Subject: [OAUTH-WG] OAuth Discovery

From: Mike Jones <[email-masked]>
Date: Wed, 25 Nov 2015 23:37:10 +0000

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>.

---

From: William Denniss <[email-masked]>
Date: Wed, 25 Nov 2015 16:01:23 -0800

Looks good. A few review notes:

1.
Can we add a xref to the WebFinger spec (RFC7033) in section 2?

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?

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"

On Wed, Nov 25, 2015 at 3:37 PM, Mike Jones <[email-masked]>
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:
>
> 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.
>
>
>
> ·         http://tools.ietf.org/html/draft-jones-oauth-discovery-00
>
>
>
> ·         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-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Nov 2015 21:59:18 -0300

Inline
> On Nov 25, 2015, at 9:01 PM, William Denniss <[email-masked]> wrote:
> 
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-masked] <mailto:[email-masked]>> 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:
> 
> 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.
> 
>  
> 
> ·         http://tools.ietf.org/html/draft-jones-oauth-discovery-00 <http://tools.ietf.org/html/draft-jones-oauth-discovery-00>
>  
> 
> ·         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>.
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 26 Nov 2015 01:13:35 +0000

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-masked]]
Sent: Wednesday, November 25, 2015 4:59 PM
To: William Denniss <[email-masked]>
Cc: Mike Jones <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] OAuth Discovery

Inline
On Nov 25, 2015, at 9:01 PM, William Denniss <[email-masked]<mailto:[email-masked]>> wrote:

1.

2.

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"

John B.

On Wed, Nov 25, 2015 at 3:37 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> 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:

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

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

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

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 26 Nov 2015 16:30:56 +0200

Good work, Mike, John, Nat!

