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

Brian Campbell bcampbell at pingidentity.com
Tue Jun 5 17:49:29 UTC 2012


I'm just saying that for the simple case (IMHO) it would make more sense
and be cleaner to define a request parameter for the flag rather than a
special scope value. The request object can stay complicated for the
complicated and granular cases.

On Tue, Jun 5, 2012 at 11:35 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> Per Mikes note, it will take a significant consensus to change the
> decision from the in person meeting.
>
> We currently have a way to ask for the claims as part of the id_token, via
> the request object.  That is still there,  would adding an aditional OAuth
> parameter be an improvement over the request object?
>
> The goal was having simple way to do it for basic clients.
>
> John B.
>
>
> On 2012-06-05, at 1:13 PM, Brian Campbell wrote:
>
> 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> 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
>> > 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/e488f332/attachment.html>


More information about the Openid-specs-ab mailing list