Subject: [OAUTH-WG] OAuth Discovery spec pared down to its essence

From: Mike Jones <[email-masked]>
Date: Thu, 18 Feb 2016 06:48:22 +0000

In response to working group input, this version of the OAuth Discovery specification has been pared down to its essence - leaving only the features that are already widely deployed.  Specifically, all that remains is the definition of the authorization server discovery metadata document and the metadata values used in it.  The WebFinger discovery logic has been removed.  The relationship between the issuer identifier URL and the well-known URI path relative to it at which the discovery metadata document is located has also been clarified.

Given that this now describes only features that are in widespread deployment, the editors believe that this version is ready for working group last call.

The specification is available at:

*       http://tools.ietf.org/html/draft-ietf-oauth-discovery-01

An HTML-formatted version is also available at:

*       http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html

                                                          -- Mike & Nat & John

P.S.  This notice was also posted at http://self-issued.info/?p=1544 and as @selfissued<https://twitter.com/selfissued>.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 18 Feb 2016 06:35:28 -0700

I still find the following text objectionable and confusing…
   By default, for historical reasons, unless an application-specific
   well-known URI path suffix is registered and used for an application,
   the client for that application SHOULD use the well-known URI path
   suffix "openid-configuration" and publish the metadata document at
   the path formed by concatenating "/.well-known/openid-configuration"
   to the authorization server's issuer identifier.  As described in
   Section 5 <http://tools.ietf.org/html/draft-ietf-oauth-discovery-01#section-5>, despite the identifier
   "/.well-known/openid-configuration", appearing to be OpenID-specific,
   its usage in this specification is actually referring to a general
   OAuth 2.0 feature that is not specific to OpenID Connect.

Further, as a default “openid-configuration” as the default further gives people the impression that a plain OAuth server *is* an authentication server and that the normal access token received is evidence of a successful authentication.

It would be better to point out that application may include oauth discovery in their discovery URI and that OAuth is an example of this. It might be good to include two examples.  E.g. OIDC and SCIM (as another referenceable example).

 GET /.well-known/openid-configuration
and
 GET /.well-known/scim
Retrieve the OAuth configuration for the application openid and scim respectively.

The use of:
 GET /.well-known/oauth2/
Should be the default used when there is no known application based well-known application based URI discovery.

Of course, the concern I raised earlier is that this approach of application specific URIs ends up requiring every application to make an IANA registration if they don’t want to use the default of “oauth2” (or “openid-configuration”).  Is that what the authors expect?

It seemed better to me to use the webfinger syntax to allow the client to say “I want the designated OAuth configuration for the resource service X” would be a better design that avoids extensive IANA registration.

Phil

@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Feb 17, 2016, at 11:48 PM, Mike Jones <[email-masked]> wrote:
> 
> In response to working group input, this version of the OAuth Discovery specification has been pared down to its essence – leaving only the features that are already widely deployed.  Specifically, all that remains is the definition of the authorization server discovery metadata document and the metadata values used in it.  The WebFinger discovery logic has been removed.  The relationship between the issuer identifier URL and the well-known URI path relative to it at which the discovery metadata document is located has also been clarified.
>  
> ·       http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 <http://tools.ietf.org/html/draft-ietf-oauth-discovery-01>
>  
> ·       http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html <http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html>
>  
>                                                           -- Mike & Nat & John
>  
> P.S.  This notice was also posted at http://self-issued.info/?p=1544 <http://self-issued.info/?p=1544> and as @selfissued <https://twitter.com/selfissued>.
> _______________________________________________
> OAuth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: John Bradley <[email-masked]>
Date: Thu, 18 Feb 2016 08:55:39 -0500

Diffrent protocols like Connect and SCIM may have different configurations, endpoints , keys , authentication methods, scopes etc.

It should be posable to have them as one document, but forcing them to use one document is going to cause a explosion of claim registration for discovery.

I think it is better for SCIM to register one well known than to have to register 20 claims with scim prefixes or something silly like that.

Name-spacing the claims by allowing them to be in different well known files is not unreasonable.

Remember some of these protocols may be hosted on SaaS so there is no guarantee that all protocols will have the same OAuth Config.

Nothing stops a protocol from doing what it likes with webfinger if it wants to use that for discovery.

In principal I like the idea of having another protocol as an example.

My only concern is that I haven’t seen any discussion of your SCIM discovery document in the SCIM WG.  
I personally think sorting out discovery for SCIM is a good idea,  but OAUTh is but one of several authentication methods for SCIM, and there are probably other non OAuth things that want to be described.

I would feel better about using it as an example if it were adopted by the WG and some general interest shown.

I encourage you to do that so we can use it as a example.

John B.

> On Feb 18, 2016, at 8:35 AM, Phil Hunt <[email-masked]> wrote:
> 
>> On Feb 17, 2016, at 11:48 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Thu, 18 Feb 2016 07:06:35 -0700

Maybe SCIM was a bad example.  It functions as a RESTful resource in the context of OAuth.

I find the use of OIDC to be confusing as an example (and the default) because it is both an OAuth resource and a security service.  It is a modification of OAuth.

Start thinking about every application ever written that uses OAuth. Are we expecting 100s of thousands of these to each register?

To me, this specification is a fine specification for OIDC and it should be published there because the specification defines how to discovery OAuth and OpenID information.

Likewise you suggest it is ok for SCIM to do the same. 

How do we expect normal applications to set up and do discovery?

It seems to me that an “OAUTH” discovery spec should have a parameter to ask, I want to discover OAuth configuration for resource service X.

That still allows me to have a separate discovery service that says, tell me about resource service X itself.

BTW. I think we are FAR from Last Call on this topic.

Phil

@independentid

