Re: [OAUTH-WG] OAuth Discovery

Hi Mike, Nat, John,

thanks for starting this work.

It seems you assume the AS can always be discoverd using the user id of 
the resource owner. I think the underlying assumption is resource 
servers accept access token of different (any?) user specific AS (and 
OP)? From my perspective, RSs nowadays typically trust _the_ AS of their 
security domain/ecosystem and all resource owners need to have an user 
account with this particular AS. So I would assume the process to start 
at the RS. We potentially need to cover for both cases.

What do you think?

best regards,
Torsten.

Am 26.11.2015 um 00:37 schrieb Mike Jones:
>
> I’m pleased to announce that Nat Sakimura, John Bradley, and I have 
> created an OAuth 2.0 Discovery specification.  This fills a hole in 
> the current OAuth specification set that is necessary to achieve 
> interoperability.  Indeed, the Interoperability section of OAuth 2.0 
> <https://tools.ietf.org/html/rfc6749#section-1.8>states:
>
> In addition, this specification leaves a few required components 
> partially or fully undefined (e.g., client registration, authorization 
> server capabilities, endpoint discovery).  Without these components, 
> clients must be manually and specifically configured against a 
> specific authorization server and resource server in order to 
> interoperate.
> This framework was designed with the clear expectation that future 
> work will define prescriptive profiles and extensions necessary to 
> achieve full web-scale interoperability.
>
> This specification enables discovery of both endpoint locations and 
> authorization server capabilities.
>
> This specification is based upon the already widely deployed OpenID 
> Connect Discovery 1.0 
> <http://openid.net/specs/openid-connect-discovery-1_0.html> 
> specification and is compatible with it, by design.  The OAuth 
> Discovery spec removes the portions of OpenID Connect Discovery that 
> are OpenID specific and adds metadata values for Revocation and 
> Introspection endpoints.  It also maps OpenID concepts, such as OpenID 
> Provider, Relying Party, End-User, and Issuer to their OAuth 
> underpinnings, respectively Authorization Server, Client, Resource 
> Owner, and the newly introduced Configuration Information Location. 
>  Some identifiers with names that appear to be OpenID specific were 
> retained for compatibility purposes; despite the reuse of these 
> identifiers that appear to be OpenID specific, their usage in this 
> specification is actually referring to general OAuth 2.0 features that 
> are not specific to OpenID Connect.
>
> The specification is available at:
>
> ·http://tools.ietf.org/html/draft-jones-oauth-discovery-00
>
> An HTML-formatted version is also available at:
>
> ·http://self-issued.info/docs/draft-jones-oauth-discovery-00.html
>
>                                                 -- Mike
>
> P.S.  This note was also posted at http://self-issued.info/?p=1496 
> <http://self-issued.info/?p=1496> and as @selfissued 
> <https://twitter.com/selfissued>.
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth