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

Mike Jones Michael.Jones at microsoft.com
Tue Jun 5 17:25:57 UTC 2012


Please read my reply that apparently went out in parallel with your message.  Given that this decision was made at the in-person working group with dozens of participants, we have a responsibility to not change it lightly.

As an individual, I also believe that using a scope parameter is much less disruptive than using an additional parameter and also makes better sense, since this scope value modifies the behavior of other scope parameters.  But my main point is that the reason we make consequential decisions at the in-person meetings is to get broad consensus for them.  This was unanimously adopted at a meeting with dozens of participants, and therefore should not be changed without a similar level of review and participation.

                                                            -- Mike

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

I haven't thought though all the cases so this might be short sighted but it would seem that adding a new parameter to the request would be the way to go.  As you say, id_token is already a divergence from OAuth so it seems reasonable to have a divergent parameter that toggles the claims that go in it.

So I guess my preference would be to add a new request param (probably named claims_in_id_token) to the authorization request along the lines of what's already being done for nonce, display, prompt, etc.

On Tue, Jun 5, 2012 at 10:53 AM, John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>> wrote:
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/eee1a54f/attachment.html>


More information about the Openid-specs-ab mailing list