[Openid-specs-ab] scope of scope?
bcampbell at pingidentity.com
Sat Mar 24 16:03:41 UTC 2012
Sure thing, just submitted #558.
I'm not necessary arguing for a change on the second issue. An having the
"openid" scope disambiguate does make sense for a lot of situations.
However, there is still the potential for ambiguity here, isn't there?
There's nothing preventing a client from requesting AS specific scope
values during the course of an OpenID Connect transaction, is there?
On Fri, Mar 23, 2012 at 10:41 PM, Mike Jones <Michael.Jones at microsoft.com>wrote:
> 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. J****
> ** **
> 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...
More information about the Openid-specs-ab