We are not changing current OAuth Semantics. Scopes are per AS and might apply to different API. The AS needs to sort out its scope name collision policy otherwise it will be a problem at the authorization endpoint when they request scopes anyway. Scope is unfortunately already overloaded, we are supporting the overloaded scopes from the Authorization endpoint.
The AS could also have different registration endpoints for different API if they want to have separate client_id for the API. (the authorization and token endpoints could resolve scope name collisions based on client_id, but that is more an implementation issue they would logically be separate AS from the client perspective.) The scopes are the ones used at the authorization/token endpoint. John B. On 2013-06-05, at 1:11 AM, Phil Hunt <phil.h...@oracle.com> wrote: > How is targeting achieved in dynamic registration? Or in other words how do > we know what API is referred to within the scope? Is the registration > endpoint generic or to be matched with each resource API? > > For example, in google's manual registration system, they ask which APIs the > clients will access. This keeps scope from getting complex later on. > > I'm worried about attempting to overload scope for this purpose during > registration. > > I suppose if a client can only register for one API at a time, then the usual > OAuth2 techniques for targeting would apply. > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
