I tend to agree that we need both. We needed to start someplace.
The user based discovery may better be described as finding a OAuth Service/API for the user, authentication, photo, calendar, health record etc. We may want to separate that from the OAuth discovery as that could be used independently. Anyway the document is a start. John B. > On Dec 13, 2015, at 2:43 PM, 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 >> <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>http://tools.ietf.org/html/draft-jones-oauth-discovery-00 >> <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 >> <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 <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