> On Feb 18, 2016, at 6:55 AM, John Bradley <[email-masked]> wrote:
> 
>> On Feb 18, 2016, at 8:35 AM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: John Bradley <[email-masked]>
Date: Thu, 18 Feb 2016 09:19:09 -0500

Can you clarify what you mean by “resource service x”?

Is that the RS base URI for the resource,  a specific URI that the client is requesting?

That is getting UMA ish. 

The concept of a base RS URI is a rat hole that I prefer not to go down, as it is something everyone thinks exists but like SCIM if it exists it is protocol or deployment specific.

The notion that you would send the URI you are planning on requesting to a Webfinger server to find the OAuth server, is probably going to have privacy issues.

I suspect that you need to hand back a error from the resource to say where the AS is, or have a .well-known for the RS.

RS discovery probably wants to be separate from AS discovery.  (Yes I do think we need something,  UMA rpt or something like it might be a way to go)

John B.

> On Feb 18, 2016, at 9:06 AM, Phil Hunt <[email-masked]> wrote:
> 
>> On Feb 18, 2016, at 6:55 AM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 18 Feb 2016 14:26:24 +0000

Hi Phil,

>From the RESTful perspective, it is the resource that should specify where
the client should find the configuration etc. through RFC5988.
As RFC5785 states, /.well-known/ uri is a last resort when this approach
does not work, e.g., when you cannot access the resource before knowing the
metadta.
If I read your message correctly, your use case seems to be able to be
accessed first. Then RFC5988 approach seems to work perfectly.
I am advocating oauth-meta [1] for such cases.

[1] https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-2

Nat

2016年2月18日(木) 23:06 Phil Hunt <[email-masked]>:

> I find the use of OIDC to be confusing as an example (and the default)
> because it is both an OAuth resource and a security service.  It is a
> modification of OAuth.
>
> Start thinking about every application ever written that uses OAuth. Are
> we expecting 100s of thousands of these to each register?
>
> To me, this specification is a fine specification for OIDC and it should
> be published there because the specification defines how to discovery OAuth
> and OpenID information.
>
> It seems to me that an “OAUTH” discovery spec should have a parameter to
> ask, I want to discover OAuth configuration for resource service X.
>
> www.independentid.com
> [email-masked]
> Diffrent protocols like Connect and SCIM may have different
> configurations, endpoints , keys , authentication methods, scopes etc.
>
> It should be posable to have them as one document, but forcing them to use
> one document is going to cause a explosion of claim registration for
> discovery.
>
> I think it is better for SCIM to register one well known than to have to
> register 20 claims with scim prefixes or something silly like that.
>
> Remember some of these protocols may be hosted on SaaS so there is no
> guarantee that all protocols will have the same OAuth Config.
>
> I personally think sorting out discovery for SCIM is a good idea,  but
> OAUTh is but one of several authentication methods for SCIM, and there are
> probably other non OAuth things that want to be described.
>
> Further, as a default “openid-configuration” as the default further gives
> people the impression that a plain OAuth server *is* an authentication
> server and that the normal access token received is evidence of a
> successful authentication.
>
> It would be better to point out that application may include oauth
> discovery in their discovery URI and that OAuth is an example of this. It
> might be good to include two examples.  E.g. OIDC and SCIM (as another
> referenceable example).
>
> Should be the default used when there is no known application based
> well-known application based URI discovery.
>
> Of course, the concern I raised earlier is that this approach of
> application specific URIs ends up requiring every application to make an
> IANA registration if they don’t want to use the default of “oauth2” (or
> “openid-configuration”).  Is that what the authors expect?
>
> It seemed better to me to use the webfinger syntax to allow the client to
> say “I want the designated OAuth configuration for the resource service X”
> would be a better design that avoids extensive IANA registration.
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
>
>
>
> In response to working group input, this version of the OAuth Discovery
> specification has been pared down to its essence – leaving only the
> features that are already widely deployed.  Specifically, all that remains
> is the definition of the authorization server discovery metadata document
> and the metadata values used in it.  The WebFinger discovery logic has been
> removed.  The relationship between the issuer identifier URL and the
> well-known URI path relative to it at which the discovery metadata document
> is located has also been clarified.
>
> Given that this now describes only features that are in widespread
> deployment, the editors believe that this version is ready for working
> group last call.
>
> ·       http://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>
> ·       http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html
>
>                                                           -- Mike & Nat &
> John
>
> P.S.  This notice was also posted at http://self-issued.info/?p=1544 and
> as @selfissued <https://twitter.com/selfissued>.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 18 Feb 2016 15:47:09 +0100

> BTW. I think we are FAR from Last Call on this topic.

Thanks for your feedback, Phil. As you have seen I had issued a WGLC
prior to your message based on the claim from the authors that they
believe the document is finished.

We will, of course, take all reviews into account and see where we are
with the discovery spec. I, as the shepherd, will also do my review and
I encourage many working group members to also take a look at the
document and to provide their input.

Ciao
Hannes

---

From: Phil Hunt <[email-masked]>
Date: Thu, 18 Feb 2016 07:49:05 -0700

resource service X could be any http accessible service:

* CRM
* Finance
* Payroll
* ERP
* any application on the web.

The spec seems to suggest that we use /.well-known/crm to discover OAuth config for crm.  But that may cause conflict if crm has its own discovery. Which leads us down the path of doing something like “crm-oauth”.

Then there is confusion about what host the discovery is done on.

For example, hypothetically do I do:

GET /.well-known/crm
Host: example.com

But what about the CRM’s configuration information. Is this stomping on it?

Or, what If we put the oauth configuration at the host for the crm service:
GET /.well-known/openid-configuration
Host: crm.example.com

I think the point is that there is a relationship between a protected resource and its designated OAuth service. 

The client needs to discover:
* Where is its designated resource service and what security does it use
* If it is OAuth, where is the intended OAuth configuration for that resource service instance?

Phil

@independentid

> On Feb 18, 2016, at 7:19 AM, John Bradley <[email-masked]> wrote:
> 
>> On Feb 18, 2016, at 9:06 AM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: John Bradley <[email-masked]>
Date: Thu, 18 Feb 2016 10:41:23 -0500

I suspect that the configuration well-knowns are going to be on the root domain.   You could try and get a user to put in crm.example.com, but I suspect that is not going to work.

If the app doesn’t have a specific protocol identifier then it would use the default.  

I don’t know if you can get around having some sort of app/protocol identifier configured in the app.

John B.

> On Feb 18, 2016, at 9:49 AM, Phil Hunt <[email-masked]> wrote:
> 
> Host: example.com <http://example.com/>
> 
> Host: crm.example.com <http://crm.example.com/>
> 
>> On Feb 18, 2016, at 7:19 AM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Mike Jones <[email-masked]>
Date: Thu, 18 Feb 2016 16:41:16 +0000

Let me second John’s point that OAuth configuration information and application configuration information need not be interspersed.  For instance, if the service is at https://example.com and the XYZ application is being used, then these configuration metadata documents could both be used:

·       https://example.com/.well-known/openid-configuration - OAuth configuration metadata

·       https://example.com/.well-known/xyz-configuration - XYZ configuration metadata

There’s not much point in defining a new /.well-known/oauth2.0 value, since there is no such thing as generic OAuth 2.0.  By definition, it must always be used in an application context that profiles OAuth 2.0 to enable interoperability.  The existing /.well-known/openid-configuration value works fine for this purpose.  Yes, the optics of having a different value might seem better but it comes at the cost of interoperability problems.  In my view, interop trumps optics.

To a point that George Fletcher made, WebFinger could still be used to learn the locations of these configuration metadata documents if that makes sense in the application context.  The editors took WebFinger out of the OAuth Discovery document since it isn’t always applicable.

                                                          Cheers,
                                                          -- Mike

From: John Bradley [mailto:[email-masked]]
Sent: Thursday, February 18, 2016 7:41 AM
To: Phil Hunt <[email-masked]>
Cc: Mike Jones <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

I suspect that the configuration well-knowns are going to be on the root domain.   You could try and get a user to put in crm.example.com<http://crm.example.com>, but I suspect that is not going to work.

John B.

On Feb 18, 2016, at 9:49 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

* CRM
* Finance
* Payroll
* ERP

GET /.well-known/crm
Host: example.com<http://example.com/>

Or, what If we put the oauth configuration at the host for the crm service:
GET /.well-known/openid-configuration
Host: crm.example.com<http://crm.example.com/>

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

On Feb 18, 2016, at 7:19 AM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:

That is getting UMA ish.

John B.

On Feb 18, 2016, at 9:06 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

On Feb 18, 2016, at 6:55 AM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:

John B.

On Feb 18, 2016, at 8:35 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

   Section 5<http://tools.ietf.org/html/draft-ietf-oauth-discovery-01#section-5>, despite the identifier

 GET /.well-known/scim

The use of:

 GET /.well-known/oauth2/

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

On Feb 17, 2016, at 11:48 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

The specification is available at:
•       http://tools.ietf.org/html/draft-ietf-oauth-discovery-01

An HTML-formatted version is also available at:
•       http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html

                                                          -- Mike & Nat & John

P.S.  This notice was also posted at http://self-issued.info/?p=1544 and as @selfissued<https://twitter.com/selfissued>.
_______________________________________________
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: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 18 Feb 2016 10:09:23 -0700

How does the client request the oauth configuration assigned to xyz?

The example you give appears to presume a single oauth infrastructure for all apps. 

The only way right now to have apps specific oauth is to infer the relation by the domain "xyz.example.com".  

That makes discovery more complex because there arw many more discovery locations and many more configurations to maintain. 

If example.com had separate oauth servers for services xyz and abc, how would discovery work from a single /.well-know endpoint?

Phil

> On Feb 18, 2016, at 09:41, Mike Jones <[email-masked]> wrote:
> 
>    Section 5, despite the identifier
> P.S.  This notice was also posted at http://self-issued.info/?p=1544 and as @selfissued.

---

From: Mike Jones <[email-masked]>
Date: Thu, 18 Feb 2016 17:11:52 +0000

If there were different OAuth services, they would be located at different URLs, with different .well-known documents at those URLs.

From: Phil Hunt (IDM) [mailto:[email-masked]]
Sent: Thursday, February 18, 2016 9:09 AM
To: Mike Jones <[email-masked]>
Cc: John Bradley <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

The only way right now to have apps specific oauth is to infer the relation by the domain "xyz.example.com<http://xyz.example.com>".

If example.com<http://example.com> had separate oauth servers for services xyz and abc, how would discovery work from a single /.well-know endpoint?

Phil

On Feb 18, 2016, at 09:41, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Let me second John’s point that OAuth configuration information and application configuration information need not be interspersed.  For instance, if the service is at https://example.com and the XYZ application is being used, then these configuration metadata documents could both be used:

                                                          Cheers,
                                                          -- Mike

From: John Bradley [mailto:[email-masked]]
Sent: Thursday, February 18, 2016 7:41 AM
To: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

John B.

* CRM
* Finance
* Payroll
* ERP

GET /.well-known/crm

Phil

@independentid

That is getting UMA ish.

John B.

Phil

@independentid

John B.

 GET /.well-known/scim

The use of:

 GET /.well-known/oauth2/

Phil

