[Openid-specs-ab] scope of scope?

Mike Jones Michael.Jones at microsoft.com
Fri Mar 23 21:41:10 UTC 2012

Could you file an issue tracker issue about the first issue?  Since OAuth provides no IANA registry for scope values, OpenID Connect shouldn't try to use it. :)

The second issue has already been extensively discussed.  There's a consensus that (1) short names matter and (2) if a short name conflicts with a short name in an existing deployment, the presence of the "openid" scope value can be used to disambiguate between the two meanings of them in the OpenID Connect case, should such a need arise.

Thanks for the careful review you're doing.

                                                            -- Mike

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Brian Campbell
Sent: Friday, March 23, 2012 2:08 PM
To: <openid-specs-ab at lists.openid.net>
Subject: [Openid-specs-ab] scope of scope?

I'm still the newbie here so please forgive me if this has already been discussed but I have a concerns/questions about OpenID Connect's use of scope values. I realize most of you are probably traveling to Paris right now - I'm at a gate in O'Hare typing this - but I wanted to throw this out there in hopes of maybe discussing at the meeting on Sunday.

2 things really,

§10.1.1 of Standard -08* has an IANA registry request for the scope values, openid, profile, email, address, and phone. However, oauth-v2 does not establish, as far as I can tell, a registry for scope values - only for token types, parameters, response types and extension errors.

Perhaps this raises the question of if OAuth2 should establish some registry for scope values or otherwise provide some guidance on avoiding name collisions when using specific scope values in derivative specification? It doesn't provide much now, "The [scope] strings are defined by the authorization server" seems to be the extent of it. Anyway, the way I read it currently, the registration request in §10.1.1 is either illegal or meaningless.

Technical details of if/how to reserve scope values aside, does it make sense for this specification to try and reserve values that seem like they might be in common use already by existing OAuth deployments and products? I understand there's likely a desire of short values but I expected to see some kind of attempt at qualifying them?  i.e. oic_ or openid_ or something along those lines.


* http://openid.bitbucket.org/openid-connect-standard-1_0.html#anchor21
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120323/340ddfe7/attachment.html>

More information about the Openid-specs-ab mailing list