[Openid-specs-ab] Expected Identity

John Bradley ve7jtb at ve7jtb.com
Mon May 14 23:17:50 UTC 2012

How is this different from the decision we made in SF to allow the id_token or a email hint to be passed to the authorization endpoint?

If a id_token is sent as part of the request only that user should be allowed to login.  Typically in the immediate mode if the user has changed or logged out they would get an error.

I don't think in the session management discussion we decided how to pass the email if a id_token is not available,  only that we need to.

There was also some discussion around the need to ask for consent to release the email if the RP sends it as a hint.

John B.
On 2012-05-14, at 6:00 PM, Justin Richer wrote:

> Blaine, your timing is spot on -- I was actually just discussing this very use case here this afternoon in the context of one of our projects. I think there's a definite need for indicating what the starting identity was in the transaction, even if for sanity checking cases. But more to the point, you don't want to cause all RPs to force a prompt for all users just in case they might run into the problem below. Ultimately, I see it as another bit of information, a hint, that the RP can send to help the IdP do its job.
> After thinking through it a bit, I think that the Request Object might be the best place to put something like that into. It makes it possible for RPs that care about it to do the legwork, but it doesn't further pollute the OAuth Auth Endpoint namespace for the simple cases that might not care.
> Should we put this in as an issue?
> -- Justin
> On 05/11/2012 09:23 PM, Blaine Cook wrote:
>> Hi all,
>> I'm trying to implement sign-in for a site using a combination of
>> OpenID 2.0, OAuth (Facebook / Twitter), and ideally OpenID Connect
>> once it's done.
>> My user interface for sign-in starts with the asking the user for
>> their email address, since I also allow password-based sign-in for
>> users who don't have or don't want federated sign-in.
>> The problem I'm facing is that there isn't a causal connection between
>> the identity provided by the user and the identity that I get back
>> after they complete their federated sign-in. For example, a user might
>> try to sign in using a friend's computer. The best possible steps with
>> OpenID 2.0 or OpenID Connect are as follows:
>> 1. The user enters "bob.example at gmail.com" as their email address and
>> is sent to Google to sign in.
>> 2. Their friend, "alice.example at gmail.com" is already signed in at
>> Google, and has already given my app permission to rely on Google as a
>> single sign-on provider.
>> 3. The user is transparently redirected back to my site.
>> 4. The token I attempt to use is for "alice.example at gmail.com";
>> clearly, though, this doesn't match Bob's expectation.
>> 5. I refuse to sign in "alice.example at gmail.com", since the requested
>> user was "bob.example at gmail.com"
>> 6. I redirect to Google, this time insisting that Google ask the user
>> to sign in.
>> 7. The user clicks "Sign in as a different user"; at this point,
>> Google needs to remember that we're still in the middle of a sign-in
>> flow (Yahoo's OpenID system fails at this point)
>> 8. The user signs in as "bob.example at gmail.com" and is redirected back
>> to my site.
>> 9. I sign-in "bob.example at gmail.com"
>> For SPs that *do not* provide a mechanism to insist that the user
>> signs in (i.e., the server doesn't implement prompt=login), this
>> approach fails at step #5, at which point I need to display a
>> confusing message indicating to the user that they should *first* sign
>> out of Google, *then* return to my site in order to sign in. This
>> option sucks, but is necessary for e.g., Yahoo.
>> Sometimes, depending on how the SP implements prompt=login, the sign
>> in may have the already signed-in user inaccessible in the sign in
>> form (i.e., only the password field is available for entry),
>> necessitating that the user explicitly sign out before signing in;
>> this can be very annoying on shared computers (and unnecessary, since
>> the login for "bob.example at gmail.com" need only persist for as long as
>> is necessary to sign Bob in on my site). In this case, this process
>> fails at #7.
>> An alternative is possible:
>> If OpenID Connect were to have (like the BrowserID 'requiredEmail'
>> attribute[1]) a parameter (e.g., "requiredIdentity") that meant "only
>> authenticate this user; do not allow any other users to authenticate,
>> and present a successful sign-in if and only if this user has
>> authenticated; otherwise, produce an error", then the following
>> workflow would be possible:
>> 1. The user enters "bob.example at gmail.com" as their email address and
>> is sent to Google to sign in.
>> Ignored: 2. Their friend, "alice.example at gmail.com" is already sign in
>> at Google, and has already given my app permission to rely on Google
>> as a single sign-on provider.
>> 2. Bob authenticates at Google, proving that he is "bob.example at gmail.com"
>> 3. Google redirects back to my site.
>> 4. I sign-in "bob.example at gmail.com"
>> There are never more complex flows, other than the normal "user can't
>> successfully sign in" flow which is already required to handle a
>> normal and necessary failure case.
>> Please consider adding this parameter to OpenID Connect – as a website
>> implementor, this feature is probably necessary for me to be able to
>> confidently provide OpenID support to my users. The alternative is a
>> sprawling and error-prone mass of code to deal with all of the
>> potential scenarios that might arise, as only hinted at in the first
>> user experience example.
>> Best,
>> b.
>> 1. https://github.com/mozilla/browserid/blob/dev/example/rp/index.html#L186
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4937 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120514/bf95e489/attachment-0001.p7s>

More information about the Openid-specs-ab mailing list