@independentid

                                                          -- Mike & Nat & John

---

From: John Bradley <[email-masked]>
Date: Thu, 18 Feb 2016 12:21:56 -0500

The protocol would need to have a .well-known location registered or use the default well-known for OAuth.

Apps would look for there specific configuration and fall back to the generic one if that is not available.

To save apps making multiple request the server can just link the  app specific well-knowns  to the OAuth well-known.

I don’t know of a OAuth app that doesn’t have preconfigured logic about the API it is using.  
Part of that pre configuration should be what well-known file to look for if required.

Also nothing stops enterprises from making up there own well-known locations for specific apps.

Also it would be up to app /api developers to register a well known for oauth and one for whatever else they need to configure, or if it is a small amount of info they could extend the OAuth discovery registry with a resource URI location for the protocol etc.

John B.

> On Feb 18, 2016, at 12:09 PM, Phil Hunt (IDM) <[email-masked]> wrote:
> 
> The only way right now to have apps specific oauth is to infer the relation by the domain "xyz.example.com <http://xyz.example.com/>".  
> 
> If example.com <http://example.com/> had separate oauth servers for services xyz and abc, how would discovery work from a single /.well-know endpoint?
> 
> Phil
> 
> On Feb 18, 2016, at 09:41, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Let me second John’s point that OAuth configuration information and application configuration information need not be interspersed.  For instance, if the service is at https://example.com <https://example.com/> and the XYZ application is being used, then these configuration metadata documents could both be used:
>> ·       https://example.com/.well-known/openid-configuration <https://example.com/.well-known/openid-configuration> - OAuth configuration metadata
>> ·       https://example.com/.well-known/xyz-configuration <https://example.com/.well-known/xyz-configuration> - XYZ configuration metadata
>>  
>>   <>
>> From: John Bradley [mailto:[email-masked] <mailto:[email-masked]>] 
>> To: Phil Hunt <[email-masked] <mailto:[email-masked]>>
>> Cc: Mike Jones <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> I suspect that the configuration well-knowns are going to be on the root domain.   You could try and get a user to put in crm.example.com <http://crm.example.com/>, but I suspect that is not going to work.
>>  
>> On Feb 18, 2016, at 9:49 AM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> www.independentid.com <http://www.independentid.com/>
>> [email-masked] <mailto:[email-masked]>
>>  
>>  
>>  
>> 
>>  
>> www.independentid.com <http://www.independentid.com/>
>> [email-masked] <mailto:[email-masked]>
>>  
>>  
>>  
>> 
>>  
>> www.independentid.com <http://www.independentid.com/>
>> [email-masked] <mailto:[email-masked]>
>>  
>>  
>>  
>> 
>>

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 18 Feb 2016 18:12:55 +0000

I also think we are way far from last call (and surprised to see last call issued) on this document as it is still very complex for something that should be very simple 

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, February 18, 2016 6:47 AM
To: Phil Hunt <[email-masked]>; John Bradley <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

> BTW. I think we are FAR from Last Call on this topic.

Thanks for your feedback, Phil. As you have seen I had issued a WGLC prior to your message based on the claim from the authors that they believe the document is finished.

We will, of course, take all reviews into account and see where we are with the discovery spec. I, as the shepherd, will also do my review and I encourage many working group members to also take a look at the document and to provide their input.

Ciao
Hannes

---

From: Mike Jones <[email-masked]>
Date: Thu, 18 Feb 2016 18:17:49 +0000

It's the OAuth-specific subset of what's already widely deployed.  Nothing was invented - just subsetted.

I think it's already as simple as possible unless the working group decides to remove even more functionality (which it can obviously do).

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, February 18, 2016 6:47 AM
To: Phil Hunt <[email-masked]>; John Bradley <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

Ciao
Hannes

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 18 Feb 2016 18:27:23 +0000

Not sure about that. There are things that are "recommended" like the dynamic registration endpoint, I don't understand why this is recommended as a lot of folks still don't do this. There are security considerations about all the information that is in the discovery that have not been addressed.

-----Original Message-----
From: Mike Jones 
Sent: Thursday, February 18, 2016 10:18 AM
To: Anthony Nadalin <[email-masked]>; Hannes Tschofenig <[email-masked]>; Phil Hunt <[email-masked]>; John Bradley <[email-masked]>
Cc: [email-masked]
Subject: RE: [OAUTH-WG] OAuth Discovery spec pared down to its essence

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, February 18, 2016 6:47 AM
To: Phil Hunt <[email-masked]>; John Bradley <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Thu, 18 Feb 2016 13:32:52 -0500

We are establishing a registry.  Some folks do use dynamic client registration.   

We can register it in this document or take it out and let others register it once the registry is established.

It will be registered one way or the other.  

One of the reasons for starting last call is to get people to read the draft and comment. 
That seems to be working.

If you have specific security considerations, please let us know so they can be addressed.   Text is always appreciated.

John B.

> On Feb 18, 2016, at 1:27 PM, Anthony Nadalin <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 18 Feb 2016 18:42:20 +0000

I'm fine with changing dynamic registration from being RECOMMENDED to OPTIONAL.  That's good actionable feedback.  Likewise, looking at again, we also need to change jwks_uri from REQUIRED to OPTIONAL, since not all OAuth deployments need keys.

I expect more good, actionable feedback to also come from the WGLC as people carefully read the draft with fresh eyes.

				-- Mike

-----Original Message-----
From: John Bradley [mailto:[email-masked]] 
Sent: Thursday, February 18, 2016 10:33 AM
To: Anthony Nadalin <[email-masked]>
Cc: Mike Jones <[email-masked]>; Hannes Tschofenig <[email-masked]>; Phil Hunt <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

