Re: [OAUTH-WG] OAuth Discovery

[Mike Jones <[e-mail]>]

Thanks for the quick feedback, William.  I had almost finished writing similar comments to John’s when his reply came in. ;-)

Per your second questions, for the -00 draft, we intentionally didn’t invent any new functionality (other than adding revocation and introspection endpoint values).  Other means of obtaining the configuration information location can be added later, if there’s consensus to do so.  I’ll observe that if we want the authorization endpoint to return something additional, that may be more of an activity that revises RFC 6749 than a discovery spec activity.  If so, the 6749bis could specify that a URL for the discovery information be returned under specific circumstances.

John’s right that people should think about how to best describe the “issuer” value in a general OAuth context.  The spec currently says that this location is the root of .well-known resources for the authorization server.  That’s certainly true but maybe not completely intuitively appealing.  Your thoughts how to better describe this would be appreciated.

Happy Thanksgiving to all of you in the US!

                                                          -- Mike

From: John Bradley [mailto:[e-mail]]
Sent: Wednesday, November 25, 2015 4:59 PM
To: William Denniss <[e-mail]>
Cc: Mike Jones <[e-mail]>; [e-mail]
Subject: Re: [OAUTH-WG] OAuth Discovery

Inline
On Nov 25, 2015, at 9:01 PM, William Denniss <[e-mail]<mailto:[e-mail]>> 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 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 <[e-mail]<mailto:[e-mail]>> 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

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<https://twitter.com/selfissued>.

_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth