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

Brian Campbell bcampbell at pingidentity.com
Tue Jun 5 17:26:40 UTC 2012


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_idClaim 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>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]
> *Sent:* Tuesday, June 05, 2012 9:53 AM
> *To:* Brian Campbell
> *Cc:* Mike Jones; 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>
> 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
> 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/6c530afa/attachment-0001.html>


More information about the Openid-specs-ab mailing list