John B.

---

From: William Denniss <[email-masked]>
Date: Thu, 18 Feb 2016 11:27:56 -0800

Two review comments:

1.
Can the text in "Section 2.  Authorization Server Metadata" near the end
regarding additional metadata be expanded? I think we should reference the
IANA registry established by this spec in that section (as this will be the
reference point for people looking for other registered metadata), and
possibly mention something about registered vs unregistered parameters and
interoperability. At present if you only read that section it is a little
vague.

I like the treatment of claims in the JWT spec
https://tools.ietf.org/html/rfc7519#section-4.2, splitting into 3
groups: registered, public and private. Not saying we should mirror it
exactly, but as an implementer I liked how clearly it was stated in
that spec.

2.
Since this doc is in WG Last call, do we need to remove the reference to
the mix-up I-D (Section 2, "issuer"), or are we expecting them to be
finalized together?

On Thu, Feb 18, 2016 at 10:42 AM, Mike Jones <[email-masked]>
wrote:

> I'm fine with changing dynamic registration from being RECOMMENDED to
> OPTIONAL.  That's good actionable feedback.  Likewise, looking at again, we
> also need to change jwks_uri from REQUIRED to OPTIONAL, since not all OAuth
> deployments need keys.
>
> I expect more good, actionable feedback to also come from the WGLC as
> people carefully read the draft with fresh eyes.
>
>                                 -- Mike
>
> Cc: Mike Jones <[email-masked]>; Hannes Tschofenig <
> [email-masked]>; Phil Hunt <[email-masked]>;
> [email-masked]
> If you have specific security considerations, please let us know so they
> can be addressed.   Text is always appreciated.
>
> John B.
>
> > Not sure about that. There are things that are "recommended" like the
> dynamic registration endpoint, I don't understand why this is recommended
> as a lot of folks still don't do this. There are security considerations
> about all the information that is in the discovery that have not been
> addressed.
> >
> > To: Anthony Nadalin <[email-masked]>; Hannes Tschofenig <
> [email-masked]>; Phil Hunt <[email-masked]>; John
> Bradley <[email-masked]>
> > Cc: [email-masked]
> > I think it's already as simple as possible unless the working group
> decides to remove even more functionality (which it can obviously do).
> >
> >                               -- Mike
> >
> > To: Hannes Tschofenig <[email-masked]>; Phil Hunt <
> [email-masked]>; John Bradley <[email-masked]>
> > Cc: [email-masked]
> > I also think we are way far from last call (and surprised to see last
> call issued) on this document as it is still very complex for something
> that should be very simple
> >
> prior to your message based on the claim from the authors that they believe
> the document is finished.
> >
> with the discovery spec. I, as the shepherd, will also do my review and I
> encourage many working group members to also take a look at the document
> and to provide their input.
> >
> > Ciao
> > Hannes
> >

---

From: Mike Jones <[email-masked]>
Date: Thu, 18 Feb 2016 19:36:40 +0000

Thanks, William.  I’m good with referencing the registry in Section 2.  I’ll think about the registered/public/private comment.

It’s fine to reference oauth-mix-up-mitigation as a draft in a finished RFC as long as it’s an informative and not a normative reference.

                                                          -- Mike

From: William Denniss [mailto:[email-masked]]
Sent: Thursday, February 18, 2016 11:28 AM
To: Mike Jones <[email-masked]>
Cc: John Bradley <[email-masked]>; Anthony Nadalin <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

Two review comments:

1.
Can the text in "Section 2.  Authorization Server Metadata" near the end regarding additional metadata be expanded? I think we should reference the IANA registry established by this spec in that section (as this will be the reference point for people looking for other registered metadata), and possibly mention something about registered vs unregistered parameters and interoperability. At present if you only read that section it is a little vague.

I like the treatment of claims in the JWT spec https://tools.ietf.org/html/rfc7519#section-4.2, splitting into 3 groups: registered, public and private. Not saying we should mirror it exactly, but as an implementer I liked how clearly it was stated in that spec.

2.
Since this doc is in WG Last call, do we need to remove the reference to the mix-up I-D (Section 2, "issuer"), or are we expecting them to be finalized together?

On Thu, Feb 18, 2016 at 10:42 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I'm fine with changing dynamic registration from being RECOMMENDED to OPTIONAL.  That's good actionable feedback.  Likewise, looking at again, we also need to change jwks_uri from REQUIRED to OPTIONAL, since not all OAuth deployments need keys.

                                -- Mike

