[Openid-specs-ab] May 25, 2012 OpenID Connect Update Release

Mike Jones Michael.Jones at microsoft.com
Tue Jun 5 17:32:38 UTC 2012


It's just a flag to say that the scope-requested claims are to appear in the ID Token.  It's a shorthand for requesting the listed claims in the {"id_token" : {"claims": {...}}} section of the OpenID Request Object and has the same semantics.

It in no way restricts access to the UserInfo endpoint.  In fact, claims can still be requested there in the same request using the OpenID Request Object, if the client so chooses.

                                                            -- Mike

From: Brian Campbell [mailto:bcampbell at pingidentity.com]
Sent: Tuesday, June 05, 2012 10:27 AM
To: Mike Jones
Cc: John Bradley; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] May 25, 2012 OpenID Connect Update Release

Unfortunately other work obligations kept me from attending the last in-person WG meeting but, had I been there, I would have expressed the same hesitation around the claims_in_id_token scope. It can work and if there's consensus for it, that's fine. But it is rather awkward and I wanted to raise the question.

Your point about the "openid" scope is taken but I'd argue that even though it does alter/augment the rest of the exchange, that's a necessary piece to bootstrap the whole connect SSO flow.  And even with that it still seems to fit the OAuth concept of a scope - in that it enables access to the user_id Claim at the protected resource that is the UserInfo Endpoint.  Where claims_in_id_token as a scope is just a flag on the request to indicate how the response is formed (or is it also somehow intended to constrain client access to the UserInfo Endpoint?).


On Tue, Jun 5, 2012 at 11:09 AM, Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>> wrote:
We discussed having separate scopes like email_id at the in-person working group meeting at Yahoo! and explicitly rejected that approach.  We're not trying to provide fine-grained control with scopes.  (If you need that, use a request object.)  We are providing a binary switch saying that the scope-requested claims are to be returned in a different place.  As such, at least as I see it, the logical place to make that declaration is also as a scope value.

Per Brian's comment about special treatment for scope values - that was already true without claims_in_id_token.  The "openid" scope alters/augments the semantics of the rest of the entire OAuth exchange (including enabling the id_token).  Compared to that, the special handling for the claims_in_id_token scope value is much less pervasive in impact.

For what it's worth, I'm strongly against defining a new parameter when the consensus decision at the in-person working group was to use a scope value.  We specifically discussed that approach and agreed upon it.  I believe that if we're going even consider changing that, we should likewise do so at another in-person working group meeting.  The reason I say that is that the decisions made in March at Yahoo! were *much* more widely reviewed and discussed than most working group decisions, and so should be accorded special respect.  (That's the reason we decide consequential things at in-person WG meetings, after all.)

                                                            -- Mike

From: John Bradley [mailto:ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>]
Sent: Tuesday, June 05, 2012 9:53 AM
To: Brian Campbell
Cc: Mike Jones; openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] May 25, 2012 OpenID Connect Update Release

I don't know that anyone is deeply attached to having it as a scope.   The idea was to not require a request object.

Scopes implicitly specify the RS endpoint.   This is sort of modifying the endpoint for other scopes, and I understand that is a touch awkward.

Would something like having separate scopes like:
email_id
profile_id
phone_id
address_id

If you ask for email it comes back from user_info and if you ask for email_id it is in the id_token.

Or is there something else you are thinking such as adding an extra parameter?  We are trying not to diverge from OAuth as much as possible. (Yes I know id_token is a big divergence)

If people don't like the claims_in_id_token scope then lets get alternate proposals on the table quickly.

John B.

On 2012-06-05, at 12:25 PM, Brian Campbell wrote:

I'm trying to understand why a scope was used to indicate the desire for user info claims to be returned in the ID Token? It really seems like something that should be isolated to a flag on the request (a new parameter or something in the request object). It feels out of place as a scope and will require ASs to have special conditional treatment of that one scope value (which I'd like to avoid as I'd think most implementers would).
On Sat, May 26, 2012 at 12:13 AM, Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>> wrote:


  *   Added scope value claims_in_id_token as a switch to indicate that the UserInfo claims should be returned in the ID Token, per issue #561
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120605/e10d0829/attachment.html>


More information about the Openid-specs-ab mailing list