Issuer check failures?

[kevinbaker]

Per 4.3 (Token Issuance - issuer checks) what if there are some failures?

1. Multiple 1P cookies? And user is required to select between multiple accounts currently logged in at the Issuer side (for example, multiple @gmail.com accounts on a home PC).

2. You note "cookies sent represent a logged in user, and if the logged in user " ...

• What if the user's login is expired using the email address, but the Issuer wants to make sure a valid login is done before returning "email_verified": true? (also, desiring 2FA usage at the Issuer side.)

Is there any browser flow to redirect to an Issuer page to have the Issuer confirm login details before returning to the original page flow?

[kevinbaker]

Also...

3. Not the right email at all? For example, if I have the email first initial last name @ gmail.com , and people attempt to use my email as a throwaway to verify all the time from every site under the sun, how does the Issuer return a real failure? Even if the user is determined to use it as a throwaway?

Is it just email_verified: false, but ... maybe something stronger could be designed in... email_failed_verification: "do_not_use_this_one! he gets so much spam!" ?

What would the UI look like in this case for the user? Force the user to pick another email? I guess I haven't tried seeing what an OAuth flow looks like in this case for comparison (wrong account altogether)

[fkj]

For the third case, wouldn't just failing immediately be the correct choice for the "people" since they are not logged in to an account with that email? The whole point is to make sure people cannot use it (in this case as a throwaway) without actually being in control of that email address (as defined by the issuer).