I see that the introspection and revocation endpoints are included now
(they've been missing in OpenID discovery).

Regarding client authentication, would it make sense to let
token_endpoint_auth_methods_supported apply to the introspection and
revocation endpoints as well?

token_endpoint_auth_methods_supported
      OPTIONAL.  JSON array containing a list of client authentication
      methods supported by this token endpoint.  Client authentication
      method values are used in the "token_endpoint_auth_method"
      parameter defined in Section 2 of [RFC7591] <http://tools.ietf.org/html/rfc7591#section-2>.  If omitted, the
      default is "client_secret_basic" -- the HTTP Basic Authentication
      Scheme specified in Section 2.3.1
<http://tools.ietf.org/html/draft-jones-oauth-discovery-00#section-2.3.1> of OAuth 2.0 [RFC6749 <http://tools.ietf.org/html/rfc6749>].

Vladimir

---

From: Justin Richer <[email-masked]>
Date: Thu, 26 Nov 2015 09:37:45 -0500

Those should be handled separately if they’re to be added to discovery.

 — Justin

> On Nov 26, 2015, at 9:30 AM, Vladimir Dzhuvinov <[email-masked]> wrote:
> 
> I see that the introspection and revocation endpoints are included now (they've been missing in OpenID discovery).
> 
> Regarding client authentication, would it make sense to let token_endpoint_auth_methods_supported apply to the introspection and revocation endpoints as well?
> 
>       Scheme specified in Section 2.3.1 <http://tools.ietf.org/html/draft-jones-oauth-discovery-00#section-2.3.1> of OAuth 2.0 [RFC6749 <http://tools.ietf.org/html/rfc6749>].
> 
> 
> Vladimir
> 
>> 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> <https://tools.ietf.org/html/rfc6749#section-1.8> states:
>> 
>> This specification is based upon the already widely deployed OpenID Connect Discovery 1.0<http://openid.net/specs/openid-connect-discovery-1_0.html> <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 
>>  s
>> pecific to OpenID Connect.
>> 
>> *         http://tools.ietf.org/html/draft-jones-oauth-discovery-00 <http://tools.ietf.org/html/draft-jones-oauth-discovery-00>
>> 
>> *         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> <https://twitter.com/selfissued>.
>> 
>> 
>>

---

From: John Bradley <[email-masked]>
Date: Thu, 26 Nov 2015 12:59:30 -0300

The methods could be the same but they should probably specified separately eg

introspection_endpoint_auth_methods_supported
If we overload them we will probably regret it later.

John B.
> On Nov 26, 2015, at 11:30 AM, Vladimir Dzhuvinov <[email-masked]> wrote:
> 
>> This specification is based upon the already widely deployed OpenID Connect Discovery 1.0<http://openid.net/specs/openid-connect-discovery-1_0.html> <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 
>>  s

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 27 Nov 2015 01:35:19 +0900

Agreed...

2015-11-27 0:59 GMT+09:00 John Bradley <[email-masked]>:

> P.S.  This note was also posted at http://self-issued.info/?p=1496 and as @selfissued<https://twitter.com/selfissued> <https://twitter.com/selfissued>.
>
>
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 26 Nov 2015 20:31:54 +0200

Introspection (RFC 7662) allows bearer token authorisation for the
request, which I guess will require a new keyword for this auth method?

https://tools.ietf.org/html/rfc7662#section-2.1

On 26.11.2015 17:59, John Bradley wrote:
>>> Vladimir Dzhuvinov :: [email-masked]
>>>

---

From: Bill Mills <[email-masked]>
Date: Sat, 28 Nov 2015 03:58:20 +0000 (UTC)

Can you elaborate on the advantage of having a separate parallel spec to OpenID Discovery? 

    On Wednesday, November 25, 2015 3:37 PM, Mike Jones <[email-masked]> wrote:

  <!--#yiv2101860304 _filtered #yiv2101860304 {font-family:Wingdings;panose-1:5 0 0 0 0 0 0 0 0 0;} _filtered #yiv2101860304 {font-family:"Cambria Math";panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv2101860304 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv2101860304 {font-family:"Segoe UI";panose-1:2 11 5 2 4 2 4 2 2 3;}#yiv2101860304 #yiv2101860304 p.yiv2101860304MsoNormal, #yiv2101860304 li.yiv2101860304MsoNormal, #yiv2101860304 div.yiv2101860304MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv2101860304 a:link, #yiv2101860304 span.yiv2101860304MsoHyperlink {color:#0563C1;text-decoration:underline;}#yiv2101860304 a:visited, #yiv2101860304 span.yiv2101860304MsoHyperlinkFollowed {color:#954F72;text-decoration:underline;}#yiv2101860304 pre {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:"Courier New";}#yiv2101860304 p.yiv2101860304MsoListParagraph, #yiv2101860304 li.yiv2101860304MsoListParagraph, #yiv2101860304 div.yiv2101860304MsoListParagraph {margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv2101860304 span.yiv2101860304EmailStyle17 {font-family:"Calibri", sans-serif;color:windowtext;}#yiv2101860304 span.yiv2101860304HTMLPreformattedChar {font-family:"Courier New";}#yiv2101860304 span.yiv2101860304grey {}#yiv2101860304 .yiv2101860304MsoChpDefault {} _filtered #yiv2101860304 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv2101860304 div.yiv2101860304WordSection1 {}#yiv2101860304 _filtered #yiv2101860304 {} _filtered #yiv2101860304 {font-family:Symbol;} _filtered #yiv2101860304 {font-family:"Courier New";} _filtered #yiv2101860304 {font-family:Wingdings;} _filtered #yiv2101860304 {font-family:Symbol;} _filtered #yiv2101860304 {font-family:"Courier New";} _filtered #yiv2101860304 {font-family:Wingdings;} _filtered #yiv2101860304 {font-family:Symbol;} _filtered #yiv2101860304 {font-family:"Courier New";} _filtered #yiv2101860304 {font-family:Wingdings;}#yiv2101860304 ol {margin-bottom:0in;}#yiv2101860304 ul {margin-bottom:0in;}-->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, theInteroperability section of OAuth 2.0states: 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 deployedOpenID 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
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Jones <[email-masked]>
Date: Sat, 28 Nov 2015 04:05:45 +0000

It allows non-Connect implementation of OAuth 2.0 to also have a standard discovery capability – and one that can later be updated to also support OpenID Connect with no breaking changes, should that be desired in the future.

                                                          -- Mike

From: Bill Mills [mailto:[email-masked]]
Sent: Friday, November 27, 2015 7:58 PM
To: Mike Jones <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] OAuth Discovery

On Wednesday, November 25, 2015 3:37 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                                -- Mike

---

From: Phil Hunt <[email-masked]>
Date: Fri, 27 Nov 2015 20:43:32 -0800

While it is good to start with the connect spec, i would caution on the assumption of compatibility. More than likely there will be changes based on broader cases. 

I would like to understand these broader requirements, use cases, and security considerations first. 

Phil

> On Nov 27, 2015, at 20:05, Mike Jones <[email-masked]> 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 states:
> 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.
>  
> P.S.  This note was also posted at http://self-issued.info/?p=1496 and as @selfissued.
>

---

From: Prateek Mishra <[email-masked]>
Date: Sat, 28 Nov 2015 14:24:17 -0800

+1
[quote]
> I would like to understand these broader requirements, use cases, and security considerations first. 

[\quote]

OAuth is being used in a *much* broader set of use-cases and contexts than OpenID connect. 

I think its very important to have a solution that addresses these flows. 

- prateek

> On Nov 27, 2015, at 20:05, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>   <>
>> From: Bill Mills [mailto:[email-masked] <mailto:[email-masked]>] 
>> To: Mike Jones <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> On Wednesday, November 25, 2015 3:37 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>>

---

From: Mike Jones <[email-masked]>
Date: Sat, 28 Nov 2015 23:40:55 +0000

No disagreement.  I’m sure that the working group will add features to address functionality needed for some common use cases that are not needed by OpenID Connect.  Indeed, the three authors have already done so – adding endpoints for token revocation and token introspection.  Other additions are likely to occur as well along the way.

That being said, given that OpenID Connect Discovery<http://openid.net/specs/openid-connect-discovery-1_0.html> established existing practice for representing common discovery functionality like the authorization endpoint URL, the token endpoint URL, etc., it would seem counterproductive not to follow that existing practice, where applicable.  Indeed, the OAuth working group has already had a similar success with a completed RFC, keeping OAuth 2.0 Dynamic Client Registration<http://tools.ietf.org/html/rfc7591> 100% compatible with OpenID Connect Dynamic Client Registration<http://openid.net/specs/openid-connect-registration-1_0.html>.

Getting down to specifics, what features are needed for common use cases that aren’t already in the current draft?  For starters, Vladimir Dzhuvinov has already called out defining authentication methods to the revocation and introspection endpoints.  What else are people commonly doing that isn’t covered in the current draft?

Remember of course, that one of the primary purposes of the specification is to establish the OAuth Discovery Metadata Registry.  That way we don’t have to think of everything that anyone might need in advance.  New values can and will be added as they are needed by new and existing applications in additional specifications utilizing the registry.

                                                          Best wishes,
                                                          -- Mike

From: Prateek Mishra [mailto:[email-masked]]
Sent: Saturday, November 28, 2015 2:24 PM
To: Phil Hunt <[email-masked]>
Cc: Mike Jones <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] OAuth Discovery

+1
[quote]

Phil

[\quote]

- prateek

On Nov 27, 2015, at 20:05, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
It allows non-Connect implementation of OAuth 2.0 to also have a standard discovery capability – and one that can later be updated to also support OpenID Connect with no breaking changes, should that be desired in the future.

                                                          -- Mike

From: Bill Mills [mailto:[email-masked]]
Sent: Friday, November 27, 2015 7:58 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] OAuth Discovery

                                                                -- Mike

---

From: John Bradley <[email-masked]>
Date: Sat, 28 Nov 2015 20:41:32 -0300

No one is saying we shouldn’t.

What I said was that Connect will consider refactoring it’s discovery to be based on the IETF version once there is one if it is posable.

If it is not posable for Connect to use the OAuth discovery from this WG then that would be a fail.

I think we are in agreement.

What Mike and I submitted is a starting point.

John B.

> On Nov 28, 2015, at 7:24 PM, Prateek Mishra <[email-masked]> wrote:
> 
> +1
> [quote]
>>