-----Original Message-----
From: John Bradley [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, February 18, 2016 10:33 AM
To: Anthony Nadalin <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; Phil Hunt <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

John B.

> On Feb 18, 2016, at 1:27 PM, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:
>
> To: Anthony Nadalin <[email-masked]<mailto:[email-masked]>>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; Phil Hunt <[email-masked]<mailto:[email-masked]>>; John Bradley <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>
> From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Anthony Nadalin
> To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; Phil Hunt <[email-masked]<mailto:[email-masked]>>; John Bradley <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>
> From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Hannes Tschofenig
> To: Phil Hunt <[email-masked]<mailto:[email-masked]>>; John Bradley <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>

---

From: William Denniss <[email-masked]>
Date: Thu, 18 Feb 2016 11:42:56 -0800

On Thu, Feb 18, 2016 at 11:36 AM, Mike Jones <[email-masked]>
wrote:

> Thanks, William.  I’m good with referencing the registry in Section 2.
>

Great!

> I’ll think about the registered/public/private comment.
>
>
I'm not suggesting we necessarily have to use the same
registered/public/private structure, only that some discussion of
standardized vs non-standard could be helpful for implementers (e.g. try to
pick something that is collision resistant for proprietary metadata).

> It’s fine to reference oauth-mix-up-mitigation as a draft in a finished
> RFC as long as it’s an informative and not a normative reference.
>

Ah ok, I wasn't aware of that.

> *From:* William Denniss [mailto:[email-masked]]
>
> *Sent:* Thursday, February 18, 2016 11:28 AM
> *To:* Mike Jones <[email-masked]>
> *Cc:* John Bradley <[email-masked]>; Anthony Nadalin <
> [email-masked]>; [email-masked]
>
> *Subject:* Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
>
>
>
> Two review comments:
>
>
>
> 1.
>

---

From: "Nat Sakimura" <[email-masked]>
Date: Fri, 19 Feb 2016 11:04:52 +0900

Hi Phil, 

You wrote: 

> If  <http://example.com> example.com had separate oauth servers for services xyz and abc, 

> how would discovery work from a single /.well-known endpoint?

I am trying to understand your use case, but I am not sure if I do. 

The use case seems to be such that: 

-        There is a client C1. It could be a CRM or any kind of application that uses RFC6749 and RFC6750 to access other resources a resource server R1. C1 and R1 has a pre-configured relationship. 

-        The resource server R1 supports RFC6750, and can have multiple OAuth RFC6749 endpoints that it supports, which are A1, …, An. 

-        Ax supports multiple resource services, Rx. 

-        There is a user U1 that wants to access C1, which in turn access R1. U1 gets authenticated somehow at C1. It could be either through a password system at C1, or through a federated login protocol supported at Ax, such as OpenID Connect. 

Another possibility is a case where Cx = Rx, which makes things a bit simpler. 

Is this what you have in mind? Please let me know. If it is not, please correct me.

Cheers, 

Nat

--

PLEASE READ :This e-mail is confidential and intended for the

named recipient only. If you are not an intended recipient,

please notify the sender  and delete this e-mail.

From: OAuth [mailto:[email-masked]] On Behalf Of Phil Hunt (IDM)
Sent: Friday, February 19, 2016 2:09 AM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

If example.com <http://example.com>  had separate oauth servers for services xyz and abc, how would discovery work from a single /.well-know endpoint?

Phil

On Feb 18, 2016, at 09:41, Mike Jones <[email-masked] <mailto:[email-masked]> > wrote:

*       https://example.com/.well-known/openid-configuration - OAuth configuration metadata

*       https://example.com/.well-known/xyz-configuration - XYZ configuration metadata

                                                          Cheers,

                                                          -- Mike

From: John Bradley [mailto:[email-masked]] 
Sent: Thursday, February 18, 2016 7:41 AM
To: Phil Hunt <[email-masked] <mailto:[email-masked]> >
Cc: Mike Jones <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

I suspect that the configuration well-knowns are going to be on the root domain.   You could try and get a user to put in crm.example.com <http://crm.example.com> , but I suspect that is not going to work.

John B.

 

On Feb 18, 2016, at 9:49 AM, Phil Hunt <[email-masked] <mailto:[email-masked]> > wrote:

* CRM

* Finance

* Payroll

* ERP

GET /.well-known/crm

Phil

@independentid

 

On Feb 18, 2016, at 7:19 AM, John Bradley <[email-masked] <mailto:[email-masked]> > wrote:

That is getting UMA ish. 

John B.

On Feb 18, 2016, at 9:06 AM, Phil Hunt <[email-masked] <mailto:[email-masked]> > wrote:

Phil

@independentid

 

On Feb 18, 2016, at 6:55 AM, John Bradley <[email-masked] <mailto:[email-masked]> > wrote:

John B.

On Feb 18, 2016, at 8:35 AM, Phil Hunt <[email-masked] <mailto:[email-masked]> > wrote:

   Section 5 <http://tools.ietf.org/html/draft-ietf-oauth-discovery-01#section-5> , despite the identifier

and

 GET /.well-known/scim

The use of:

 GET /.well-known/oauth2/

Phil

@independentid

 

On Feb 17, 2016, at 11:48 PM, Mike Jones <[email-masked] <mailto:[email-masked]> > wrote:

*        <http://tools.ietf.org/html/draft-ietf-oauth-discovery-01> http://tools.ietf.org/html/draft-ietf-oauth-discovery-01

*        <http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html> http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html

                                                          -- Mike & Nat & John

P.S.  This notice was also posted at  <http://self-issued.info/?p=1544> http://self-issued.info/?p=1544 and as  <https://twitter.com/selfissued> @selfissued.

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

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 18 Feb 2016 21:57:46 -0700

No. Much simpler. 

A service provider has decided to have a separate oauth server for each web 'property'. This could be because they were acquired separately and run different infrastructures. Or the business structure keeps each BU completely separate. 

The client can't really depend on previously known or hard coded endpoints because there are 1000s of instances deployed (eg as in tenancies). 

This dynamic discovery is going to be particularly true of open source software that customers choose to host on PaaS cloud providers of their choosing. 

Phil

> On Feb 18, 2016, at 19:04, Nat Sakimura <[email-masked]> wrote:
> 
> Hi Phil,
>  
> You wrote:
> > If example.com had separate oauth servers for services xyz and abc,

---

From: "Nat Sakimura" <[email-masked]>
Date: Fri, 19 Feb 2016 14:19:33 +0900

Thanks for the explanation. Let me re-formulate. 

Assumption

1.     There are resource server – authorization server pairs: R1A1 … RnAn. 

2.     There are clients C1 … Cm. 

3.     These instances can be hosted on a multi-tenancy environment. 

Flow

1.     Client Cx goes to a resource server Ry, but he was denied of the access and was told to get an access token. Now Cx needs to know where to go. 

2.     Cx uses << Discovery>> to find the OAuth endpoints and the associated metadata on Ay that corresponds to Ry. 

3.     Cx goes and fetches the Discovery file. 

4.     Cx goes to Ay to get authorized using the config info in the Discovery file and the rest is normal RFC6749. 

Is this correct? 

Nat

--

From: Phil Hunt (IDM) [mailto:[email-masked]] 
Sent: Friday, February 19, 2016 1:58 PM
To: Nat Sakimura
Cc: Mike Jones; [email-masked]
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

No. Much simpler. 

Phil

On Feb 18, 2016, at 19:04, Nat Sakimura <[email-masked] <mailto:[email-masked]> > wrote:

Hi Phil, 

You wrote: 

> If example.com <http://example.com>  had separate oauth servers for services xyz and abc, 

Cheers, 

Nat

--

From: OAuth [mailto:[email-masked]] On Behalf Of Phil Hunt (IDM)
Sent: Friday, February 19, 2016 2:09 AM
To: Mike Jones
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

The only way right now to have apps specific oauth is to infer the relation by the domain "xyz.example.com <http://xyz.example.com> ".  

Phil

                                                          Cheers,

                                                          -- Mike

John B.

 

* CRM

* Finance

* Payroll

* ERP

GET /.well-known/crm

Phil

@independentid

 

That is getting UMA ish. 

John B.

Phil

@independentid

 

John B.

and

 GET /.well-known/scim

The use of:

 GET /.well-known/oauth2/

Phil

@independentid

 

                                                          -- Mike & Nat & John

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 18 Feb 2016 22:57:38 -0700

Inline...

Phil

> On Feb 18, 2016, at 22:19, Nat Sakimura <[email-masked]> wrote:
> 

> 3.     These instances can be hosted on a multi-tenancy environment.
Step 0. The client discovers the resource server endpoint and its configs. 
Question: should that include oauth?? John seems to imply yes. 
> 2.     Cx uses << Discovery>> to find the OAuth endpoints and the associated metadata on Ay that corresponds to Ry.
Where is the discovery for Ay?
> 4.     Cx goes to Ay to get authorized using the config info in the Discovery file and the rest is normal RFC6749.

Referring to the risk that a client discovered from a bad source (eg to insert a fake token endpoint), how does Ay know what discovery the client used was correct?  This might not be a problem in reality but it needs to work.

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 19 Feb 2016 06:30:25 +0000

> Step 0. The client discovers the resource server endpoint and its configs.

Sure, but that's out of scope, is it not? If I am not mistaken, we are
talking about OAuth server configuration discovery. I do agree that
resource discovery in itself is a very interesting and important work which
I would love to work on, but that is not what we are talking about here, I
think.

> Question: should that include oauth?? John seems to imply yes.

I do not think so. I think he was referring to the configuration of Ay that
corresponds to Ry. John?

> 1.     Client Cx goes to a resource server Ry, but he was denied of the
> access and was told to get an access token. Now Cx needs to know where to
> go.
>
> 2.     Cx uses << Discovery>> to find the OAuth endpoints and the
> associated metadata on Ay that corresponds to Ry.
>
I was just trying to understand your use case. I have not put any solution
into it. That's why I marked discovery as <<Discovery>>.

The default one that the draft suggest is the https://authority
(uri(Ay))/.well-known/openid-configuration.
What John is suggesting is that we could also have
https://authority(uri(Ay))/.well-known/oauth-config-for-Ry, if I read his
message correctly.

> 4.     Cx goes to Ay to get authorized using the config info in the
> Discovery file and the rest is normal RFC6749.
>
>
> Referring to the risk that a client discovered from a bad source (eg to
> insert a fake token endpoint), how does Ay know what discovery the client
> used was correct?  This might not be a problem in reality but it needs to
> work.
>
> Right. We are currently asking the clients to be sane enough to get the
configuration for the server directly over https at the authorization
server, more or less. When Ay gets an authorization request, it has no way
of knowing that the client got the config from the right endpoint. Are you
suggesting something like have the client send the signature of the config
file that it is using now?

> *From:* Phil Hunt (IDM) [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Friday, February 19, 2016 1:58 PM
> *To:* Nat Sakimura
> *Cc:* Mike Jones; [email-masked]
> A service provider has decided to have a separate oauth server for each
> web 'property'. This could be because they were acquired separately and run
> different infrastructures. Or the business structure keeps each BU
> completely separate.
>
>
>
> The client can't really depend on previously known or hard coded endpoints
> because there are 1000s of instances deployed (eg as in tenancies).
>
>
>
> This dynamic discovery is going to be particularly true of open source
> software that customers choose to host on PaaS cloud providers of their
> choosing.
>
>
> Phil
>
>
> -       There is a client C1. It could be a CRM or any kind of
> application that uses RFC6749 and RFC6750 to access other resources a
> resource server R1. C1 and R1 has a pre-configured relationship.
>
> -       The resource server R1 supports RFC6750, and can have multiple
> OAuth RFC6749 endpoints that it supports, which are A1, …, An.
>
> -       There is a user U1 that wants to access C1, which in turn access
> R1. U1 gets authenticated somehow at C1. It could be either through a
> password system at C1, or through a federated login protocol supported at
> Ax, such as OpenID Connect.
>
>
>
> *From:* OAuth [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Phil Hunt (IDM)
> *Sent:* Friday, February 19, 2016 2:09 AM
> *To:* Mike Jones
> *Cc:* [email-masked]
> The only way right now to have apps specific oauth is to infer the
> relation by the domain "xyz.example.com".
>
>
>
> That makes discovery more complex because there arw many more discovery
> locations and many more configurations to maintain.
>
>
>
> If example.com had separate oauth servers for services xyz and abc, how
> would discovery work from a single /.well-know endpoint?
>
>
> Phil
>
>
> Let me second John’s point that OAuth configuration information and
> application configuration information need not be interspersed.  For
> instance, if the service is at https://example.com and the XYZ
> application is being used, then these configuration metadata documents
> could both be used:
>
> There’s not much point in defining a new /.well-known/oauth2.0 value,
> since there is no such thing as generic OAuth 2.0.  By definition, it must
> always be used in an application context that profiles OAuth 2.0 to enable
> interoperability.  The existing /.well-known/openid-configuration value
> works fine for this purpose.  Yes, the optics of having a different value
> might seem better but it comes at the cost of interoperability problems.
> In my view, interop trumps optics.
>
>
>
> To a point that George Fletcher made, WebFinger could still be used to
> learn the locations of these configuration metadata documents if that makes
> sense in the application context.  The editors took WebFinger out of the
> OAuth Discovery document since it isn’t always applicable.
>
>
>
>                                                           Cheers,
>
>                                                           -- Mike
>
>
>
> *From:* John Bradley [mailto:[email-masked] <[email-masked]>]
> *Sent:* Thursday, February 18, 2016 7:41 AM
> *To:* Phil Hunt <[email-masked]>
> *Cc:* Mike Jones <[email-masked]>; [email-masked]
> I suspect that the configuration well-knowns are going to be on the root
> domain.   You could try and get a user to put in crm.example.com, but I
> suspect that is not going to work.
>
>
>
> The spec seems to suggest that we use /.well-known/crm to discover OAuth
> config for crm.  But that may cause conflict if crm has its own discovery.
> Which leads us down the path of doing something like “crm-oauth”.
>
>
>
> I think the point is that there is a relationship between a protected
> resource and its designated OAuth service.
>
>
>
> The concept of a base RS URI is a rat hole that I prefer not to go down,
> as it is something everyone thinks exists but like SCIM if it exists it is
> protocol or deployment specific.
>
>
>
> The notion that you would send the URI you are planning on requesting to a
> Webfinger server to find the OAuth server, is probably going to have
> privacy issues.
>
>
>
> I suspect that you need to hand back a error from the resource to say
> where the AS is, or have a .well-known for the RS.
>
>
>
> RS discovery probably wants to be separate from AS discovery.  (Yes I do
> think we need something,  UMA rpt or something like it might be a way to go)
>
>
>
> John B.
>
>
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 19 Feb 2016 07:39:30 -0700

Step 0 is  something we need to discuss. 

An OAuth protected resource can be hacked if a client uses an evil discovery and it returns a proxied resource server.  Just as a token server can be proxied, so can a resource server.  So the OAuth server may be issuing tokens in a secure way, but then it gives it to a client that uses them at the wrong endpoint.

I believe the resource and the As must be bound together in a security relationship. The security descriptor needs to reflect this.

I am ok with separate app data discovery.  But from the oauth security perspective, the oauth server needs to indicate that it is the correct server to use for Rx.

There are probably multiple ways to do this, but I think the discovery draft has only addressed 2 of 3 endpoints.  We need all of them bound together.

@independentid

> On Feb 18, 2016, at 11:30 PM, Nat Sakimura <[email-masked]> wrote:
> 
> 
> 
> 2016年2月19日(金) 14:58 Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>>:
> Inline...
> 
> Phil
> 
> On Feb 18, 2016, at 22:19, Nat Sakimura <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Thanks for the explanation. Let me re-formulate.  <>
>>  
>> 
>> Assumption
>> 
> 
> 
> Sure, but that's out of scope, is it not? If I am not mistaken, we are talking about OAuth server configuration discovery. I do agree that resource discovery in itself is a very interesting and important work which I would love to work on, but that is not what we are talking about here, I think.  
>  
> I do not think so. I think he was referring to the configuration of Ay that corresponds to Ry. John?  
> I was just trying to understand your use case. I have not put any solution into it. That's why I marked discovery as <<Discovery>>.  
> 
> The default one that the draft suggest is the https://authority <https://authority/>(uri(Ay))/.well-known/openid-configuration. 
> What John is suggesting is that we could also have https://authority(uri(Ay))/.well-known/oauth-config-for-Ry <https://authority(uri(Ay))/.well-known/oauth-config-for-Ry>, if I read his message correctly. 
> 
> 
> Right. We are currently asking the clients to be sane enough to get the configuration for the server directly over https at the authorization server, more or less. When Ay gets an authorization request, it has no way of knowing that the client got the config from the right endpoint. Are you suggesting something like have the client send the signature of the config file that it is using now? 
>>  
>> 
>> Is this correct? 
>> 
>>  
>> 
>> Nat
>> 
>>  
>> 
>> --
>> 
>> From: Phil Hunt (IDM) [mailto:[email-masked] <mailto:[email-masked]>] 
>> Cc: Mike Jones; [email-masked] <mailto:[email-masked]>
>> On Feb 18, 2016, at 19:04, Nat Sakimura <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Phil, 
>> 
>>  
>> 
>> You wrote: 
>> 
>> > If example.com <http://example.com/> had separate oauth servers for services xyz and abc, 
>> 
>> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Phil Hunt (IDM)
>> ·http://tools.ietf.org/html/draft-ietf-oauth-discovery-01 <http://tools.ietf.org/html/draft-ietf-oauth-discovery-01>
>>  
>> 
>> ·http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html <http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html>
>>  
>> 
>>   -- Mike & Nat & John
>> 
>>  
>> 
>> P.S. This notice was also posted athttp://self-issued.info/?p=1544 <http://self-issued.info/?p=1544>and as@selfissued <https://twitter.com/selfissued>.
>>