Explicit Sign-in 1.1.2.2 => direct interaction between user and IdP?

[dickhardt]

All large IdPs dynamically evaluate each attempted sign in to an RP by a user, and will require additional direct interaction if a risk threshold is exceeded. The proposal reads that the IdP has no mechanism to directly interact with the user.

[dj2]

What kinds of interactions are typically seen? Is the risk threshold custom per IDP or is there something specific they're looking for?

[dickhardt]

The big IdPs all gather their own unique signals and feed them into their ML to make decisions. They are not doing this as IdPs -- it is what they do for account protection generally.

[gffletch]

Agree with @dickhardt! The IDP MUST have a direct communication path with the user. Sometimes it's to require an additional verification (ala Google when you login from a new device and new location). Sometimes it's to alert the user to some other aspect of change to their identity at the IDP. Given that many IDPs have additional services there might be a privacy check-up flow that is required (etc). There is also the case of authentication methods (e.g. QR codes) that don't involve the browser at all but require the IDP to be able to return content to the user so that the user can complete the flow.

This is a key benefit of the existing redirect based flows. The RP has transferred the user to the IDP to do whatever is necessary at the IDP and when those steps are completed the IDP returns the user to the RP in an authenticated state. Changing that dynamic and significant impacts on the user's security and the dynamics of how identity works today.

[npm1]

The IDP needs to produce an ID token that is going to be used by the RP to sign the user in. Is this last step not sufficient? If an IDP deems the risk to the user to be high in the particular scenario, they could reject sending an IDP token. However, I do agree that we have not replaced all of the flows available via redirects with this API.

[achimschloss]

#253 (comment)

[yi-gu]

This has been addressed with the Error API #498 e.g. the IdP can return an error instead of a token and the browser can render UI for the IdP to communicate with the users.

In case that the IdP needs to gather further user permission before issuing an token, they could use the Continuation API w3c-fedid/custom-requests#1