Consent stage breaks usability and user relation with IDP. Raises privacy issues for IDPs

[achimschloss]

The latest changes in https://github.com/samuelgoto/WebID#the-consent-stage don't look workable for an IDP and will largely affect user convenience and expectation.

IDPs rely on a direct user interaction (IDP UI) for a user to authorise information sharing with an RP and also to validate the RPs identity. The proposal raises some fundamental concerns:

• How should an IDP validate/trust that an authorisation was given by a specific user?
• More importantly, how would the IDP even be sure which RP is receiving the data? In a usual SSO flow RPs must be authenticated by the IDP for obvious reasons, which requires prior registration / agreements on secrets etc. Even lightweight approaches based on CORS won't work without RP knowledge prio to transmitting any data
• How would an IDP know and record which data the RP is requesting? (scopes/claims)

Users rely on an IDPs service across devices / different browsers / different sessions for an RP on a single browser. This interaction is unknown to the browser thus user interactions will not meet user expectation:

• As already noted in the proposal the IDP will have prior user interactions that the browser is not aware of, a user could have registered with an RP on a different device / prior session and already approved to share specific information to an RP. Establishing the browser UI as proposed will basically eliminate the main advantages of an IDP as the user will see repetitive prompts to share the same information over and over again.
• Conceptually one needs to differentiate between a registration and a following login, which one is currently happening during a call to the IDP API cannot be known to the browser thus he cannot present a fitting interaction without relying on the IDP (which in turn needs to be ware of the RP to do so).
• I don't see how one could conceptually decouple this a suggested without breaking user expectation.

The prior approach of wrapping the IDP Interaction with the user into an identity-specific API/Wrapper looked much more balanced and workable for the stated goals to minimize the divergence from existing federated identity user experience. The control of the authentication/authorisation flow must remain with the IDP thought (without duplication by the browser)

The browser can very well observe the interaction of the user with the IDP and also inform the user about an RP session state with an IDP. Ultimately its the users choice to leverage an IDP with an RP which is completely unrelated to the browser itself, I do believe this choice should be respected and don't see how this decoupling could work out. IDP Tracking might be scenario, but it should not dictate the whole design of this API (with the noted impacts) as the IDP is a service chosen by the user

[samuelgoto]

Great points! Let me try to address them:

How should an IDP validate/trust that an authorisation was given by a specific user?

IDPs rely on the conventions browsers use to assess that authorization was given by a specific user (e.g. a

was filled and submitted, a JS event was fired, etc). IDPs would use different conventions (TBD), but the same trust relationship.

More importantly, how would the IDP even be sure which RP is receiving the data? In a usual SSO flow RPs must be authenticated by the IDP for obvious reasons, which requires prior registration / agreements on secrets etc. Even lightweight approaches based on CORS won't work without RP knowledge prio to transmitting any data

In this latest formulation, IDPs would get the information of RPs after user consent.

How would an IDP know and record which data the RP is requesting? (scopes/claims)

In this latest formulation, we would break down authentication from authorization, so the intermediation would only happen for the former but not for the latter (where scopes/claims are used).

I need to write that down, as that's unclear in the explainer right now.

The prior approach of wrapping the IDP Interaction with the user into an identity-specific API/Wrapper looked much more balanced and workable for the stated goals to minimize the divergence from existing federated identity user experience. The control of the authentication/authorisation flow must remain with the IDP thought (without duplication by the browser)

Agreed, and I need to keep that section in an "Alternatives Considered" section. The challenge with this formulation is that it can be abused by trackers and used outside of the scope of authentication. By imposing a stricter UI, the browser can be more confident that it is being used for the purposes of exchanging identity related tokens.

That is, if the IDP gets to control more of the UI, what prevents a tracker from using the API for tracking purposes?

[achimschloss]

How should an IDP validate/trust that an authorisation was given by a specific user?

IDPs rely on the conventions browsers use to assess that authorization was given by a specific user (e.g. a was filled and submitted, a JS event was fired, etc). IDPs would use different conventions (TBD), but the same trust relationship.

Ok, I think it's important to have this stated explicitely.

More importantly, how would the IDP even be sure which RP is receiving the data? In a usual SSO flow RPs must be authenticated by the IDP for obvious reasons, which requires prior registration / agreements on secrets etc. Even lightweight approaches based on CORS won't work without RP knowledge prio to transmitting any data

In this latest formulation, IDPs would get the information of RPs after user consent.

I think we'd need to break down the phases of the process down a bit more granular, we maybe have a different understanding of the consent phase /UI. I think what you are referring to might be what I'd call account selection/discovery - see also below

How would an IDP know and record which data the RP is requesting? (scopes/claims)

In this latest formulation, we would break down authentication from authorization, so the intermediation would only happen for the former but not for the latter (where scopes/claims are used).

I think I understand where your getting at, typically a login process with an IDP has the following phases in my view (feel free to add).

1. Account Selection / Discovery - This is mainly a User/IDP interaction, knowledge of the RP is not really relevant for the IDP at that stage. The user will choose an account to use to login into an RP (usually by entering his e-mail in the initial interaction) and proceed. Account choices are usually persisted within the user agent. (User/IDP relation). It's a form of authorisation in a sense given the user will share his e-mail address with the IDP at this stage.
2. Authentication - User authenticates with the IDP (either via a fitting interaction with the IDP or based on a already known authentication status(usually stored in server-side cookies))
3. Authorisation (in relation to the RP) - User approves claims as requested by the RP (thus knowledge of the RP is necessary here), in cases the IDP determines it's still needed (as the user did not approve already)
4. ID Token/Access Token handling back to the RP

Are you saying that the proposal would mainly relate to 1 and 4 and leave the rest of the phase untouched (other then using new JS-API to initiate / transfer the necessary details)?

By imposing a stricter UI, the browser can be more confident that it is being used for the purposes of exchanging identity related tokens.

That is, if the IDP gets to control more of the UI, what prevents a tracker from using the API for tracking purposes?

Ok - so the scenario is that an adversary (using a more general term) would misuse the API by basically just mocking the calls (no user interaction whatsoever), access some client side storage and pass back information (while also collecting data provided).

Looking at the phases above this could be prevented by focussing on phase 1 and 4 I would think:

• Account Selection / Discovery is a pretty generic use-case, if that would become a browser supported UI that would allow the IDP to still maintain a state that sounds as if it could be made generic (Branding support needed of course). There are some details that would need consideration like Identity First Flows (RP side account selection) etc. this is part of the Nascar Challenge.
• By mediating 4 the browser can transparently inform the user about a login status in any case here. The browser could establish confidence that the IDP is not an adversary by running the user through a mediated account selection/discovery at least once.

Edit:
Another more obvious option would be to only allow whitelisted IDPs to be called via theres APIs, similar to what is being done with certificate authorities.

I need to write that down, as that's unclear in the explainer right now.

Thanks, appreciated.

[npm1]

This issue asks some questions which we believe are solved with some of the APIs we are proposing, such as the w3c-fedid/custom-requests#1 continuation API, w3c-fedid/custom-requests#4 fields API, and w3c-fedid/custom-requests#2 params. Since there has not been an update on this in 4 years, I'm going to close it but feel free to comment if you think something else needs to be addressed and we can reopen.