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:[email protected]]
Sent: Wednesday, November 25, 2015 4:59 PM
To: William Denniss <[email protected]>
Cc: Mike Jones <[email protected]>; [email protected]
Subject: Re: [OAUTH-WG] OAuth Discovery
Inline
On Nov 25, 2015, at 9:01 PM, William Denniss
<[email protected]<mailto:[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
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
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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
