+1. Good observation. Phil
> On Dec 13, 2015, at 12:43, Torsten Lodderstedt <tors...@lodderstedt.net> > wrote: > > 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 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 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 and as >> @selfissued. >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth