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

Brian Campbell bcampbell at pingidentity.com
Mon Jun 11 16:14:53 UTC 2012


FWIW, on my initial reading of it I made the assumption that the
openid scope was required for access to anything at the user info
endpoint.  My reasoning was that the user info endpoint is an OpenID
connect thing and that messages says, "If the openid scope value is
not present, the request MUST NOT be treated as an OpenID Connect
request." I inferred from that that not having or not approving the
openid scope would mean that the given access token would not be valid
for any access to the userinfo endpoint.

Looking at the very next sentence in messages, "This scope value
requests access to the user_id Claim at the UserInfo Endpoint" as well
as the wording on the email, profile, address and phone scopes might
suggest that initial interpretation is wrong and that any one of those
scopes is sufficient for access to the user info endpoint.

I can see it either way and don't have a strong preference but I do
think it is currently somewhat ambiguous and should probably be
clarified.

On Thu, Jun 7, 2012 at 9:29 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
> Right if openid is not one of the scopes the meaning of profile and email is undefined and up to the IdP to decide how to process in OAuth.
>
> The question is what happens if the scopes are "openid profile email"  and the user declines to login (denies the openid scope).
>
> Do you:
> a) Return a OAuth error saying the user declined everything.
> b) Grant a access_token for the user_info endpoint for those scopes (but no id_token)
> c) Treat the "profile email" scopes as if they were not part of openID Connect and precess them as if they had not been received with the openid scope.
>
> I am guessing that most implementations do a or b.
>
> Should the spec clarify only one option as being correct fro the IdP?
>
> John B.
>
> On 2012-06-07, at 10:59 AM, Sascha Preibisch wrote:
>
>> Hi John!
>>
>> I am working on an early implementation and we assumed that a user can deny/ grant any of the scope values.
>>
>> Like granting "profile" but denying "address". The issued access_token can than only retrieve data with the associated granted scope.
>>
>> Another question would be:
>>
>> - if scope is "openid profile email" profile and email would be handled as openid scopes und accessed via "/userinfo"
>> - if scope is "profile email" profile and email would be handled as ordinary scopes but not to be used with "/userinfo".
>>
>> I think some clarification here would be good.
>>
>> Regards,
>> Sascha
>>
>> -----Original Message-----
>> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of John Bradley
>> Sent: Thursday, June 07, 2012 7:34 AM
>> To: Nat Sakimura
>> Cc: openid-specs-ab at lists.openid.net
>> Subject: Re: [Openid-specs-ab] May 25, 2012 OpenID Connect Update Release
>>
>> The openID scope is presented to the user as their RP is requesting authentication proceed yes/no or other appropriate language.
>> It is possible that a openID Connect request could come in with scopes for "openID photo_share"  and a user declines to login but agrees to grant a token for photo_share.
>>
>> We may need to clarify that this is valid, so a client could get back a access token for some other service without a id_token.
>>
>> It might be worth double checking what people think would happen if a user consents to "profile" but declines to login?
>> Is that returned as a error, or as just a access token for user_info?
>>
>> Should a Authorization server allow that combination?
>>
>> John B.
>>
>> On 2012-06-07, at 2:30 AM, Nat Sakimura wrote:
>>
>>> OpenID scope can be denied. Deciding not to proceed with
>>> authentication is indeed the denial of OpenID scope.
>>>
>>> OpenID scope is the scope that is requesting the id_token. If the user
>>> denies it, the response will not have id_token and the authentication
>>> fails. Other scopes may be granted at the same time but that is not
>>> defined by the OpenID specification as they are out of scope.
>>>
>>> Nat Sakimura
>>>
>>> On 2012/06/07, at 15:10, Mike Jones <Michael.Jones at microsoft.com> wrote:
>>>
>>>> The "openid" scope already can not be denied by users.  Some scopes specify claims.  Others do not.  You'll already have to have code that is specific to each scope value without claims_in_id_token.
>>>>
>>>> Users may not be given the option to deny claims_in_id_token.  Like the "openid" scope, it modifies the behavior of the OAuth flow - it doesn't request any additional claims.
>>>>
>>>>              -- Mike
>>>>
>>>> -----Original Message-----
>>>> From: openid-specs-ab-bounces at lists.openid.net
>>>> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of nov
>>>> matake
>>>> Sent: Wednesday, June 06, 2012 10:40 PM
>>>> To: Vladimir Dzhuvinov / NimbusDS
>>>> Cc: openid-specs-ab at lists.openid.net
>>>> Subject: Re: [Openid-specs-ab] May 25, 2012 OpenID Connect Update
>>>> Release
>>>>
>>>> +1 for the new response type.
>>>>
>>>> I don't want to have any undenyable scopes.
>>>> (If user denied "claims_in_id_token" scope, what happens?)
>>>>
>>>> I'm OK with both making single "id_token_with_userinfo" response type or combination of "id_token" and "userinfo".
>>>>
>>>> nov
>>>>
>>>> On 2012/06/06, at 5:29, Vladimir Dzhuvinov / NimbusDS wrote:
>>>>
>>>>> Hi guys,
>>>>>
>>>>> I just started work on updating our OpenID Connect SDK to the latest
>>>>> revision.
>>>>>
>>>>> From a programming perspective I regard this extended ID token in a
>>>>> class of its own. To me, the logical way to request it is by means
>>>>> of an additional response type, e.g. extended_id_token or
>>>>> id_token_with_userinfo.
>>>>>
>>>>> My understanding of "scope" has been that it is purely a spec of
>>>>> which claims sets the client wants to receive, and not about the
>>>>> "how" and "where". And this is how we had it implemented, as a set
>>>>> of enum values that map to claim names.
>>>>>
>>>>>
>>>>> Vladimir
>>>>>
>>>>> --
>>>>> Vladimir Dzhuvinov : www.NimbusDS.com : vladimir at nimbusds.com
>>>>>
>>>>>
>>>>>
>>>>> -------- Original Message --------
>>>>> Subject: Re: [Openid-specs-ab] May 25, 2012 OpenID Connect Update
>>>>> Release
>>>>> From: Brian Campbell <bcampbell at pingidentity.com>
>>>>> Date: Tue, June 05, 2012 6:49 pm
>>>>> To: John Bradley <ve7jtb at ve7jtb.com>
>>>>> Cc: "openid-specs-ab at lists.openid.net"
>>>>> <openid-specs-ab at lists.openid.net>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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
>>> _______________________________________________
>>> 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
>


More information about the Openid-specs-ab mailing list