Inline > On Nov 25, 2015, at 9:01 PM, William Denniss <[email protected]> wrote: > > Looks good. A few review notes: > > 1. > Can we add a xref to the WebFinger spec (RFC7033) in section 2? Yes that should be OK > > 2. > Is the only way to discover the location of the discovery document via > WebFinger? > > In Yokohama we also talked about the AS returning the discovery document host > (i.e. issuer) on the auth and token endpoints. What are the reasons for > choosing WebFinger over that method?
This is a first draft, that is close to the Connect Document. It needs work, around what a issuer (AS identity) is in OAuth. Some of the Webdinger stuff is strange without a specific API that you are looking for. It would be odd to look for someone’s OAuth server. I could see looking for a persons Photosharing service and getting directed to It’s AS discovery document assuming a well known API. Nat has a spec on meta-data for the endpoint API. The WG may elect to merge them or keep them separate. It would be the endpoint meta-data (headers) that would point at the discovery document. This is a start. > > 3. > It looks like an IANA registry was not setup for OpenID Connect discovery > params (at least, not in that spec). Is the registry established in > http://tools.ietf.org/html/draft-jones-oauth-discovery-00#section-8.1.2 > <http://tools.ietf.org/html/draft-jones-oauth-discovery-00#section-8.1.2> > designed to be a shared registry for OIDC/OAuth discovery? And if so, should > we also register values defined in the OIDC discovery spec, e.g. > “subject_types_supported" I expect that like registration, OAuth would establish the registry and register an initial set, and then Connect would add connect specific claims to that registry once it is established. John B. > > On Wed, Nov 25, 2015 at 3:37 PM, Mike Jones <[email protected] > <mailto:[email protected]>> wrote: > 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> > > > 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 > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
