Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[George Fletcher]

I'm fine with this clarification as it is more correctly describes the 
purpose of the document.


Thanks,
George

On 2/29/16 5:34 PM, Brian Campbell wrote:

+1 for "OAuth 2.0 Authorization Server Discovery” from those two options.

But what about "OAuth 2.0 Authorization Server Metadata”?

The document in its current scope (which I agree with, BTW) isn't 
really about discovery so much as about describing the metadata at 
some well-known(ish) resource.




On Sat, Feb 27, 2016 at 10:48 AM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:


It’s clear that people want us to move to the name “OAuth 2.0
Authorization Server Discovery”. The editors will plan to make
that change in the draft addressing Working Group Last Call comments.

Thanks all,

-- Mike

*From:*Samuel Erdtman [mailto:sam...@erdtman.se
<mailto:sam...@erdtman.se>]
*Sent:* Saturday, February 27, 2016 6:47 AM
*To:* Mike Jones mailto:michael.jo...@microsoft.com>>
*Cc:* Vladimir Dzhuvinov mailto:vladi...@connect2id.com>>; oauth@ietf.org
<mailto:oauth@ietf.org>


*Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location

+1 for “OAuth 2.0 Authorization Server Discovery”

//Samuel

On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones
mailto:michael.jo...@microsoft.com>>
wrote:

Thanks for your thoughts, Vladimir.  I’m increasingly inclined
to accept your suggestion to change the title from “OAuth 2.0
Discovery” to “OAuth 2.0 Authorization Server Discovery”.
While the abstract already makes it clear that the scope of
the document is AS discovery, doing so in the title seems like
it could help clarify things, given that a lot of the
discussion seems to be about resource discovery, which is out
of scope of the document.

I’m not saying that resource discovery isn’t important – it is
– but unlike authorization server discovery, where there’s
lots of existing practice, including using the existing data
format for describing OAuth implementations that aren’t being
used with OpenID Connect, there’s no existing practice to
standardize for resource discovery. The time to create a
standard for that seems to be after existing practice has
emerged.  It **might** or might not use new metadata values in
the AS discovery document, but that’s still to be determined. 
The one reason to leave the title as-is is that resource

discovery might end up involving extensions to this metadata
format in some cases.

I think an analogy to the core OAuth documents RFC 6749 and
RFC 6750 applies.  6749 is about the AS. 6750 is about the
RS.  The discovery document is about the AS.  We don’t yet
have a specification or existing practice for RS discovery,
which would be the 6750 analogy.

In summary, which title do people prefer?

·“OAuth 2.0 Discovery”

·“OAuth 2.0 Authorization Server Discovery”







___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Thomas Broyer]

On Mon, Feb 29, 2016 at 11:35 PM Brian Campbell 
wrote:

> +1 for "OAuth 2.0 Authorization Server Discovery” from those two options.
>
> But what about "OAuth 2.0 Authorization Server Metadata”?
>
> The document in its current scope (which I agree with, BTW) isn't really
> about discovery so much as about describing the metadata at some
> well-known(ish) resource.
>

+1

(in case that wasn't obvious already by my previous mails)
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Vladimir Dzhuvinov]

On 01/03/16 00:34, Brian Campbell wrote:
> +1 for "OAuth 2.0 Authorization Server Discovery” from those two options.
>
> But what about "OAuth 2.0 Authorization Server Metadata”?
>
> The document in its current scope (which I agree with, BTW) isn't really
> about discovery so much as about describing the metadata at some
> well-known(ish) resource.

This sounds even more precise. The updated draft no longer mentions how
the client arrives at the AS metadata URL, just its format and
parameters. So the discovery bit is essentially gone from it.

Because if we take the OIDC definition of discovery, then

"OpenID Provider Issuer discovery is the process of determining the
location of the OpenID Provider."

(from
http://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery )

So the draft has been reduced to mimicking sections 3 and 4 of OIDC
Discovery:

3.  OpenID Provider Metadata ->
http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata
4.  Obtaining OpenID Provider Configuration Information ->
http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig

I would like to vote for "OAuth 2.0 Authorization Server Metadata”


Cheers,

Vladimir


> On Sat, Feb 27, 2016 at 10:48 AM, Mike Jones 
> wrote:
>
>> It’s clear that people want us to move to the name “OAuth 2.0
>> Authorization Server Discovery”.  The editors will plan to make that
>> change in the draft addressing Working Group Last Call comments.
>>
>>
>>
>>   Thanks all,
>>
>>   -- Mike
>>
>>
>>
>> *From:* Samuel Erdtman [mailto:sam...@erdtman.se]
>> *Sent:* Saturday, February 27, 2016 6:47 AM
>> *To:* Mike Jones 
>> *Cc:* Vladimir Dzhuvinov ; oauth@ietf.org
>>
>> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>>
>>
>> +1 for “OAuth 2.0 Authorization Server Discovery”
>>
>>
>>
>> //Samuel
>>
>>
>>
>> On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones 
>> wrote:
>>
>> Thanks for your thoughts, Vladimir.  I’m increasingly inclined to accept
>> your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth
>> 2.0 Authorization Server Discovery”.  While the abstract already makes it
>> clear that the scope of the document is AS discovery, doing so in the title
>> seems like it could help clarify things, given that a lot of the discussion
>> seems to be about resource discovery, which is out of scope of the document.
>>
>>
>>
>> I’m not saying that resource discovery isn’t important – it is – but
>> unlike authorization server discovery, where there’s lots of existing
>> practice, including using the existing data format for describing OAuth
>> implementations that aren’t being used with OpenID Connect, there’s no
>> existing practice to standardize for resource discovery.  The time to
>> create a standard for that seems to be after existing practice has
>> emerged.  It **might** or might not use new metadata values in the AS
>> discovery document, but that’s still to be determined.  The one reason to
>> leave the title as-is is that resource discovery might end up involving
>> extensions to this metadata format in some cases.
>>
>>
>>
>> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750
>> applies.  6749 is about the AS.  6750 is about the RS.  The discovery
>> document is about the AS.  We don’t yet have a specification or existing
>> practice for RS discovery, which would be the 6750 analogy.
>>
>>
>>
>> In summary, which title do people prefer?
>>
>> ·   “OAuth 2.0 Discovery”
>>
>> ·   “OAuth 2.0 Authorization Server Discovery”
>>
>>
>>
>>  
>>
>>
>>
>>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Roland Hedberg]

+1 

> 29 feb. 2016 kl. 15:41 skrev Brian Campbell :
> 
> +1 
> 
> On Fri, Feb 19, 2016 at 9:28 PM, Vladimir Dzhuvinov  > wrote:
> +1
> 
> On 19/02/16 23:59, Justin Richer wrote:
> > The newly-trimmed OAuth Discovery document is helpful and moving in the 
> > right direction. It does, however, still have too many vestiges of its 
> > OpenID Connect origins. One issue in particular still really bothers me: 
> > the use of “/.well-known/openid-configuration” in the discovery portion. Is 
> > this an OAuth discovery document, or an OpenID Connect one? There is 
> > absolutely no compelling reason to tie the URL to the OIDC discovery 
> > mechanism.
> >
> > I propose that we use “/.well-known/oauth-authorization-server” as the 
> > default discovery location, and state that the document MAY also be 
> > reachable from “/.well-known/openid-configuration” if the server also 
> > provides OpenID Connect on the same domain. Other applications SHOULD use 
> > the same parameter names to describe OAuth endpoints and functions inside 
> > their service-specific discovery document.
> >
> >  — Justin
> > ___
> > OAuth mailing list
> > OAuth@ietf.org 
> > https://www.ietf.org/mailman/listinfo/oauth 
> > 
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Brian Campbell]

+1

On Fri, Feb 19, 2016 at 9:28 PM, Vladimir Dzhuvinov  wrote:

> +1
>
> On 19/02/16 23:59, Justin Richer wrote:
> > The newly-trimmed OAuth Discovery document is helpful and moving in the
> right direction. It does, however, still have too many vestiges of its
> OpenID Connect origins. One issue in particular still really bothers me:
> the use of “/.well-known/openid-configuration” in the discovery portion. Is
> this an OAuth discovery document, or an OpenID Connect one? There is
> absolutely no compelling reason to tie the URL to the OIDC discovery
> mechanism.
> >
> > I propose that we use “/.well-known/oauth-authorization-server” as the
> default discovery location, and state that the document MAY also be
> reachable from “/.well-known/openid-configuration” if the server also
> provides OpenID Connect on the same domain. Other applications SHOULD use
> the same parameter names to describe OAuth endpoints and functions inside
> their service-specific discovery document.
> >
> >  — Justin
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Brian Campbell]

+1 for "OAuth 2.0 Authorization Server Discovery” from those two options.

But what about "OAuth 2.0 Authorization Server Metadata”?

The document in its current scope (which I agree with, BTW) isn't really
about discovery so much as about describing the metadata at some
well-known(ish) resource.



On Sat, Feb 27, 2016 at 10:48 AM, Mike Jones 
wrote:

> It’s clear that people want us to move to the name “OAuth 2.0
> Authorization Server Discovery”.  The editors will plan to make that
> change in the draft addressing Working Group Last Call comments.
>
>
>
>   Thanks all,
>
>   -- Mike
>
>
>
> *From:* Samuel Erdtman [mailto:sam...@erdtman.se]
> *Sent:* Saturday, February 27, 2016 6:47 AM
> *To:* Mike Jones 
> *Cc:* Vladimir Dzhuvinov ; oauth@ietf.org
>
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> +1 for “OAuth 2.0 Authorization Server Discovery”
>
>
>
> //Samuel
>
>
>
> On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones 
> wrote:
>
> Thanks for your thoughts, Vladimir.  I’m increasingly inclined to accept
> your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth
> 2.0 Authorization Server Discovery”.  While the abstract already makes it
> clear that the scope of the document is AS discovery, doing so in the title
> seems like it could help clarify things, given that a lot of the discussion
> seems to be about resource discovery, which is out of scope of the document.
>
>
>
> I’m not saying that resource discovery isn’t important – it is – but
> unlike authorization server discovery, where there’s lots of existing
> practice, including using the existing data format for describing OAuth
> implementations that aren’t being used with OpenID Connect, there’s no
> existing practice to standardize for resource discovery.  The time to
> create a standard for that seems to be after existing practice has
> emerged.  It **might** or might not use new metadata values in the AS
> discovery document, but that’s still to be determined.  The one reason to
> leave the title as-is is that resource discovery might end up involving
> extensions to this metadata format in some cases.
>
>
>
> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750
> applies.  6749 is about the AS.  6750 is about the RS.  The discovery
> document is about the AS.  We don’t yet have a specification or existing
> practice for RS discovery, which would be the 6750 analogy.
>
>
>
> In summary, which title do people prefer?
>
> ·   “OAuth 2.0 Discovery”
>
> ·   “OAuth 2.0 Authorization Server Discovery”
>
>
>
>  
>
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Mike Jones]

I know that at least in Azure, developers can dynamically add resources for use 
by the client using the developer portal at any time.  Therefore, at client 
configuration time, which is when AS discovery is used, there is not an 
authoritative list of resources available.  I believe that Brian said a similar 
thing about his use cases.

Therefore, while what you’re proposing may *seem*, simple, but it’s *not 
actually* simple at all.

  -- Mike

From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Saturday, February 27, 2016 10:57 AM
To: Mike Jones 
Cc: Vladimir Dzhuvinov ; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

To clarify…. I am not suggesting that we need a resource discovery mechanism.

What I am suggesting is much simpler.

I propose that the authorization confirm that the endpoint that the client has 
discovered is a resource that the AS can issue tokens for (in other words is a 
valid audience for the tokens).

This will work well in UMA cases and it confirms the relationship between the 
AS and the RS is in fact valid.
It also detects mis-configuration cases that might naturally occur in scenarios 
with multi-tenancies etc.

Phil

@independentid
www.independentid.com<http://www.independentid.com>
phil.h...@oracle.com<mailto:phil.h...@oracle.com>




On Feb 27, 2016, at 10:38 AM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:

Thanks for taking the time to propose specific text, Phil.  That’s really 
helpful.  I’ll plan to incorporate a version of this in the draft addressing 
WGLC comments.

I agree with Vladimir’s observation that it’s difficult to come up with a 
general-purpose resource discovery mechanism.  That in part, is because, as 
Brian points out, there’s often not a 1:1 relationship between authorization 
servers and resource servers.  As I’ve written before, I do encourage the 
working group to work on creating solutions to resource discovery that will 
work for some common use cases.  But the good news is that while resource 
discovery requires new invention, authorization server discovery does not.

 -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Vladimir Dzhuvinov
Sent: Saturday, February 27, 2016 10:33 AM
To: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location


On 27/02/16 20:10, Phil Hunt wrote:

The name change seems appropriate given that the WG members have decided not to 
address the issue of resource discovery as part of this specification.



If the consensus is to limit the scope of the specification, then I suggest the 
following security considerations text.



Resource Discovery



Secure discovery of resource endpoints is out-of-scope of this specification. 
This specification assumes that the client has already securely discovered the 
correct resource endpoint and that the client has correctly selected the 
correct corresponding discovery for OAuth Authorization server. Implementers 
MUST consider that if an incorrect resource endpoint was discovered by the 
client that an attacker will be able to set up a man-in-the-middle proxy to a 
real resource server without detection by the authorization server or the 
client.

I support that. This was the primary concern of everyone who felt uncomfortable 
with the original draft with WebFinger-based discovery in it, so it should be 
included.








It may be more appropriate to even include this text in the introduction as a 
cautionary "red flag" to implementers.
+1








Once again, I strongly urge the WG to actually include a method for the client 
to discovery that the oauth cliet has correctly discovered an authorization 
server that is willing and able to issue access tokens for a given resource 
endpoint. I believe this relationship is critical to security of OAuth in cases 
where resource endpoints are discovered dynamically.  Of course willing and 
able means that the AS believes that the endpoint is legitimate.

The more I think about this topic, the more pessimistic I get that there is a 
good solution to this :)

Vladimir









Phil



@independentid

www.independentid.com<http://www.independentid.com/> 
<http://www.independentid.com/><http://www.independentid.com/>phil.h...@oracle.com<mailto:phil.h...@oracle.com>
 <mailto:phil.h...@oracle.com><mailto:phil.h...@oracle.com>











On Feb 27, 2016, at 6:46 AM, Samuel Erdtman 
<mailto:sam...@erdtman.se> wrote:



+1 for “OAuth 2.0 Authorization Server Discovery”



//Samuel



On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones 
mailto:michael.jo...@microsoft.com> 
<mailto:michael.jo...@microsoft.com><mailto:michael.jo...@microsoft.com>> wrote:

Thanks for your thoughts, Vladimir.  I’m increasingly inclined to accept your 
suggestion to change the title from “OA

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Phil Hunt]

To clarify…. I am not suggesting that we need a resource discovery mechanism.

What I am suggesting is much simpler.

I propose that the authorization confirm that the endpoint that the client has 
discovered is a resource that the AS can issue tokens for (in other words is a 
valid audience for the tokens).

This will work well in UMA cases and it confirms the relationship between the 
AS and the RS is in fact valid.
It also detects mis-configuration cases that might naturally occur in scenarios 
with multi-tenancies etc.

Phil

@independentid
www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com 
<mailto:phil.h...@oracle.com>





> On Feb 27, 2016, at 10:38 AM, Mike Jones  wrote:
> 
> Thanks for taking the time to propose specific text, Phil.  That’s really 
> helpful.  I’ll plan to incorporate a version of this in the draft addressing 
> WGLC comments.
>  
> I agree with Vladimir’s observation that it’s difficult to come up with a 
> general-purpose resource discovery mechanism.  That in part, is because, as 
> Brian points out, there’s often not a 1:1 relationship between authorization 
> servers and resource servers.  As I’ve written before, I do encourage the 
> working group to work on creating solutions to resource discovery that will 
> work for some common use cases.  But the good news is that while resource 
> discovery requires new invention, authorization server discovery does not.
>  
>  -- Mike
>   <>
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Vladimir Dzhuvinov
> Sent: Saturday, February 27, 2016 10:33 AM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
>  
> 
> On 27/02/16 20:10, Phil Hunt wrote:
> The name change seems appropriate given that the WG members have decided not 
> to address the issue of resource discovery as part of this specification.
>  
> If the consensus is to limit the scope of the specification, then I suggest 
> the following security considerations text.
>  
> Resource Discovery
>  
> Secure discovery of resource endpoints is out-of-scope of this specification. 
> This specification assumes that the client has already securely discovered 
> the correct resource endpoint and that the client has correctly selected the 
> correct corresponding discovery for OAuth Authorization server. Implementers 
> MUST consider that if an incorrect resource endpoint was discovered by the 
> client that an attacker will be able to set up a man-in-the-middle proxy to a 
> real resource server without detection by the authorization server or the 
> client. 
> 
> I support that. This was the primary concern of everyone who felt 
> uncomfortable with the original draft with WebFinger-based discovery in it, 
> so it should be included.
> 
> 
> 
> 
>  
> It may be more appropriate to even include this text in the introduction as a 
> cautionary "red flag" to implementers.
> +1
> 
> 
>  
>  
> Once again, I strongly urge the WG to actually include a method for the 
> client to discovery that the oauth cliet has correctly discovered an 
> authorization server that is willing and able to issue access tokens for a 
> given resource endpoint. I believe this relationship is critical to security 
> of OAuth in cases where resource endpoints are discovered dynamically.  Of 
> course willing and able means that the AS believes that the endpoint is 
> legitimate.
> 
> The more I think about this topic, the more pessimistic I get that there is a 
> good solution to this :)
> 
> Vladimir
> 
> 
> 
>  
>  
> Phil
>  
> @independentid
> www.independentid.com <http://www.independentid.com/> 
> <http://www.independentid.com/> 
> <http://www.independentid.com/>phil.h...@oracle.com 
> <mailto:phil.h...@oracle.com> <mailto:phil.h...@oracle.com> 
> <mailto:phil.h...@oracle.com>
>  
>  
>  
>  
>  
> On Feb 27, 2016, at 6:46 AM, Samuel Erdtman  
> <mailto:sam...@erdtman.se> wrote:
>  
> +1 for “OAuth 2.0 Authorization Server Discovery”
>  
> //Samuel
>  
> On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones  <mailto:michael.jo...@microsoft.com> <mailto:michael.jo...@microsoft.com> 
> <mailto:michael.jo...@microsoft.com>> wrote:
> Thanks for your thoughts, Vladimir.  I’m increasingly inclined to accept your 
> suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0 
> Authorization Server Discovery”.  While the abstract already makes it clear 
> that the scope of the document is AS discovery, doing so in the title seems 
> like it could help clarify things, given that a lot of the discussion se

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Mike Jones]

Thanks for taking the time to propose specific text, Phil.  That’s really 
helpful.  I’ll plan to incorporate a version of this in the draft addressing 
WGLC comments.

I agree with Vladimir’s observation that it’s difficult to come up with a 
general-purpose resource discovery mechanism.  That in part, is because, as 
Brian points out, there’s often not a 1:1 relationship between authorization 
servers and resource servers.  As I’ve written before, I do encourage the 
working group to work on creating solutions to resource discovery that will 
work for some common use cases.  But the good news is that while resource 
discovery requires new invention, authorization server discovery does not.

 -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Vladimir Dzhuvinov
Sent: Saturday, February 27, 2016 10:33 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location


On 27/02/16 20:10, Phil Hunt wrote:

The name change seems appropriate given that the WG members have decided not to 
address the issue of resource discovery as part of this specification.



If the consensus is to limit the scope of the specification, then I suggest the 
following security considerations text.



Resource Discovery



Secure discovery of resource endpoints is out-of-scope of this specification. 
This specification assumes that the client has already securely discovered the 
correct resource endpoint and that the client has correctly selected the 
correct corresponding discovery for OAuth Authorization server. Implementers 
MUST consider that if an incorrect resource endpoint was discovered by the 
client that an attacker will be able to set up a man-in-the-middle proxy to a 
real resource server without detection by the authorization server or the 
client.

I support that. This was the primary concern of everyone who felt uncomfortable 
with the original draft with WebFinger-based discovery in it, so it should be 
included.







It may be more appropriate to even include this text in the introduction as a 
cautionary "red flag" to implementers.
+1







Once again, I strongly urge the WG to actually include a method for the client 
to discovery that the oauth cliet has correctly discovered an authorization 
server that is willing and able to issue access tokens for a given resource 
endpoint. I believe this relationship is critical to security of OAuth in cases 
where resource endpoints are discovered dynamically.  Of course willing and 
able means that the AS believes that the endpoint is legitimate.

The more I think about this topic, the more pessimistic I get that there is a 
good solution to this :)

Vladimir








Phil



@independentid

www.independentid.com<http://www.independentid.com> 
<http://www.independentid.com/><http://www.independentid.com/>phil.h...@oracle.com<mailto:phil.h...@oracle.com>
 <mailto:phil.h...@oracle.com><mailto:phil.h...@oracle.com>











On Feb 27, 2016, at 6:46 AM, Samuel Erdtman 
<mailto:sam...@erdtman.se> wrote:



+1 for “OAuth 2.0 Authorization Server Discovery”



//Samuel



On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones 
mailto:michael.jo...@microsoft.com> 
<mailto:michael.jo...@microsoft.com><mailto:michael.jo...@microsoft.com>> wrote:

Thanks for your thoughts, Vladimir.  I’m increasingly inclined to accept your 
suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0 
Authorization Server Discovery”.  While the abstract already makes it clear 
that the scope of the document is AS discovery, doing so in the title seems 
like it could help clarify things, given that a lot of the discussion seems to 
be about resource discovery, which is out of scope of the document.







I’m not saying that resource discovery isn’t important – it is – but unlike 
authorization server discovery, where there’s lots of existing practice, 
including using the existing data format for describing OAuth implementations 
that aren’t being used with OpenID Connect, there’s no existing practice to 
standardize for resource discovery.  The time to create a standard for that 
seems to be after existing practice has emerged.  It *might* or might not use 
new metadata values in the AS discovery document, but that’s still to be 
determined.  The one reason to leave the title as-is is that resource discovery 
might end up involving extensions to this metadata format in some cases.







I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 applies.  
6749 is about the AS.  6750 is about the RS.  The discovery document is about 
the AS.  We don’t yet have a specification or existing practice for RS 
discovery, which would be the 6750 analogy.







In summary, which title do people prefer?



·   “OAuth 2.0 Discovery”



·   “OAuth 2.0 Authorization Server Discovery”







   

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Vladimir Dzhuvinov]

On 27/02/16 20:10, Phil Hunt wrote:
> The name change seems appropriate given that the WG members have decided not 
> to address the issue of resource discovery as part of this specification.
>
> If the consensus is to limit the scope of the specification, then I suggest 
> the following security considerations text.
>
> Resource Discovery
>
> Secure discovery of resource endpoints is out-of-scope of this specification. 
> This specification assumes that the client has already securely discovered 
> the correct resource endpoint and that the client has correctly selected the 
> correct corresponding discovery for OAuth Authorization server. Implementers 
> MUST consider that if an incorrect resource endpoint was discovered by the 
> client that an attacker will be able to set up a man-in-the-middle proxy to a 
> real resource server without detection by the authorization server or the 
> client. 

I support that. This was the primary concern of everyone who felt
uncomfortable with the original draft with WebFinger-based discovery in
it, so it should be included.



> It may be more appropriate to even include this text in the introduction as a 
> cautionary "red flag" to implementers.
+1

>
> Once again, I strongly urge the WG to actually include a method for the 
> client to discovery that the oauth cliet has correctly discovered an 
> authorization server that is willing and able to issue access tokens for a 
> given resource endpoint. I believe this relationship is critical to security 
> of OAuth in cases where resource endpoints are discovered dynamically.  Of 
> course willing and able means that the AS believes that the endpoint is 
> legitimate.

The more I think about this topic, the more pessimistic I get that there
is a good solution to this :)

Vladimir


>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com 
> <mailto:phil.h...@oracle.com>
>
>
>
>
>
>> On Feb 27, 2016, at 6:46 AM, Samuel Erdtman  wrote:
>>
>> +1 for “OAuth 2.0 Authorization Server Discovery”
>>
>> //Samuel
>>
>> On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones > <mailto:michael.jo...@microsoft.com>> wrote:
>> Thanks for your thoughts, Vladimir.  I’m increasingly inclined to accept 
>> your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0 
>> Authorization Server Discovery”.  While the abstract already makes it clear 
>> that the scope of the document is AS discovery, doing so in the title seems 
>> like it could help clarify things, given that a lot of the discussion seems 
>> to be about resource discovery, which is out of scope of the document.
>>
>>  
>>
>> I’m not saying that resource discovery isn’t important – it is – but unlike 
>> authorization server discovery, where there’s lots of existing practice, 
>> including using the existing data format for describing OAuth 
>> implementations that aren’t being used with OpenID Connect, there’s no 
>> existing practice to standardize for resource discovery.  The time to create 
>> a standard for that seems to be after existing practice has emerged.  It 
>> *might* or might not use new metadata values in the AS discovery document, 
>> but that’s still to be determined.  The one reason to leave the title as-is 
>> is that resource discovery might end up involving extensions to this 
>> metadata format in some cases.
>>
>>  
>>
>> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 
>> applies.  6749 is about the AS.  6750 is about the RS.  The discovery 
>> document is about the AS.  We don’t yet have a specification or existing 
>> practice for RS discovery, which would be the 6750 analogy.
>>
>>  
>>
>> In summary, which title do people prefer?
>>
>> ·   “OAuth 2.0 Discovery”
>>
>> ·   “OAuth 2.0 Authorization Server Discovery”
>>
>>  
>>
>>   -- Mike
>>
>>   <>
>> From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] 
>> On Behalf Of Vladimir Dzhuvinov
>> Sent: Thursday, February 25, 2016 12:59 AM
>> To: oauth@ietf.org <mailto:oauth@ietf.org>
>>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>>  
>>
>> In OIDC the discovery doc is of great utility to developers and integrators. 
>> Developers also tend to find it a more accurate and complete description of 
>> how to set up a client for a particular deployment, compared to traditional 
>> online docs, which may be not be up 

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Phil Hunt]

The name change seems appropriate given that the WG members have decided not to 
address the issue of resource discovery as part of this specification.

If the consensus is to limit the scope of the specification, then I suggest the 
following security considerations text.

Resource Discovery

Secure discovery of resource endpoints is out-of-scope of this specification. 
This specification assumes that the client has already securely discovered the 
correct resource endpoint and that the client has correctly selected the 
correct corresponding discovery for OAuth Authorization server. Implementers 
MUST consider that if an incorrect resource endpoint was discovered by the 
client that an attacker will be able to set up a man-in-the-middle proxy to a 
real resource server without detection by the authorization server or the 
client. 

It may be more appropriate to even include this text in the introduction as a 
cautionary "red flag" to implementers.

Once again, I strongly urge the WG to actually include a method for the client 
to discovery that the oauth cliet has correctly discovered an authorization 
server that is willing and able to issue access tokens for a given resource 
endpoint. I believe this relationship is critical to security of OAuth in cases 
where resource endpoints are discovered dynamically.  Of course willing and 
able means that the AS believes that the endpoint is legitimate.

Phil

@independentid
www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com 
<mailto:phil.h...@oracle.com>





> On Feb 27, 2016, at 6:46 AM, Samuel Erdtman  wrote:
> 
> +1 for “OAuth 2.0 Authorization Server Discovery”
> 
> //Samuel
> 
> On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones  <mailto:michael.jo...@microsoft.com>> wrote:
> Thanks for your thoughts, Vladimir.  I’m increasingly inclined to accept your 
> suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0 
> Authorization Server Discovery”.  While the abstract already makes it clear 
> that the scope of the document is AS discovery, doing so in the title seems 
> like it could help clarify things, given that a lot of the discussion seems 
> to be about resource discovery, which is out of scope of the document.
> 
>  
> 
> I’m not saying that resource discovery isn’t important – it is – but unlike 
> authorization server discovery, where there’s lots of existing practice, 
> including using the existing data format for describing OAuth implementations 
> that aren’t being used with OpenID Connect, there’s no existing practice to 
> standardize for resource discovery.  The time to create a standard for that 
> seems to be after existing practice has emerged.  It *might* or might not use 
> new metadata values in the AS discovery document, but that’s still to be 
> determined.  The one reason to leave the title as-is is that resource 
> discovery might end up involving extensions to this metadata format in some 
> cases.
> 
>  
> 
> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 applies. 
>  6749 is about the AS.  6750 is about the RS.  The discovery document is 
> about the AS.  We don’t yet have a specification or existing practice for RS 
> discovery, which would be the 6750 analogy.
> 
>  
> 
> In summary, which title do people prefer?
> 
> ·   “OAuth 2.0 Discovery”
> 
> ·   “OAuth 2.0 Authorization Server Discovery”
> 
>  
> 
>   -- Mike
> 
>   <>
> From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] 
> On Behalf Of Vladimir Dzhuvinov
> Sent: Thursday, February 25, 2016 12:59 AM
> To: oauth@ietf.org <mailto:oauth@ietf.org>
> 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> 
>  
> 
> In OIDC the discovery doc is of great utility to developers and integrators. 
> Developers also tend to find it a more accurate and complete description of 
> how to set up a client for a particular deployment, compared to traditional 
> online docs, which may be not be up to date, or even missing. Very much like 
> auto-generated Swagger and JavaDocs.
> 
> Here are some example OIDC discovery docs:
> 
> https://accounts.google.com/.well-known/openid-configuration 
> <https://accounts.google.com/.well-known/openid-configuration>
> 
> https://www.paypalobjects.com/.well-known/openid-configuration 
> <https://www.paypalobjects.com/.well-known/openid-configuration>
> 
> https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration
>  
> <https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration>
> 
> 
> With this discovery document in place setup of iden

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Mike Jones]

It’s clear that people want us to move to the name “OAuth 2.0 Authorization 
Server Discovery”.  The editors will plan to make that change in the draft 
addressing Working Group Last Call comments.

  Thanks all,
  -- Mike

From: Samuel Erdtman [mailto:sam...@erdtman.se]
Sent: Saturday, February 27, 2016 6:47 AM
To: Mike Jones 
Cc: Vladimir Dzhuvinov ; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

+1 for “OAuth 2.0 Authorization Server Discovery”

//Samuel

On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
Thanks for your thoughts, Vladimir.  I’m increasingly inclined to accept your 
suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0 
Authorization Server Discovery”.  While the abstract already makes it clear 
that the scope of the document is AS discovery, doing so in the title seems 
like it could help clarify things, given that a lot of the discussion seems to 
be about resource discovery, which is out of scope of the document.

I’m not saying that resource discovery isn’t important – it is – but unlike 
authorization server discovery, where there’s lots of existing practice, 
including using the existing data format for describing OAuth implementations 
that aren’t being used with OpenID Connect, there’s no existing practice to 
standardize for resource discovery.  The time to create a standard for that 
seems to be after existing practice has emerged.  It *might* or might not use 
new metadata values in the AS discovery document, but that’s still to be 
determined.  The one reason to leave the title as-is is that resource discovery 
might end up involving extensions to this metadata format in some cases.

I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 applies.  
6749 is about the AS.  6750 is about the RS.  The discovery document is about 
the AS.  We don’t yet have a specification or existing practice for RS 
discovery, which would be the 6750 analogy.

In summary, which title do people prefer?

•   “OAuth 2.0 Discovery”

•   “OAuth 2.0 Authorization Server Discovery”

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Vladimir Dzhuvinov
Sent: Thursday, February 25, 2016 12:59 AM
To: oauth@ietf.org<mailto:oauth@ietf.org>

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

In OIDC the discovery doc is of great utility to developers and integrators. 
Developers also tend to find it a more accurate and complete description of how 
to set up a client for a particular deployment, compared to traditional online 
docs, which may be not be up to date, or even missing. Very much like 
auto-generated Swagger and JavaDocs.

Here are some example OIDC discovery docs:

https://accounts.google.com/.well-known/openid-configuration

https://www.paypalobjects.com/.well-known/openid-configuration

https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration


With this discovery document in place setup of identity federation can then be 
easily scripted. For example:

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html


Now, does that dictate any particular app architecture? My reading of the spec 
is that it doesn't, and it shouldn't either. By staying neutral on the topics 
of RS discovery and registering RPs with RSs. And how one arrives at the 
".well-known/...". I'm not even sure that resource discovery should be a topic 
of this WG. Perhaps to this end, and to prevent confusion that the spec is 
trying to do something more, a more specific title would suit it better. E.g. 
"AS Discovery".

Cheers,

Vladimir


On 25/02/16 02:25, Phil Hunt (IDM) wrote:

And so does oracle and so does google. Each different.



So how can an app dictate it then unless we all go to a common architecture?



Phil



On Feb 24, 2016, at 16:04, Mike Jones 
<mailto:michael.jo...@microsoft.com> wrote:



Azure defines ways for resource servers to be registered for use with a client 
and for clients to dynamically request an access token for use at a particular 
resource server.  You can call that custom architecture if you want.  It’s 
well-defined but it’s not currently in the standards realm.  I know that Google 
has syntax for doing the same, as I’m sure do a lot of other cloud OAuth 
deployments, such as Oracle’s.  For what it’s worth, the working group talked 
about possibly producing a standard version of syntax for making these kinds of 
requests during our discussions in Prague (during the Token Exchange 
discussion) but nobody has run with this yet.



In this sense, yes, Azure is an application of the kind we’re talking about.  
Azure already does define

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Samuel Erdtman]

+1 for “OAuth 2.0 Authorization Server Discovery”

//Samuel

On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones 
wrote:

> Thanks for your thoughts, Vladimir.  I’m increasingly inclined to accept
> your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth
> 2.0 Authorization Server Discovery”.  While the abstract already makes it
> clear that the scope of the document is AS discovery, doing so in the title
> seems like it could help clarify things, given that a lot of the discussion
> seems to be about resource discovery, which is out of scope of the document.
>
>
>
> I’m not saying that resource discovery isn’t important – it is – but
> unlike authorization server discovery, where there’s lots of existing
> practice, including using the existing data format for describing OAuth
> implementations that aren’t being used with OpenID Connect, there’s no
> existing practice to standardize for resource discovery.  The time to
> create a standard for that seems to be after existing practice has
> emerged.  It **might** or might not use new metadata values in the AS
> discovery document, but that’s still to be determined.  The one reason to
> leave the title as-is is that resource discovery might end up involving
> extensions to this metadata format in some cases.
>
>
>
> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750
> applies.  6749 is about the AS.  6750 is about the RS.  The discovery
> document is about the AS.  We don’t yet have a specification or existing
> practice for RS discovery, which would be the 6750 analogy.
>
>
>
> In summary, which title do people prefer?
>
> ·   “OAuth 2.0 Discovery”
>
> ·   “OAuth 2.0 Authorization Server Discovery”
>
>
>
>   -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Vladimir
> Dzhuvinov
> *Sent:* Thursday, February 25, 2016 12:59 AM
> *To:* oauth@ietf.org
>
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> In OIDC the discovery doc is of great utility to developers and
> integrators. Developers also tend to find it a more accurate and complete
> description of how to set up a client for a particular deployment, compared
> to traditional online docs, which may be not be up to date, or even
> missing. Very much like auto-generated Swagger and JavaDocs.
>
> Here are some example OIDC discovery docs:
>
> https://accounts.google.com/.well-known/openid-configuration
>
> https://www.paypalobjects.com/.well-known/openid-configuration
>
>
> https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration
>
>
> With this discovery document in place setup of identity federation can
> then be easily scripted. For example:
>
>
> http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html
>
>
> Now, does that dictate any particular app architecture? My reading of the
> spec is that it doesn't, and it shouldn't either. By staying neutral on the
> topics of RS discovery and registering RPs with RSs. And how one arrives at
> the ".well-known/...". I'm not even sure that resource discovery should be
> a topic of this WG. Perhaps to this end, and to prevent confusion that the
> spec is trying to do something more, a more specific title would suit it
> better. E.g. "AS Discovery".
>
> Cheers,
>
> Vladimir
>
>
>
> On 25/02/16 02:25, Phil Hunt (IDM) wrote:
>
> And so does oracle and so does google. Each different.
>
>
>
> So how can an app dictate it then unless we all go to a common architecture?
>
>
>
> Phil
>
>
>
> On Feb 24, 2016, at 16:04, Mike Jones  
>  wrote:
>
>
>
> Azure defines ways for resource servers to be registered for use with a 
> client and for clients to dynamically request an access token for use at a 
> particular resource server.  You can call that custom architecture if you 
> want.  It’s well-defined but it’s not currently in the standards realm.  I 
> know that Google has syntax for doing the same, as I’m sure do a lot of other 
> cloud OAuth deployments, such as Oracle’s.  For what it’s worth, the working 
> group talked about possibly producing a standard version of syntax for making 
> these kinds of requests during our discussions in Prague (during the Token 
> Exchange discussion) but nobody has run with this yet.
>
>  In this sense, yes, Azure is an application of the kind we’re talking about. 
>  Azure already does define specific new OAuth 2.0 discovery metadata values 
> that are used in production.  A registry just doesn’t yet exist in which it 
> can regi

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[tors...@lodderstedt.net]

+1

Sent by MailWise – See your emails as clean, short chats.

 Originalnachricht 
Betreff: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
Von: Justin Richer 
An: George Fletcher 
Cc: "" 

>+1 for “OAuth 2.0 Authorization Server Discovery”
>
> — Justin
>
>> On Feb 25, 2016, at 2:20 PM, George Fletcher  wrote:
>> 
>> +1 for “OAuth 2.0 Authorization Server Discovery”
>> 
>> On 2/25/16 2:10 PM, Mike Jones wrote:
>>> Thanks for your thoughts, Vladimir.  I’m increasingly inclined to accept 
>>> your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 
>>> 2.0 Authorization Server Discovery”.  While the abstract already makes it 
>>> clear that the scope of the document is AS discovery, doing so in the title 
>>> seems like it could help clarify things, given that a lot of the discussion 
>>> seems to be about resource discovery, which is out of scope of the document.
>>>  
>>> I’m not saying that resource discovery isn’t important – it is – but unlike 
>>> authorization server discovery, where there’s lots of existing practice, 
>>> including using the existing data format for describing OAuth 
>>> implementations that aren’t being used with OpenID Connect, there’s no 
>>> existing practice to standardize for resource discovery.  The time to 
>>> create a standard for that seems to be after existing practice has emerged. 
>>>  It *might* or might not use new metadata values in the AS discovery 
>>> document, but that’s still to be determined.  The one reason to leave the 
>>> title as-is is that resource discovery might end up involving extensions to 
>>> this metadata format in some cases.
>>>  
>>> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 
>>> applies.  6749 is about the AS.  6750 is about the RS.  The discovery 
>>> document is about the AS.  We don’t yet have a specification or existing 
>>> practice for RS discovery, which would be the 6750 analogy.
>>>  
>>> In summary, which title do people prefer?
>>> ·   “OAuth 2.0 Discovery”
>>> ·   “OAuth 2.0 Authorization Server Discovery”
>>>  
>>>               -- Mike
>>>   <>
>>> From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] 
>>> On Behalf Of Vladimir Dzhuvinov
>>> Sent: Thursday, February 25, 2016 12:59 AM
>>> To: oauth@ietf.org <mailto:oauth@ietf.org>
>>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>>  
>>> In OIDC the discovery doc is of great utility to developers and 
>>> integrators. Developers also tend to find it a more accurate and complete 
>>> description of how to set up a client for a particular deployment, compared 
>>> to traditional online docs, which may be not be up to date, or even 
>>> missing. Very much like auto-generated Swagger and JavaDocs.
>>> 
>>> Here are some example OIDC discovery docs:
>>> 
>>> https://accounts.google.com/.well-known/openid-configuration 
>>> <https://accounts.google.com/.well-known/openid-configuration>
>>> 
>>> https://www.paypalobjects.com/.well-known/openid-configuration 
>>> <https://www.paypalobjects.com/.well-known/openid-configuration>
>>> 
>>> https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration
>>>  
>>> <https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration>
>>> 
>>> 
>>> With this discovery document in place setup of identity federation can then 
>>> be easily scripted. For example:
>>> 
>>> http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html
>>>  
>>> <http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html>
>>> 
>>> 
>>> Now, does that dictate any particular app architecture? My reading of the 
>>> spec is that it doesn't, and it shouldn't either. By staying neutral on the 
>>> topics of RS discovery and registering RPs with RSs. And how one arrives at 
>>> the ".well-known/...". I'm not even sure that resource discovery should be 
>>> a topic of this WG. Perhaps to this end, and to prevent confusion that the 
>>> spec is trying to do something more, a more specific title would suit it 
>>> better. E.g. "AS Discovery".
>>

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Justin Richer]

+1 for “OAuth 2.0 Authorization Server Discovery”

 — Justin

> On Feb 25, 2016, at 2:20 PM, George Fletcher  wrote:
> 
> +1 for “OAuth 2.0 Authorization Server Discovery”
> 
> On 2/25/16 2:10 PM, Mike Jones wrote:
>> Thanks for your thoughts, Vladimir.  I’m increasingly inclined to accept 
>> your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0 
>> Authorization Server Discovery”.  While the abstract already makes it clear 
>> that the scope of the document is AS discovery, doing so in the title seems 
>> like it could help clarify things, given that a lot of the discussion seems 
>> to be about resource discovery, which is out of scope of the document.
>>  
>> I’m not saying that resource discovery isn’t important – it is – but unlike 
>> authorization server discovery, where there’s lots of existing practice, 
>> including using the existing data format for describing OAuth 
>> implementations that aren’t being used with OpenID Connect, there’s no 
>> existing practice to standardize for resource discovery.  The time to create 
>> a standard for that seems to be after existing practice has emerged.  It 
>> *might* or might not use new metadata values in the AS discovery document, 
>> but that’s still to be determined.  The one reason to leave the title as-is 
>> is that resource discovery might end up involving extensions to this 
>> metadata format in some cases.
>>  
>> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 
>> applies.  6749 is about the AS.  6750 is about the RS.  The discovery 
>> document is about the AS.  We don’t yet have a specification or existing 
>> practice for RS discovery, which would be the 6750 analogy.
>>  
>> In summary, which title do people prefer?
>> ·   “OAuth 2.0 Discovery”
>> ·   “OAuth 2.0 Authorization Server Discovery”
>>  
>>   -- Mike
>>   <>
>> From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] 
>> On Behalf Of Vladimir Dzhuvinov
>> Sent: Thursday, February 25, 2016 12:59 AM
>> To: oauth@ietf.org <mailto:oauth@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>  
>> In OIDC the discovery doc is of great utility to developers and integrators. 
>> Developers also tend to find it a more accurate and complete description of 
>> how to set up a client for a particular deployment, compared to traditional 
>> online docs, which may be not be up to date, or even missing. Very much like 
>> auto-generated Swagger and JavaDocs.
>> 
>> Here are some example OIDC discovery docs:
>> 
>> https://accounts.google.com/.well-known/openid-configuration 
>> <https://accounts.google.com/.well-known/openid-configuration>
>> 
>> https://www.paypalobjects.com/.well-known/openid-configuration 
>> <https://www.paypalobjects.com/.well-known/openid-configuration>
>> 
>> https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration
>>  
>> <https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration>
>> 
>> 
>> With this discovery document in place setup of identity federation can then 
>> be easily scripted. For example:
>> 
>> http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html
>>  
>> <http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html>
>> 
>> 
>> Now, does that dictate any particular app architecture? My reading of the 
>> spec is that it doesn't, and it shouldn't either. By staying neutral on the 
>> topics of RS discovery and registering RPs with RSs. And how one arrives at 
>> the ".well-known/...". I'm not even sure that resource discovery should be a 
>> topic of this WG. Perhaps to this end, and to prevent confusion that the 
>> spec is trying to do something more, a more specific title would suit it 
>> better. E.g. "AS Discovery".
>> 
>> Cheers,
>> 
>> Vladimir
>> 
>> 
>> 
>> 
>> On 25/02/16 02:25, Phil Hunt (IDM) wrote:
>> And so does oracle and so does google. Each different. 
>>  
>> So how can an app dictate it then unless we all go to a common architecture?
>>  
>> Phil
>>  
>> On Feb 24, 2016, at 16:04, Mike Jones  
>> <mailto:michael.jo...@microsoft.com> wrote:
>>  
>> Azure defines ways for resource servers to be registered for us

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[George Fletcher]

As long as the "aud" value is more akin to a fixed URI from which the 
client can determine valid endpoints for that "aud", this could work. It 
does make the client do a lot of discovery.


I don't think the "aud" value can be a domain.

Thanks,
George

On 2/26/16 12:52 AM, nov matake wrote:
It sounds like we want to return a list of available access tokens 
“aud” values from AS config discovery endpoint (and also via 
oauth-meta too?), doesn’t it?


and RS config discovery endpoint will return acceptable access token 
“iss” values, a list of every RS endpoints, required scopes per 
endpoint etc.

(it would be another thread though)

Thanks,
Nov

On Feb 26, 2016, at 13:08, Nat Sakimura <mailto:sakim...@gmail.com>> wrote:


I will include the origin in the next rev.

For http header v.s JSON, shall I bring the JSON back in?
2016年2月26日(金) 13:05 Manger, James 
<mailto:james.h.man...@team.telstra.com>>:


You are right, George, that making the AS track /v2/… or /v3/… in
RS paths is likely to be brittle — but tracking RS web origins is
not too onerous.

PoP has some nice security advantages over bearer tokens or
passwords. However, it should still be possible to use the latter
fairly safely — but it does require the issuer of credentials to
indicate where they can be used.

--

James Manger

*From:*OAuth [mailto:oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>] *On Behalf Of *George Fletcher
*Sent:* Friday, 26 February 2016 2:28 AM
*To:* Vladimir Dzhuvinov mailto:vladi...@connect2id.com>>; oauth@ietf.org
    <mailto:oauth@ietf.org>


*Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location

That said, I'm not against the AS informing the client that the
token can be used at the MailResource, ContactResource and
MessagingResource to help the client know not to send the token
to a BlogResource. However, identifying the actual endpoint seems
overly complex when what is really trying to be protected is a
token from being used where it shouldn't be (which is solved by Pop)

Thanks,
George

On 2/25/16 10:25 AM, George Fletcher wrote:

Interesting... this is not at all my current experience:) If
a RS goes from v2 of it's API to v3 and that RS uses the
current standard of putting a "v2" or"v3" in it's API path...
then a token issued for v2 of the API can not be sent to v3
of the API, because v3 wasn't wasn't registered/deployed when
the token was issued.

The constant management of scopes to URI endpoints seems like
a complexity that will quickly get out of hand.

Thanks,
George

On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:

On 25/02/16 09:02, Manger, James wrote:

I'm concerned that forcing the AS to know about all RS's 
endpoints that will accept it's tokens creates a very brittle deployment 
architecture

The AS is issuing temporary credentials (access_tokens) to 
clients but doesn’t know where those credentials will work? That’s broken.

  


An AS should absolutely indicate where an access_token can be 
used. draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” 
(resource URI) values in an HTTP Link header. A better approach would be 
including a list of web origins in the token response beside the access_token 
field.

+1

This will appear more consistent with the current
experience, and OAuth does allow the token response JSON
object to be extended with additional members (as it's
done in OpenID Connect already).

Cheers,
Vladimir


--

James Manger

  


From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of George 
Fletcher

Sent: Thursday, 25 February 2016 6:17 AM

To: Phil Hunt <mailto:phil.h...@oracle.com>; Nat 
Sakimura <mailto:sakim...@gmail.com>

Cc: <mailto:oauth@ietf.org>   
<mailto:oauth@ietf.org>

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

  


I'm concerned that forcing the AS to know about all RS's 
endpoints that will accept it's tokens creates a very brittle deployment 
architecture. What if a RS moves to a new endpoint? All clients would be 
required to get new tokens (if I understand correctly). And the RS move would 
have to coordinate with the AS to make sure all the timing is perfect in the 
switch over of endpoints.

  


I suspect a common deployment architecture today is that each 
RS requires one or more scopes to access it's resources. T

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[John Bradley]

A given AS may be supporting different protocols and or scopes with different 
privileges.

Those would need to be mapped into where the token can be used. 

If we try to use audience only to stop cross RS replay it will in my opinion 
become hopelessly complex.

I think the only secure and practical solution is likely asymmetric POP.
That only requires the RS to trust the AS.   The AS doesn’t need to know the RS 
if it is using JWT access tokens.

I am skeptical that this can be solved by meta-data alone.

John B.
> On Feb 26, 2016, at 6:52 AM, nov matake  wrote:
> 
> It sounds like we want to return a list of available access tokens “aud” 
> values from AS config discovery endpoint (and also via oauth-meta too?), 
> doesn’t it?
> 
> and RS config discovery endpoint will return acceptable access token “iss” 
> values, a list of every RS endpoints, required scopes per endpoint etc.
> (it would be another thread though)
> 
> Thanks,
> Nov
> 
>> On Feb 26, 2016, at 13:08, Nat Sakimura > <mailto:sakim...@gmail.com>> wrote:
>> 
>> I will include the origin in the next rev. 
>> 
>> For http header v.s JSON, shall I bring the JSON back in? 
>> 2016年2月26日(金) 13:05 Manger, James > <mailto:james.h.man...@team.telstra.com>>:
>> You are right, George, that making the AS track /v2/… or /v3/… in RS paths 
>> is likely to be brittle — but tracking RS web origins is not too onerous.
>> 
>>  
>> 
>> PoP has some nice security advantages over bearer tokens or passwords. 
>> However, it should still be possible to use the latter fairly safely — but 
>> it does require the issuer of credentials to indicate where they can be used.
>> 
>>  
>> 
>> --
>> 
>> James Manger
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] 
>> On Behalf Of George Fletcher
>> Sent: Friday, 26 February 2016 2:28 AM
>> To: Vladimir Dzhuvinov > <mailto:vladi...@connect2id.com>>; oauth@ietf.org <mailto:oauth@ietf.org>
>> 
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>> 
>>  
>> 
>> That said, I'm not against the AS informing the client that the token can be 
>> used at the MailResource, ContactResource and MessagingResource to help the 
>> client know not to send the token to a BlogResource. However, identifying 
>> the actual endpoint seems overly complex when what is really trying to be 
>> protected is a token from being used where it shouldn't be (which is solved 
>> by Pop)
>> 
>> Thanks,
>> George
>> 
>> On 2/25/16 10:25 AM, George Fletcher wrote:
>> 
>> Interesting... this is not at all my current experience:) If a RS goes from 
>> v2 of it's API to v3 and that RS uses the current standard of putting a "v2" 
>> or"v3" in it's API path... then a token issued for v2 of the API can not be 
>> sent to v3 of the API, because v3 wasn't wasn't registered/deployed when the 
>> token was issued. 
>> 
>> The constant management of scopes to URI endpoints seems like a complexity 
>> that will quickly get out of hand.
>> 
>> Thanks,
>> George
>> 
>> On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
>> 
>>  
>> 
>> On 25/02/16 09:02, Manger, James wrote:
>> 
>> I'm concerned that forcing the AS to know about all RS's endpoints that will 
>> accept it's tokens creates a very brittle deployment architecture
>> The AS is issuing temporary credentials (access_tokens) to clients but 
>> doesn’t know where those credentials will work? That’s broken.
>>  
>> An AS should absolutely indicate where an access_token can be used. 
>> draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” 
>> (resource URI) values in an HTTP Link header. A better approach would be 
>> including a list of web origins in the token response beside the 
>> access_token field.
>> +1 
>> 
>> This will appear more consistent with the current experience, and OAuth does 
>> allow the token response JSON object to be extended with additional members 
>> (as it's done in OpenID Connect already).
>> 
>> Cheers,
>> Vladimir
>> 
>> 
>> 
>> --
>> James Manger
>>  
>> From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] 
>> On Behalf Of George Fletcher
>> Sent: Thursday, 25 February 2016 6:17 AM
>> To: Phil Hunt  <mailto:phil.h...@oracle.com>; Nat 
>> Sakimura  <

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[nov matake]

It sounds like we want to return a list of available access tokens “aud” values 
from AS config discovery endpoint (and also via oauth-meta too?), doesn’t it?

and RS config discovery endpoint will return acceptable access token “iss” 
values, a list of every RS endpoints, required scopes per endpoint etc.
(it would be another thread though)

Thanks,
Nov

> On Feb 26, 2016, at 13:08, Nat Sakimura  wrote:
> 
> I will include the origin in the next rev. 
> 
> For http header v.s JSON, shall I bring the JSON back in? 
> 2016年2月26日(金) 13:05 Manger, James  <mailto:james.h.man...@team.telstra.com>>:
> You are right, George, that making the AS track /v2/… or /v3/… in RS paths is 
> likely to be brittle — but tracking RS web origins is not too onerous.
> 
>  
> 
> PoP has some nice security advantages over bearer tokens or passwords. 
> However, it should still be possible to use the latter fairly safely — but it 
> does require the issuer of credentials to indicate where they can be used.
> 
>  
> 
> --
> 
> James Manger
> 
>  
> 
>  
> 
>  
> 
> From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] 
> On Behalf Of George Fletcher
> Sent: Friday, 26 February 2016 2:28 AM
> To: Vladimir Dzhuvinov  <mailto:vladi...@connect2id.com>>; oauth@ietf.org <mailto:oauth@ietf.org>
> 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> 
>  
> 
> That said, I'm not against the AS informing the client that the token can be 
> used at the MailResource, ContactResource and MessagingResource to help the 
> client know not to send the token to a BlogResource. However, identifying the 
> actual endpoint seems overly complex when what is really trying to be 
> protected is a token from being used where it shouldn't be (which is solved 
> by Pop)
> 
> Thanks,
> George
> 
> On 2/25/16 10:25 AM, George Fletcher wrote:
> 
> Interesting... this is not at all my current experience:) If a RS goes from 
> v2 of it's API to v3 and that RS uses the current standard of putting a "v2" 
> or"v3" in it's API path... then a token issued for v2 of the API can not be 
> sent to v3 of the API, because v3 wasn't wasn't registered/deployed when the 
> token was issued. 
> 
> The constant management of scopes to URI endpoints seems like a complexity 
> that will quickly get out of hand.
> 
> Thanks,
> George
> 
> On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
> 
>  
> 
> On 25/02/16 09:02, Manger, James wrote:
> 
> I'm concerned that forcing the AS to know about all RS's endpoints that will 
> accept it's tokens creates a very brittle deployment architecture
> The AS is issuing temporary credentials (access_tokens) to clients but 
> doesn’t know where those credentials will work? That’s broken.
>  
> An AS should absolutely indicate where an access_token can be used. 
> draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” 
> (resource URI) values in an HTTP Link header. A better approach would be 
> including a list of web origins in the token response beside the access_token 
> field.
> +1 
> 
> This will appear more consistent with the current experience, and OAuth does 
> allow the token response JSON object to be extended with additional members 
> (as it's done in OpenID Connect already).
> 
> Cheers,
> Vladimir
> 
> 
> 
> --
> James Manger
>  
> From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] 
> On Behalf Of George Fletcher
> Sent: Thursday, 25 February 2016 6:17 AM
> To: Phil Hunt  <mailto:phil.h...@oracle.com>; Nat 
> Sakimura  <mailto:sakim...@gmail.com>
> Cc:  <mailto:oauth@ietf.org>  
> <mailto:oauth@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> I'm concerned that forcing the AS to know about all RS's endpoints that will 
> accept it's tokens creates a very brittle deployment architecture. What if a 
> RS moves to a new endpoint? All clients would be required to get new tokens 
> (if I understand correctly). And the RS move would have to coordinate with 
> the AS to make sure all the timing is perfect in the switch over of endpoints.
>  
> I suspect a common deployment architecture today is that each RS requires one 
> or more scopes to access it's resources. The client then asks the user to 
> authorize a token with a requested list of scopes. The client can then send 
> the token to the appropriate RS endpoint. The RS will not authorize access 
> unless the token has the required scopes.
>  
> If the concern is that the client may accidentally send the token to 

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Nat Sakimura]

I will include the origin in the next rev.

For http header v.s JSON, shall I bring the JSON back in?
2016年2月26日(金) 13:05 Manger, James :

> You are right, George, that making the AS track /v2/… or /v3/… in RS paths
> is likely to be brittle — but tracking RS web origins is not too onerous.
>
>
>
> PoP has some nice security advantages over bearer tokens or passwords.
> However, it should still be possible to use the latter fairly safely — but
> it does require the issuer of credentials to indicate where they can be
> used.
>
>
>
> --
>
> James Manger
>
>
>
>
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *George
> Fletcher
> *Sent:* Friday, 26 February 2016 2:28 AM
> *To:* Vladimir Dzhuvinov ; oauth@ietf.org
>
>
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> That said, I'm not against the AS informing the client that the token can
> be used at the MailResource, ContactResource and MessagingResource to help
> the client know not to send the token to a BlogResource. However,
> identifying the actual endpoint seems overly complex when what is really
> trying to be protected is a token from being used where it shouldn't be
> (which is solved by Pop)
>
> Thanks,
> George
>
> On 2/25/16 10:25 AM, George Fletcher wrote:
>
> Interesting... this is not at all my current experience:) If a RS goes
> from v2 of it's API to v3 and that RS uses the current standard of putting
> a "v2" or"v3" in it's API path... then a token issued for v2 of the API can
> not be sent to v3 of the API, because v3 wasn't wasn't registered/deployed
> when the token was issued.
>
> The constant management of scopes to URI endpoints seems like a complexity
> that will quickly get out of hand.
>
> Thanks,
> George
>
> On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
>
>
>
> On 25/02/16 09:02, Manger, James wrote:
>
> I'm concerned that forcing the AS to know about all RS's endpoints that will 
> accept it's tokens creates a very brittle deployment architecture
>
> The AS is issuing temporary credentials (access_tokens) to clients but 
> doesn’t know where those credentials will work? That’s broken.
>
>
>
> An AS should absolutely indicate where an access_token can be used. 
> draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” 
> (resource URI) values in an HTTP Link header. A better approach would be 
> including a list of web origins in the token response beside the access_token 
> field.
>
> +1
>
> This will appear more consistent with the current experience, and OAuth
> does allow the token response JSON object to be extended with additional
> members (as it's done in OpenID Connect already).
>
> Cheers,
> Vladimir
>
>
> --
>
> James Manger
>
>
>
> From: OAuth [mailto:oauth-boun...@ietf.org ] On 
> Behalf Of George Fletcher
>
> Sent: Thursday, 25 February 2016 6:17 AM
>
> To: Phil Hunt  ; Nat Sakimura 
>  
>
> Cc:
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> I'm concerned that forcing the AS to know about all RS's endpoints that will 
> accept it's tokens creates a very brittle deployment architecture. What if a 
> RS moves to a new endpoint? All clients would be required to get new tokens 
> (if I understand correctly). And the RS move would have to coordinate with 
> the AS to make sure all the timing is perfect in the switch over of endpoints.
>
>
>
> I suspect a common deployment architecture today is that each RS requires one 
> or more scopes to access it's resources. The client then asks the user to 
> authorize a token with a requested list of scopes. The client can then send 
> the token to the appropriate RS endpoint. The RS will not authorize access 
> unless the token has the required scopes.
>
>
>
> If the concern is that the client may accidentally send the token to a "bad" 
> RS which will then replay the token, then I'd rather use a PoP mechanism 
> because the point is that you want to ensure the correct client is presenting 
> the token. Trying to ensure the client doesn't send the token to the wrong 
> endpoint seems fraught with problems.
>
>
>
> Thanks,
>
> George
>
>
>
>
> ___
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> ___
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
>
> ___
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Manger, James]

You are right, George, that making the AS track /v2/… or /v3/… in RS paths is 
likely to be brittle — but tracking RS web origins is not too onerous.

PoP has some nice security advantages over bearer tokens or passwords. However, 
it should still be possible to use the latter fairly safely — but it does 
require the issuer of credentials to indicate where they can be used.

--
James Manger



From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of George Fletcher
Sent: Friday, 26 February 2016 2:28 AM
To: Vladimir Dzhuvinov ; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

That said, I'm not against the AS informing the client that the token can be 
used at the MailResource, ContactResource and MessagingResource to help the 
client know not to send the token to a BlogResource. However, identifying the 
actual endpoint seems overly complex when what is really trying to be protected 
is a token from being used where it shouldn't be (which is solved by Pop)

Thanks,
George
On 2/25/16 10:25 AM, George Fletcher wrote:
Interesting... this is not at all my current experience:) If a RS goes from v2 
of it's API to v3 and that RS uses the current standard of putting a "v2" 
or"v3" in it's API path... then a token issued for v2 of the API can not be 
sent to v3 of the API, because v3 wasn't wasn't registered/deployed when the 
token was issued.

The constant management of scopes to URI endpoints seems like a complexity that 
will quickly get out of hand.

Thanks,
George
On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:

On 25/02/16 09:02, Manger, James wrote:

I'm concerned that forcing the AS to know about all RS's endpoints that will 
accept it's tokens creates a very brittle deployment architecture

The AS is issuing temporary credentials (access_tokens) to clients but doesn’t 
know where those credentials will work? That’s broken.



An AS should absolutely indicate where an access_token can be used. 
draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” 
(resource URI) values in an HTTP Link header. A better approach would be 
including a list of web origins in the token response beside the access_token 
field.
+1

This will appear more consistent with the current experience, and OAuth does 
allow the token response JSON object to be extended with additional members (as 
it's done in OpenID Connect already).

Cheers,
Vladimir



--

James Manger



From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of George Fletcher

Sent: Thursday, 25 February 2016 6:17 AM

To: Phil Hunt <mailto:phil.h...@oracle.com>; Nat Sakimura 
<mailto:sakim...@gmail.com>

Cc: <mailto:oauth@ietf.org> 
<mailto:oauth@ietf.org>

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location



I'm concerned that forcing the AS to know about all RS's endpoints that will 
accept it's tokens creates a very brittle deployment architecture. What if a RS 
moves to a new endpoint? All clients would be required to get new tokens (if I 
understand correctly). And the RS move would have to coordinate with the AS to 
make sure all the timing is perfect in the switch over of endpoints.



I suspect a common deployment architecture today is that each RS requires one 
or more scopes to access it's resources. The client then asks the user to 
authorize a token with a requested list of scopes. The client can then send the 
token to the appropriate RS endpoint. The RS will not authorize access unless 
the token has the required scopes.



If the concern is that the client may accidentally send the token to a "bad" RS 
which will then replay the token, then I'd rather use a PoP mechanism because 
the point is that you want to ensure the correct client is presenting the 
token. Trying to ensure the client doesn't send the token to the wrong endpoint 
seems fraught with problems.



Thanks,

George




___

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth





___

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth






___

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[John Bradley]

Authorization server discovery.

> On Feb 25, 2016, at 8:10 PM, Mike Jones  wrote:
> 
> Thanks for your thoughts, Vladimir.  I’m increasingly inclined to accept your 
> suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0 
> Authorization Server Discovery”.  While the abstract already makes it clear 
> that the scope of the document is AS discovery, doing so in the title seems 
> like it could help clarify things, given that a lot of the discussion seems 
> to be about resource discovery, which is out of scope of the document.
>  
> I’m not saying that resource discovery isn’t important – it is – but unlike 
> authorization server discovery, where there’s lots of existing practice, 
> including using the existing data format for describing OAuth implementations 
> that aren’t being used with OpenID Connect, there’s no existing practice to 
> standardize for resource discovery.  The time to create a standard for that 
> seems to be after existing practice has emerged.  It *might* or might not use 
> new metadata values in the AS discovery document, but that’s still to be 
> determined.  The one reason to leave the title as-is is that resource 
> discovery might end up involving extensions to this metadata format in some 
> cases.
>  
> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 applies. 
>  6749 is about the AS.  6750 is about the RS.  The discovery document is 
> about the AS.  We don’t yet have a specification or existing practice for RS 
> discovery, which would be the 6750 analogy.
>  
> In summary, which title do people prefer?
> ·   “OAuth 2.0 Discovery”
> ·   “OAuth 2.0 Authorization Server Discovery”
>  
>   -- Mike
>   <>
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Vladimir Dzhuvinov
> Sent: Thursday, February 25, 2016 12:59 AM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> In OIDC the discovery doc is of great utility to developers and integrators. 
> Developers also tend to find it a more accurate and complete description of 
> how to set up a client for a particular deployment, compared to traditional 
> online docs, which may be not be up to date, or even missing. Very much like 
> auto-generated Swagger and JavaDocs.
> 
> Here are some example OIDC discovery docs:
> 
> https://accounts.google.com/.well-known/openid-configuration 
> <https://accounts.google.com/.well-known/openid-configuration>
> 
> https://www.paypalobjects.com/.well-known/openid-configuration 
> <https://www.paypalobjects.com/.well-known/openid-configuration>
> 
> https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration
>  
> <https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration>
> 
> 
> With this discovery document in place setup of identity federation can then 
> be easily scripted. For example:
> 
> http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html
>  
> <http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html>
> 
> 
> Now, does that dictate any particular app architecture? My reading of the 
> spec is that it doesn't, and it shouldn't either. By staying neutral on the 
> topics of RS discovery and registering RPs with RSs. And how one arrives at 
> the ".well-known/...". I'm not even sure that resource discovery should be a 
> topic of this WG. Perhaps to this end, and to prevent confusion that the spec 
> is trying to do something more, a more specific title would suit it better. 
> E.g. "AS Discovery".
> 
> Cheers,
> 
> Vladimir
> 
> 
> 
> 
> On 25/02/16 02:25, Phil Hunt (IDM) wrote:
> And so does oracle and so does google. Each different. 
>  
> So how can an app dictate it then unless we all go to a common architecture?
>  
> Phil
>  
> On Feb 24, 2016, at 16:04, Mike Jones  
> <mailto:michael.jo...@microsoft.com> wrote:
>  
> Azure defines ways for resource servers to be registered for use with a 
> client and for clients to dynamically request an access token for use at a 
> particular resource server.  You can call that custom architecture if you 
> want.  It’s well-defined but it’s not currently in the standards realm.  I 
> know that Google has syntax for doing the same, as I’m sure do a lot of other 
> cloud OAuth deployments, such as Oracle’s.  For what it’s worth, the working 
> group talked about possibly producing a standard version of syntax for making 
> these kinds of requests during our discussions in Prague

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Donald F. Coffin]

+1 for “OAuth 2.0 Authorization Server Discovery”

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

 

Phone:  (949) 636-8571

Email:<mailto:donald.cof...@reminetworks.com> 
donald.cof...@reminetworks.com

 

From: Mike Jones [mailto:michael.jo...@microsoft.com] 
Sent: Thursday, February 25, 2016 2:10 PM
To: Vladimir Dzhuvinov ; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

 

Thanks for your thoughts, Vladimir.  I’m increasingly inclined to accept your 
suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0 
Authorization Server Discovery”.  While the abstract already makes it clear 
that the scope of the document is AS discovery, doing so in the title seems 
like it could help clarify things, given that a lot of the discussion seems to 
be about resource discovery, which is out of scope of the document.

 

I’m not saying that resource discovery isn’t important – it is – but unlike 
authorization server discovery, where there’s lots of existing practice, 
including using the existing data format for describing OAuth implementations 
that aren’t being used with OpenID Connect, there’s no existing practice to 
standardize for resource discovery.  The time to create a standard for that 
seems to be after existing practice has emerged.  It *might* or might not use 
new metadata values in the AS discovery document, but that’s still to be 
determined.  The one reason to leave the title as-is is that resource discovery 
might end up involving extensions to this metadata format in some cases.

 

I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 applies.  
6749 is about the AS.  6750 is about the RS.  The discovery document is about 
the AS.  We don’t yet have a specification or existing practice for RS 
discovery, which would be the 6750 analogy.

 

In summary, which title do people prefer?

* “OAuth 2.0 Discovery”

* “OAuth 2.0 Authorization Server Discovery”

 

  -- Mike

 

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Vladimir Dzhuvinov
Sent: Thursday, February 25, 2016 12:59 AM
To: oauth@ietf.org <mailto:oauth@ietf.org> 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

 

In OIDC the discovery doc is of great utility to developers and integrators. 
Developers also tend to find it a more accurate and complete description of how 
to set up a client for a particular deployment, compared to traditional online 
docs, which may be not be up to date, or even missing. Very much like 
auto-generated Swagger and JavaDocs.

Here are some example OIDC discovery docs:

https://accounts.google.com/.well-known/openid-configuration

https://www.paypalobjects.com/.well-known/openid-configuration

https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration


With this discovery document in place setup of identity federation can then be 
easily scripted. For example:

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html


Now, does that dictate any particular app architecture? My reading of the spec 
is that it doesn't, and it shouldn't either. By staying neutral on the topics 
of RS discovery and registering RPs with RSs. And how one arrives at the 
".well-known/...". I'm not even sure that resource discovery should be a topic 
of this WG. Perhaps to this end, and to prevent confusion that the spec is 
trying to do something more, a more specific title would suit it better. E.g. 
"AS Discovery".

Cheers,

Vladimir




On 25/02/16 02:25, Phil Hunt (IDM) wrote:

And so does oracle and so does google. Each different. 
 
So how can an app dictate it then unless we all go to a common architecture?
 
Phil
 

On Feb 24, 2016, at 16:04, Mike Jones  <mailto:michael.jo...@microsoft.com> 
 wrote:
 
Azure defines ways for resource servers to be registered for use with a client 
and for clients to dynamically request an access token for use at a particular 
resource server.  You can call that custom architecture if you want.  It’s 
well-defined but it’s not currently in the standards realm.  I know that Google 
has syntax for doing the same, as I’m sure do a lot of other cloud OAuth 
deployments, such as Oracle’s.  For what it’s worth, the working group talked 
about possibly producing a standard version of syntax for making these kinds of 
requests during our discussions in Prague (during the Token Exchange 
discussion) but nobody has run with this yet.
 
In this sense, yes, Azure is an application of the kind we’re talking about.  
Azure already does define specific new OAuth 2.0 discovery metadata values that 
are used in production.  A registry just doesn’t yet exist in which it can 
register those that are of general applicability.
 
 

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[George Fletcher]

+1 for “OAuth 2.0 Authorization Server Discovery”

On 2/25/16 2:10 PM, Mike Jones wrote:


Thanks for your thoughts, Vladimir.  I’m increasingly inclined to 
accept your suggestion to change the title from “OAuth 2.0 Discovery” 
to “OAuth 2.0 Authorization Server Discovery”. While the abstract 
already makes it clear that the scope of the document is AS discovery, 
doing so in the title seems like it could help clarify things, given 
that a lot of the discussion seems to be about resource discovery, 
which is out of scope of the document.


I’m not saying that resource discovery isn’t important – it is – but 
unlike authorization server discovery, where there’s lots of existing 
practice, including using the existing data format for describing 
OAuth implementations that aren’t being used with OpenID Connect, 
there’s no existing practice to standardize for resource discovery.  
The time to create a standard for that seems to be after existing 
practice has emerged.  It **might** or might not use new metadata 
values in the AS discovery document, but that’s still to be 
determined.  The one reason to leave the title as-is is that resource 
discovery might end up involving extensions to this metadata format in 
some cases.


I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 
applies.  6749 is about the AS.  6750 is about the RS.  The discovery 
document is about the AS.  We don’t yet have a specification or 
existing practice for RS discovery, which would be the 6750 analogy.


In summary, which title do people prefer?

·“OAuth 2.0 Discovery”

·“OAuth 2.0 Authorization Server Discovery”

-- Mike

*From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Vladimir 
Dzhuvinov

*Sent:* Thursday, February 25, 2016 12:59 AM
*To:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location

In OIDC the discovery doc is of great utility to developers and 
integrators. Developers also tend to find it a more accurate and 
complete description of how to set up a client for a particular 
deployment, compared to traditional online docs, which may be not be 
up to date, or even missing. Very much like auto-generated Swagger and 
JavaDocs.


Here are some example OIDC discovery docs:

https://accounts.google.com/.well-known/openid-configuration

https://www.paypalobjects.com/.well-known/openid-configuration

https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration


With this discovery document in place setup of identity federation can 
then be easily scripted. For example:


http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html


Now, does that dictate any particular app architecture? My reading of 
the spec is that it doesn't, and it shouldn't either. By staying 
neutral on the topics of RS discovery and registering RPs with RSs. 
And how one arrives at the ".well-known/...". I'm not even sure that 
resource discovery should be a topic of this WG. Perhaps to this end, 
and to prevent confusion that the spec is trying to do something more, 
a more specific title would suit it better. E.g. "AS Discovery".


Cheers,

Vladimir



On 25/02/16 02:25, Phil Hunt (IDM) wrote:

And so does oracle and so does google. Each different.

So how can an app dictate it then unless we all go to a common architecture?

Phil

On Feb 24, 2016, at 16:04, Mike Jones 
<mailto:michael.jo...@microsoft.com>  wrote:

Azure defines ways for resource servers to be registered for use with a 
client and for clients to dynamically request an access token for use at a 
particular resource server.  You can call that custom architecture if you want. 
 It’s well-defined but it’s not currently in the standards realm.  I know that 
Google has syntax for doing the same, as I’m sure do a lot of other cloud OAuth 
deployments, such as Oracle’s.  For what it’s worth, the working group talked 
about possibly producing a standard version of syntax for making these kinds of 
requests during our discussions in Prague (during the Token Exchange 
discussion) but nobody has run with this yet.

  


In this sense, yes, Azure is an application of the kind we’re talking 
about.  Azure already does define specific new OAuth 2.0 discovery metadata 
values that are used in production.  A registry just doesn’t yet exist in which 
it can register those that are of general applicability.

  


 -- Mike

  


From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com]

Sent: Wednesday, February 24, 2016 3:52 PM

To: Mike Jones

Cc: <mailto:oauth@ietf.org>

    Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

  


Mike

  


Take a look at the assumptions you are making.

  


You seem to 

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Mike Jones]

Thanks for your thoughts, Vladimir.  I’m increasingly inclined to accept your 
suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0 
Authorization Server Discovery”.  While the abstract already makes it clear 
that the scope of the document is AS discovery, doing so in the title seems 
like it could help clarify things, given that a lot of the discussion seems to 
be about resource discovery, which is out of scope of the document.

I’m not saying that resource discovery isn’t important – it is – but unlike 
authorization server discovery, where there’s lots of existing practice, 
including using the existing data format for describing OAuth implementations 
that aren’t being used with OpenID Connect, there’s no existing practice to 
standardize for resource discovery.  The time to create a standard for that 
seems to be after existing practice has emerged.  It *might* or might not use 
new metadata values in the AS discovery document, but that’s still to be 
determined.  The one reason to leave the title as-is is that resource discovery 
might end up involving extensions to this metadata format in some cases.

I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 applies.  
6749 is about the AS.  6750 is about the RS.  The discovery document is about 
the AS.  We don’t yet have a specification or existing practice for RS 
discovery, which would be the 6750 analogy.

In summary, which title do people prefer?

·   “OAuth 2.0 Discovery”

·   “OAuth 2.0 Authorization Server Discovery”

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Vladimir Dzhuvinov
Sent: Thursday, February 25, 2016 12:59 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

In OIDC the discovery doc is of great utility to developers and integrators. 
Developers also tend to find it a more accurate and complete description of how 
to set up a client for a particular deployment, compared to traditional online 
docs, which may be not be up to date, or even missing. Very much like 
auto-generated Swagger and JavaDocs.

Here are some example OIDC discovery docs:

https://accounts.google.com/.well-known/openid-configuration

https://www.paypalobjects.com/.well-known/openid-configuration

https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration


With this discovery document in place setup of identity federation can then be 
easily scripted. For example:

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html


Now, does that dictate any particular app architecture? My reading of the spec 
is that it doesn't, and it shouldn't either. By staying neutral on the topics 
of RS discovery and registering RPs with RSs. And how one arrives at the 
".well-known/...". I'm not even sure that resource discovery should be a topic 
of this WG. Perhaps to this end, and to prevent confusion that the spec is 
trying to do something more, a more specific title would suit it better. E.g. 
"AS Discovery".

Cheers,

Vladimir



On 25/02/16 02:25, Phil Hunt (IDM) wrote:

And so does oracle and so does google. Each different.



So how can an app dictate it then unless we all go to a common architecture?



Phil



On Feb 24, 2016, at 16:04, Mike Jones 
<mailto:michael.jo...@microsoft.com> wrote:



Azure defines ways for resource servers to be registered for use with a client 
and for clients to dynamically request an access token for use at a particular 
resource server.  You can call that custom architecture if you want.  It’s 
well-defined but it’s not currently in the standards realm.  I know that Google 
has syntax for doing the same, as I’m sure do a lot of other cloud OAuth 
deployments, such as Oracle’s.  For what it’s worth, the working group talked 
about possibly producing a standard version of syntax for making these kinds of 
requests during our discussions in Prague (during the Token Exchange 
discussion) but nobody has run with this yet.



In this sense, yes, Azure is an application of the kind we’re talking about.  
Azure already does define specific new OAuth 2.0 discovery metadata values that 
are used in production.  A registry just doesn’t yet exist in which it can 
register those that are of general applicability.



-- Mike



From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com]

Sent: Wednesday, February 24, 2016 3:52 PM

To: Mike Jones

Cc: <mailto:oauth@ietf.org>

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location



Mike



Take a look at the assumptions you are making.



You seem to be assuming application software dictates oauth infrastructure 
architecture by suggesting that apps register in iana.



Would ms azure allow custom arch?



Phil



On Feb 24, 2016, at 15:28, Mike Jones 
<mailto:m

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Thomas Broyer]

On Thu, Feb 25, 2016 at 4:25 PM George Fletcher  wrote:

> Interesting... this is not at all my current experience:) If a RS goes
> from v2 of it's API to v3 and that RS uses the current standard of putting
> a "v2" or"v3" in it's API path... then a token issued for v2 of the API can
> not be sent to v3 of the API, because v3 wasn't wasn't registered/deployed
> when the token was issued.
>

Add to that:

   - "restful" APIs have a lot of "endpoints" related to a single scope
   - I know at least one AS that doesn't require RSs to register (I wonder
   how it all works, and whether it's really secure –I hope so, given the
   known RSs–, but that's how it is): documentation can be found (in French)
   at https://doc.integ01.dev-franceconnect.fr/ (or
   https://integ01.dev-franceconnect.fr/ if the previous URL doesn't work
   for you, they have DNS configuration issues)
   - even UMA doesn't register "resources" themselves, but only "resource
   sets", and it doesn't even require a) an URI for the resource set, or b)
   any "relationship" between the resource set URI (if any) and the URIs of
   the resources "in" the resource set:
   https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html



> The constant management of scopes to URI endpoints seems like a complexity
> that will quickly get out of hand.
>

+1
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Donald F. Coffin]

Nat,

 

The information that will be used to update the NAESB REQ.21 Standard can be 
found at http://greenbuttondata.org.  The document that defines the 
Authorization requirements is referenced as the “GreenButton Implementation 
Agreement 
<http://osgug.ucaiug.org/sgsystems/OpenADE/Shared%20Documents/Testing%20and%20Certification/GreenButtonTestPlan/referenceMaterial/GreenButtonAuthorization.docx>
 ”.   The current NAESB REQ.21 Standard is available on the NAESB Website, but 
is a copyrighted standard and cost $250.00.  However, NAESB does provide the 
standard for evaluation purposes, by contacting the NAESB office at 
na...@naesb.org <mailto:na...@naesb.org> .

 

The Green Button website is the technical repository for the Green Button 
initiative.  Therefore, there are several technical documents and videos 
available.  Let me know if you need help finding anything.

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

 

Phone:  (949) 636-8571

Email:<mailto:donald.cof...@reminetworks.com> 
donald.cof...@reminetworks.com

 

From: Nat Sakimura [mailto:sakim...@gmail.com] 
Sent: Thursday, February 25, 2016 10:17 AM
To: Donald F. Coffin ; Vladimir Dzhuvinov 
; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

 

Interesting. Is there a link that I can download your spec etc. ? 

 

I have not much preference over the actual endpoint link or the web origin. As 
long as the semantics is clear, either is fine. 

I was even considering using URI template. It will be extremely flexible, but I 
am not sure about the current status of the library availability and its 
qualities. 

 

Re: RFC5988 header or JSON - If you go back to earlier drafts, I was using 
JSON. This will make it independent of HTTPS. 

Also, developers can just process the JSON and store it in JSON. This is a 
overall win. 

Downside is that there is no standard for doing JSON metadata. Since Swagger is 
using JSON Schema way of expressing it, perhaps that's the way we should go, 
though, HAL seems to be a bit more efficient and nice. 

 

In either way, though, IMHO, it is important to define the link relation in the 
RFC5988 IANA registry. 

Converting RFC5988 link header to either JSON schema metadata or HAL is 
trivial. 

 

Nat

 

 

2016年2月25日(木) 23:05 Donald F. Coffin mailto:donald.cof...@reminetworks.com> >:

In fact, this is the method being used by utilities implementing the Green 
Button Connect My Data interface (North American Energy Standards Boards’ 
(NAESB) Retail Energy Quadrant 21 (REQ.21) Standard (Energy Service Provider 
Interface – ESPI).  The Green Button Alliance is in the processing of updating 
the specification to use OAuth 2.0.  The industry OpenADE Task Force, which is 
the technical WG of the UCAIug, defined additional information be returned with 
the OAuth 2.0  Token Response that includes the URI of the resource to which 
the AT can be used.

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

 

Phone:  (949) 636-8571

Email:<mailto:donald.cof...@reminetworks.com> 
donald.cof...@reminetworks.com

 

From: Vladimir Dzhuvinov [mailto:vladi...@connect2id.com 
<mailto:vladi...@connect2id.com> ] 
Sent: Thursday, February 25, 2016 2:23 AM
To: oauth@ietf.org <mailto:oauth@ietf.org> 


Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

 

 

On 25/02/16 09:02, Manger, James wrote:

I'm concerned that forcing the AS to know about all RS's endpoints that will 
accept it's tokens creates a very brittle deployment architecture

 
The AS is issuing temporary credentials (access_tokens) to clients but doesn’t 
know where those credentials will work? That’s broken.
 
An AS should absolutely indicate where an access_token can be used. 
draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” 
(resource URI) values in an HTTP Link header. A better approach would be 
including a list of web origins in the token response beside the access_token 
field.

+1 

This will appear more consistent with the current experience, and OAuth does 
allow the token response JSON object to be extended with additional members (as 
it's done in OpenID Connect already).

Cheers,
Vladimir



--
James Manger
 
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of George Fletcher
Sent: Thursday, 25 February 2016 6:17 AM
To: Phil Hunt  <mailto:phil.h...@oracle.com> ; Nat 
Sakimura  <mailto:sakim...@gmail.com> 
Cc:  <mailto:oauth@ietf.org>   <mailto:oauth@ietf.org> 

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
 
I'm concerned that forcing the AS to know about all RS's endpoints that will 
accept it's tokens creates a very brittle deployment architecture. What if a RS 
moves to a new endpoint? All clients would be required to get new t

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Vladimir Dzhuvinov]

I made a mistake in my response (good to never rush things :)

My +1 was for moving the suggested metadata params from the "Link"
header to the JSON object that represents the token response. Because in
there we already have the token itself and associated metadata
(expiration and scope).

I still haven't made up my mind about the spec as a whole though.

On 25/02/16 17:27, George Fletcher wrote:
> That said, I'm not against the AS informing the client that the token
> can be used at the MailResource, ContactResource and MessagingResource
> to help the client know not to send the token to a BlogResource.
> However, identifying the actual endpoint seems overly complex when
> what is really trying to be protected is a token from being used where
> it shouldn't be (which is solved by Pop)
>
> Thanks,
> George
>
> On 2/25/16 10:25 AM, George Fletcher wrote:
>> Interesting... this is not at all my current experience:) If a RS
>> goes from v2 of it's API to v3 and that RS uses the current standard
>> of putting a "v2" or"v3" in it's API path... then a token issued for
>> v2 of the API can not be sent to v3 of the API, because v3 wasn't
>> wasn't registered/deployed when the token was issued.
>>
>> The constant management of scopes to URI endpoints seems like a
>> complexity that will quickly get out of hand.
>>
>> Thanks,
>> George
>>
>> On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
>>>
>>>
>>> On 25/02/16 09:02, Manger, James wrote:
>>>>> I'm concerned that forcing the AS to know about all RS's endpoints
>>>>> that will accept it's tokens creates a very brittle deployment
>>>>> architecture
>>>> The AS is issuing temporary credentials (access_tokens) to clients
>>>> but doesn’t know where those credentials will work? That’s broken.
>>>>
>>>> An AS should absolutely indicate where an access_token can be used.
>>>> draft-sakimura-oauth-meta suggests indicating this with 1 or more
>>>> “ruri” (resource URI) values in an HTTP Link header. A better
>>>> approach would be including a list of web origins in the token
>>>> response beside the access_token field.
>>> +1
>>>
>>> This will appear more consistent with the current experience, and
>>> OAuth does allow the token response JSON object to be extended with
>>> additional members (as it's done in OpenID Connect already).
>>>
>>> Cheers,
>>> Vladimir
>>>
>>>> -- 
>>>> James Manger
>>>>
>>>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of George
>>>> Fletcher
>>>> Sent: Thursday, 25 February 2016 6:17 AM
>>>> To: Phil Hunt; Nat Sakimura
>>>> Cc:  
>>>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>>>
>>>> I'm concerned that forcing the AS to know about all RS's endpoints
>>>> that will accept it's tokens creates a very brittle deployment
>>>> architecture. What if a RS moves to a new endpoint? All clients
>>>> would be required to get new tokens (if I understand correctly).
>>>> And the RS move would have to coordinate with the AS to make sure
>>>> all the timing is perfect in the switch over of endpoints.
>>>>
>>>> I suspect a common deployment architecture today is that each RS
>>>> requires one or more scopes to access it's resources. The client
>>>> then asks the user to authorize a token with a requested list of
>>>> scopes. The client can then send the token to the appropriate RS
>>>> endpoint. The RS will not authorize access unless the token has the
>>>> required scopes.
>>>>
>>>> If the concern is that the client may accidentally send the token
>>>> to a "bad" RS which will then replay the token, then I'd rather use
>>>> a PoP mechanism because the point is that you want to ensure the
>>>> correct client is presenting the token. Trying to ensure the client
>>>> doesn't send the token to the wrong endpoint seems fraught with
>>>> problems.
>>>>
>>>> Thanks,
>>>> George
>>>>
>>>>
>>>> ___
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>




smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[George Fletcher]

That said, I'm not against the AS informing the client that the token 
can be used at the MailResource, ContactResource and MessagingResource 
to help the client know not to send the token to a BlogResource. 
However, identifying the actual endpoint seems overly complex when what 
is really trying to be protected is a token from being used where it 
shouldn't be (which is solved by Pop)


Thanks,
George

On 2/25/16 10:25 AM, George Fletcher wrote:
Interesting... this is not at all my current experience:) If a RS goes 
from v2 of it's API to v3 and that RS uses the current standard of 
putting a "v2" or"v3" in it's API path... then a token issued for v2 
of the API can not be sent to v3 of the API, because v3 wasn't wasn't 
registered/deployed when the token was issued.


The constant management of scopes to URI endpoints seems like a 
complexity that will quickly get out of hand.


Thanks,
George

On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:



On 25/02/16 09:02, Manger, James wrote:

I'm concerned that forcing the AS to know about all RS's endpoints that will 
accept it's tokens creates a very brittle deployment architecture

The AS is issuing temporary credentials (access_tokens) to clients but doesn’t 
know where those credentials will work? That’s broken.

An AS should absolutely indicate where an access_token can be used. 
draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” 
(resource URI) values in an HTTP Link header. A better approach would be 
including a list of web origins in the token response beside the access_token 
field.

+1

This will appear more consistent with the current experience, and 
OAuth does allow the token response JSON object to be extended with 
additional members (as it's done in OpenID Connect already).


Cheers,
Vladimir


--
James Manger

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of George Fletcher
Sent: Thursday, 25 February 2016 6:17 AM
To: Phil Hunt; Nat Sakimura
Cc:  
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I'm concerned that forcing the AS to know about all RS's endpoints that will 
accept it's tokens creates a very brittle deployment architecture. What if a RS 
moves to a new endpoint? All clients would be required to get new tokens (if I 
understand correctly). And the RS move would have to coordinate with the AS to 
make sure all the timing is perfect in the switch over of endpoints.

I suspect a common deployment architecture today is that each RS requires one 
or more scopes to access it's resources. The client then asks the user to 
authorize a token with a requested list of scopes. The client can then send the 
token to the appropriate RS endpoint. The RS will not authorize access unless 
the token has the required scopes.

If the concern is that the client may accidentally send the token to a "bad" RS 
which will then replay the token, then I'd rather use a PoP mechanism because the point 
is that you want to ensure the correct client is presenting the token. Trying to ensure 
the client doesn't send the token to the wrong endpoint seems fraught with problems.

Thanks,
George


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[George Fletcher]

Interesting... this is not at all my current experience:) If a RS goes 
from v2 of it's API to v3 and that RS uses the current standard of 
putting a "v2" or"v3" in it's API path... then a token issued for v2 of 
the API can not be sent to v3 of the API, because v3 wasn't wasn't 
registered/deployed when the token was issued.


The constant management of scopes to URI endpoints seems like a 
complexity that will quickly get out of hand.


Thanks,
George

On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:



On 25/02/16 09:02, Manger, James wrote:

I'm concerned that forcing the AS to know about all RS's endpoints that will 
accept it's tokens creates a very brittle deployment architecture

The AS is issuing temporary credentials (access_tokens) to clients but doesn’t 
know where those credentials will work? That’s broken.

An AS should absolutely indicate where an access_token can be used. 
draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” 
(resource URI) values in an HTTP Link header. A better approach would be 
including a list of web origins in the token response beside the access_token 
field.

+1

This will appear more consistent with the current experience, and 
OAuth does allow the token response JSON object to be extended with 
additional members (as it's done in OpenID Connect already).


Cheers,
Vladimir


--
James Manger

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of George Fletcher
Sent: Thursday, 25 February 2016 6:17 AM
To: Phil Hunt; Nat Sakimura
Cc:  
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I'm concerned that forcing the AS to know about all RS's endpoints that will 
accept it's tokens creates a very brittle deployment architecture. What if a RS 
moves to a new endpoint? All clients would be required to get new tokens (if I 
understand correctly). And the RS move would have to coordinate with the AS to 
make sure all the timing is perfect in the switch over of endpoints.

I suspect a common deployment architecture today is that each RS requires one 
or more scopes to access it's resources. The client then asks the user to 
authorize a token with a requested list of scopes. The client can then send the 
token to the appropriate RS endpoint. The RS will not authorize access unless 
the token has the required scopes.

If the concern is that the client may accidentally send the token to a "bad" RS 
which will then replay the token, then I'd rather use a PoP mechanism because the point 
is that you want to ensure the correct client is presenting the token. Trying to ensure 
the client doesn't send the token to the wrong endpoint seems fraught with problems.

Thanks,
George


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Nat Sakimura]

Interesting. Is there a link that I can download your spec etc. ?

I have not much preference over the actual endpoint link or the web origin.
As long as the semantics is clear, either is fine.
I was even considering using URI template. It will be extremely flexible,
but I am not sure about the current status of the library availability and
its qualities.

Re: RFC5988 header or JSON - If you go back to earlier drafts, I was using
JSON. This will make it independent of HTTPS.
Also, developers can just process the JSON and store it in JSON. This is a
overall win.
Downside is that there is no standard for doing JSON metadata. Since
Swagger is using JSON Schema way of expressing it, perhaps that's the way
we should go, though, HAL seems to be a bit more efficient and nice.

In either way, though, IMHO, it is important to define the link relation in
the RFC5988 IANA registry.
Converting RFC5988 link header to either JSON schema metadata or HAL is
trivial.

Nat


2016年2月25日(木) 23:05 Donald F. Coffin :

> In fact, this is the method being used by utilities implementing the Green
> Button Connect My Data interface (North American Energy Standards Boards’
> (NAESB) Retail Energy Quadrant 21 (REQ.21) Standard (Energy Service
> Provider Interface – ESPI).  The Green Button Alliance is in the processing
> of updating the specification to use OAuth 2.0.  The industry OpenADE Task
> Force, which is the technical WG of the UCAIug, defined additional
> information be returned with the OAuth 2.0  Token Response that includes
> the URI of the resource to which the AT can be used.
>
>
>
> Best regards,
>
> Don
>
> Donald F. Coffin
>
> Founder/CTO
>
>
>
> REMI Networks
>
> 2335 Dunwoody Xing #E
>
> Dunwoody, GA 30338-8221
>
>
>
> Phone:  (949) 636-8571
>
> Email:   donald.cof...@reminetworks.com
>
>
>
> *From:* Vladimir Dzhuvinov [mailto:vladi...@connect2id.com]
> *Sent:* Thursday, February 25, 2016 2:23 AM
> *To:* oauth@ietf.org
>
>
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
>
>
> On 25/02/16 09:02, Manger, James wrote:
>
> I'm concerned that forcing the AS to know about all RS's endpoints that will 
> accept it's tokens creates a very brittle deployment architecture
>
>
>
> The AS is issuing temporary credentials (access_tokens) to clients but 
> doesn’t know where those credentials will work? That’s broken.
>
>
>
> An AS should absolutely indicate where an access_token can be used. 
> draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” 
> (resource URI) values in an HTTP Link header. A better approach would be 
> including a list of web origins in the token response beside the access_token 
> field.
>
> +1
>
> This will appear more consistent with the current experience, and OAuth
> does allow the token response JSON object to be extended with additional
> members (as it's done in OpenID Connect already).
>
> Cheers,
> Vladimir
>
>
> --
>
> James Manger
>
>
>
> From: OAuth [mailto:oauth-boun...@ietf.org ] On 
> Behalf Of George Fletcher
>
> Sent: Thursday, 25 February 2016 6:17 AM
>
> To: Phil Hunt  ; Nat Sakimura 
>  
>
> Cc:
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> I'm concerned that forcing the AS to know about all RS's endpoints that will 
> accept it's tokens creates a very brittle deployment architecture. What if a 
> RS moves to a new endpoint? All clients would be required to get new tokens 
> (if I understand correctly). And the RS move would have to coordinate with 
> the AS to make sure all the timing is perfect in the switch over of endpoints.
>
>
>
> I suspect a common deployment architecture today is that each RS requires one 
> or more scopes to access it's resources. The client then asks the user to 
> authorize a token with a requested list of scopes. The client can then send 
> the token to the appropriate RS endpoint. The RS will not authorize access 
> unless the token has the required scopes.
>
>
>
> If the concern is that the client may accidentally send the token to a "bad" 
> RS which will then replay the token, then I'd rather use a PoP mechanism 
> because the point is that you want to ensure the correct client is presenting 
> the token. Trying to ensure the client doesn't send the token to the wrong 
> endpoint seems fraught with problems.
>
>
>
> Thanks,
>
> George
>
>
>
>
> ___
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[George Fletcher]

The AS knows the RS's that will consume it's tokens because it knows the 
scopes that it can allow the user to authorize. I don't think the AS 
MUST know the endpoints of the RS (which is what the current drafts 
require).


It is not often that the entity/group responsible for the Authorization 
Service is also responsible for the actual resource server. Take for 
example a Mail API run by one team and the Authorization server managed 
by the Identity team.


Requiring the Mail Team to notify and coordinate the change of endpoints 
for a new deployment is brittle.


Also, I believe the main reason for wanting to bind a token to an 
endpoint is to protect the token from being sent to a malicious RS and 
then having that RS replay the token. If possible replay of a token is 
the main concern, then why not use PoP which ensures that only the 
appropriate client and present the token. This seems a much cleaner way 
to protect against this threat.


Thanks,
George

On 2/25/16 2:02 AM, Manger, James wrote:


> I'm concerned that forcing the AS to know about all RS's endpoints 
that will accept it's tokens creates a very brittle deployment 
architecture


The AS is issuing temporary credentials (access_tokens) to clients but 
doesn’t know where those credentials will work? That’s broken.


An AS should absolutely indicate where an access_token can be used. 
draft-sakimura-oauth-meta suggests indicating this with 1 or more 
“ruri” (resource URI) values in an HTTP Link header. A better approach 
would be including a list of web origins in the token response beside 
the access_token field.


--

James Manger

*From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *George 
Fletcher

*Sent:* Thursday, 25 February 2016 6:17 AM
*To:* Phil Hunt ; Nat Sakimura 
*Cc:*  
*Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I'm concerned that forcing the AS to know about all RS's endpoints 
that will accept it's tokens creates a very brittle deployment 
architecture. What if a RS moves to a new endpoint? All clients would 
be required to get new tokens (if I understand correctly). And the RS 
move would have to coordinate with the AS to make sure all the timing 
is perfect in the switch over of endpoints.


I suspect a common deployment architecture today is that each RS 
requires one or more scopes to access it's resources. The client then 
asks the user to authorize a token with a requested list of scopes. 
The client can then send the token to the appropriate RS endpoint. The 
RS will not authorize access unless the token has the required scopes.


If the concern is that the client may accidentally send the token to a 
"bad" RS which will then replay the token, then I'd rather use a PoP 
mechanism because the point is that you want to ensure the correct 
client is presenting the token. Trying to ensure the client doesn't 
send the token to the wrong endpoint seems fraught with problems.


Thanks,
George



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Donald F. Coffin]

In fact, this is the method being used by utilities implementing the Green
Button Connect My Data interface (North American Energy Standards Boards'
(NAESB) Retail Energy Quadrant 21 (REQ.21) Standard (Energy Service Provider
Interface - ESPI).  The Green Button Alliance is in the processing of
updating the specification to use OAuth 2.0.  The industry OpenADE Task
Force, which is the technical WG of the UCAIug, defined additional
information be returned with the OAuth 2.0  Token Response that includes the
URI of the resource to which the AT can be used.

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

 

Phone:  (949) 636-8571

Email:<mailto:donald.cof...@reminetworks.com>
donald.cof...@reminetworks.com

 

From: Vladimir Dzhuvinov [mailto:vladi...@connect2id.com] 
Sent: Thursday, February 25, 2016 2:23 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

 

 

On 25/02/16 09:02, Manger, James wrote:

I'm concerned that forcing the AS to know about all RS's endpoints that will
accept it's tokens creates a very brittle deployment architecture

 
The AS is issuing temporary credentials (access_tokens) to clients but
doesn't know where those credentials will work? That's broken.
 
An AS should absolutely indicate where an access_token can be used.
draft-sakimura-oauth-meta suggests indicating this with 1 or more "ruri"
(resource URI) values in an HTTP Link header. A better approach would be
including a list of web origins in the token response beside the
access_token field.

+1 

This will appear more consistent with the current experience, and OAuth does
allow the token response JSON object to be extended with additional members
(as it's done in OpenID Connect already).

Cheers,
Vladimir




--
James Manger
 
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of George Fletcher
Sent: Thursday, 25 February 2016 6:17 AM
To: Phil Hunt  <mailto:phil.h...@oracle.com> ; Nat
Sakimura  <mailto:sakim...@gmail.com> 
Cc:  <mailto:oauth@ietf.org>   <mailto:oauth@ietf.org>

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
 
I'm concerned that forcing the AS to know about all RS's endpoints that will
accept it's tokens creates a very brittle deployment architecture. What if a
RS moves to a new endpoint? All clients would be required to get new tokens
(if I understand correctly). And the RS move would have to coordinate with
the AS to make sure all the timing is perfect in the switch over of
endpoints.
 
I suspect a common deployment architecture today is that each RS requires
one or more scopes to access it's resources. The client then asks the user
to authorize a token with a requested list of scopes. The client can then
send the token to the appropriate RS endpoint. The RS will not authorize
access unless the token has the required scopes.
 
If the concern is that the client may accidentally send the token to a "bad"
RS which will then replay the token, then I'd rather use a PoP mechanism
because the point is that you want to ensure the correct client is
presenting the token. Trying to ensure the client doesn't send the token to
the wrong endpoint seems fraught with problems.
 
Thanks,
George






___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org> 
https://www.ietf.org/mailman/listinfo/oauth

 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Vladimir Dzhuvinov]

In OIDC the discovery doc is of great utility to developers and
integrators. Developers also tend to find it a more accurate and
complete description of how to set up a client for a particular
deployment, compared to traditional online docs, which may be not be up
to date, or even missing. Very much like auto-generated Swagger and
JavaDocs.

Here are some example OIDC discovery docs:

https://accounts.google.com/.well-known/openid-configuration

https://www.paypalobjects.com/.well-known/openid-configuration

https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration


With this discovery document in place setup of identity federation can
then be easily scripted. For example:

http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html


Now, does that dictate any particular app architecture? My reading of
the spec is that it doesn't, and it shouldn't either. By staying neutral
on the topics of RS discovery and registering RPs with RSs. And how one
arrives at the ".well-known/...". I'm not even sure that resource
discovery should be a topic of this WG. Perhaps to this end, and to
prevent confusion that the spec is trying to do something more, a more
specific title would suit it better. E.g. "AS Discovery".

Cheers,

Vladimir




On 25/02/16 02:25, Phil Hunt (IDM) wrote:
> And so does oracle and so does google. Each different. 
>
> So how can an app dictate it then unless we all go to a common architecture?
>
> Phil
>
>> On Feb 24, 2016, at 16:04, Mike Jones  wrote:
>>
>> Azure defines ways for resource servers to be registered for use with a 
>> client and for clients to dynamically request an access token for use at a 
>> particular resource server.  You can call that custom architecture if you 
>> want.  It’s well-defined but it’s not currently in the standards realm.  I 
>> know that Google has syntax for doing the same, as I’m sure do a lot of 
>> other cloud OAuth deployments, such as Oracle’s.  For what it’s worth, the 
>> working group talked about possibly producing a standard version of syntax 
>> for making these kinds of requests during our discussions in Prague (during 
>> the Token Exchange discussion) but nobody has run with this yet.
>>  
>> In this sense, yes, Azure is an application of the kind we’re talking about. 
>>  Azure already does define specific new OAuth 2.0 discovery metadata values 
>> that are used in production.  A registry just doesn’t yet exist in which it 
>> can register those that are of general applicability.
>>  
>>     -- Mike
>>  
>> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
>> Sent: Wednesday, February 24, 2016 3:52 PM
>> To: Mike Jones
>> Cc: 
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>  
>> Mike
>>  
>> Take a look at the assumptions you are making. 
>>  
>> You seem to be assuming application software dictates oauth infrastructure 
>> architecture by suggesting that apps register in iana.  
>>  
>> Would ms azure allow custom arch?
>>
>> Phil
>>
>> On Feb 24, 2016, at 15:28, Mike Jones  wrote:
>>
>> The UserInfo Endpoint path isn’t fixed and so has to be discovered.
>>  
>> I agree that for some OAuth profiles, one or more resource servers will have 
>> to be discovered starting from the authorization server.  Working group 
>> members have also described wanting to discover authorization servers 
>> starting from resource servers.  There isn’t a standard practice for any of 
>> this, which is why it’s intentionally left out of the current specification.
>>  
>> Once the IANA OAuth Discovery Metadata Registry has been established, which 
>> will happen after the current specification has been approved, it will be 
>> easy for subsequent specifications to document existing practice for 
>> different OAuth profiles and register discovery metadata values supporting 
>> them.  Some of those values will likely define ways to discover resource 
>> servers, when applicable.
>>  
>> But first, we need to finish the existing spec, so that the registry 
>> enabling these extensions gets established in the first place.
>>  
>> -- Mike
>>  
>> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
>> Sent: Wednesday, February 24, 2016 2:13 PM
>> To: Mike Jones 
>> Cc:  
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>  
>> Yup. And because there many relations the client mist be able to discover 
>

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Vladimir Dzhuvinov]

On 25/02/16 09:02, Manger, James wrote:
>> I'm concerned that forcing the AS to know about all RS's endpoints that will 
>> accept it's tokens creates a very brittle deployment architecture
> The AS is issuing temporary credentials (access_tokens) to clients but 
> doesn’t know where those credentials will work? That’s broken.
>
> An AS should absolutely indicate where an access_token can be used. 
> draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” 
> (resource URI) values in an HTTP Link header. A better approach would be 
> including a list of web origins in the token response beside the access_token 
> field.
+1

This will appear more consistent with the current experience, and OAuth
does allow the token response JSON object to be extended with additional
members (as it's done in OpenID Connect already).

Cheers,
Vladimir

> --
> James Manger
>
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of George Fletcher
> Sent: Thursday, 25 February 2016 6:17 AM
> To: Phil Hunt ; Nat Sakimura 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> I'm concerned that forcing the AS to know about all RS's endpoints that will 
> accept it's tokens creates a very brittle deployment architecture. What if a 
> RS moves to a new endpoint? All clients would be required to get new tokens 
> (if I understand correctly). And the RS move would have to coordinate with 
> the AS to make sure all the timing is perfect in the switch over of endpoints.
>
> I suspect a common deployment architecture today is that each RS requires one 
> or more scopes to access it's resources. The client then asks the user to 
> authorize a token with a requested list of scopes. The client can then send 
> the token to the appropriate RS endpoint. The RS will not authorize access 
> unless the token has the required scopes.
>
> If the concern is that the client may accidentally send the token to a "bad" 
> RS which will then replay the token, then I'd rather use a PoP mechanism 
> because the point is that you want to ensure the correct client is presenting 
> the token. Trying to ensure the client doesn't send the token to the wrong 
> endpoint seems fraught with problems.
>
> Thanks,
> George
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Manger, James]

> I'm concerned that forcing the AS to know about all RS's endpoints that will 
> accept it's tokens creates a very brittle deployment architecture

The AS is issuing temporary credentials (access_tokens) to clients but doesn’t 
know where those credentials will work? That’s broken.

An AS should absolutely indicate where an access_token can be used. 
draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” 
(resource URI) values in an HTTP Link header. A better approach would be 
including a list of web origins in the token response beside the access_token 
field.

--
James Manger

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of George Fletcher
Sent: Thursday, 25 February 2016 6:17 AM
To: Phil Hunt ; Nat Sakimura 
Cc:  
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I'm concerned that forcing the AS to know about all RS's endpoints that will 
accept it's tokens creates a very brittle deployment architecture. What if a RS 
moves to a new endpoint? All clients would be required to get new tokens (if I 
understand correctly). And the RS move would have to coordinate with the AS to 
make sure all the timing is perfect in the switch over of endpoints.

I suspect a common deployment architecture today is that each RS requires one 
or more scopes to access it's resources. The client then asks the user to 
authorize a token with a requested list of scopes. The client can then send the 
token to the appropriate RS endpoint. The RS will not authorize access unless 
the token has the required scopes.

If the concern is that the client may accidentally send the token to a "bad" RS 
which will then replay the token, then I'd rather use a PoP mechanism because 
the point is that you want to ensure the correct client is presenting the 
token. Trying to ensure the client doesn't send the token to the wrong endpoint 
seems fraught with problems.

Thanks,
George
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Phil Hunt (IDM)]

And so does oracle and so does google. Each different. 

So how can an app dictate it then unless we all go to a common architecture?

Phil

> On Feb 24, 2016, at 16:04, Mike Jones  wrote:
> 
> Azure defines ways for resource servers to be registered for use with a 
> client and for clients to dynamically request an access token for use at a 
> particular resource server.  You can call that custom architecture if you 
> want.  It’s well-defined but it’s not currently in the standards realm.  I 
> know that Google has syntax for doing the same, as I’m sure do a lot of other 
> cloud OAuth deployments, such as Oracle’s.  For what it’s worth, the working 
> group talked about possibly producing a standard version of syntax for making 
> these kinds of requests during our discussions in Prague (during the Token 
> Exchange discussion) but nobody has run with this yet.
>  
> In this sense, yes, Azure is an application of the kind we’re talking about.  
> Azure already does define specific new OAuth 2.0 discovery metadata values 
> that are used in production.  A registry just doesn’t yet exist in which it 
> can register those that are of general applicability.
>  
> -- Mike
>  
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
> Sent: Wednesday, February 24, 2016 3:52 PM
> To: Mike Jones
> Cc: 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> Mike
>  
> Take a look at the assumptions you are making. 
>  
> You seem to be assuming application software dictates oauth infrastructure 
> architecture by suggesting that apps register in iana.  
>  
> Would ms azure allow custom arch?
> 
> Phil
> 
> On Feb 24, 2016, at 15:28, Mike Jones  wrote:
> 
> The UserInfo Endpoint path isn’t fixed and so has to be discovered.
>  
> I agree that for some OAuth profiles, one or more resource servers will have 
> to be discovered starting from the authorization server.  Working group 
> members have also described wanting to discover authorization servers 
> starting from resource servers.  There isn’t a standard practice for any of 
> this, which is why it’s intentionally left out of the current specification.
>  
> Once the IANA OAuth Discovery Metadata Registry has been established, which 
> will happen after the current specification has been approved, it will be 
> easy for subsequent specifications to document existing practice for 
> different OAuth profiles and register discovery metadata values supporting 
> them.  Some of those values will likely define ways to discover resource 
> servers, when applicable.
>  
> But first, we need to finish the existing spec, so that the registry enabling 
> these extensions gets established in the first place.
>  
>         -- Mike
>  
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
> Sent: Wednesday, February 24, 2016 2:13 PM
> To: Mike Jones 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> Yup. And because there many relations the client mist be able to discover it. 
> The client does not know if the res server is legit. 
>  
> The userinfo is always fix and so u dont need discovery. 
> 
> Phil
> 
> On Feb 24, 2016, at 14:05, Mike Jones  wrote:
> 
> In OpenID Connect, there’s a resource server called the UserInfo Endpoint 
> that returns claims about the authenticated user as a JSON data structure.  
> Its location is published in OpenID Connect discovery metadata as the 
> “userinfo_endpoint” metadata value, which is defined at 
> http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.
>  
> We didn’t include the UserInfo Endpoint in the generic OAuth discovery spec 
> since in OAuth, there are lots of possible relationships between 
> authorization servers and resource servers and they needn’t be one-to-one, as 
> is being actively discussed by the working group.  For instance, see George 
> Fletcher’s recent contribution.
>  
> Thanks for the good discussion, Phil.
>  
> -- Mike
>  
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
> Sent: Wednesday, February 24, 2016 1:25 PM
> To: Mike Jones
> Cc: 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> Where is the profile endpoint (oidc's resource server) published? (For the 
> non OIDC people on the list). 
> 
> Phil
> 
> On Feb 24, 2016, at 13:09, Mike Jones  wrote:
> 
> To the extent that generic OAuth 2.0 needs to publish some of the same 
> information as OpenID Connect – which is built on generic OAuth 2.0 – it 
> makes sense to publish th

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Mike Jones]

Azure defines ways for resource servers to be registered for use with a client 
and for clients to dynamically request an access token for use at a particular 
resource server.  You can call that custom architecture if you want.  It’s 
well-defined but it’s not currently in the standards realm.  I know that Google 
has syntax for doing the same, as I’m sure do a lot of other cloud OAuth 
deployments, such as Oracle’s.  For what it’s worth, the working group talked 
about possibly producing a standard version of syntax for making these kinds of 
requests during our discussions in Prague (during the Token Exchange 
discussion) but nobody has run with this yet.

In this sense, yes, Azure is an application of the kind we’re talking about.  
Azure already does define specific new OAuth 2.0 discovery metadata values that 
are used in production.  A registry just doesn’t yet exist in which it can 
register those that are of general applicability.

-- Mike

From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com]
Sent: Wednesday, February 24, 2016 3:52 PM
To: Mike Jones
Cc: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Mike

Take a look at the assumptions you are making.

You seem to be assuming application software dictates oauth infrastructure 
architecture by suggesting that apps register in iana.

Would ms azure allow custom arch?

Phil

On Feb 24, 2016, at 15:28, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
The UserInfo Endpoint path isn’t fixed and so has to be discovered.

I agree that for some OAuth profiles, one or more resource servers will have to 
be discovered starting from the authorization server.  Working group members 
have also described wanting to discover authorization servers starting from 
resource servers.  There isn’t a standard practice for any of this, which is 
why it’s intentionally left out of the current specification.

Once the IANA OAuth Discovery Metadata Registry has been established, which 
will happen after the current specification has been approved, it will be easy 
for subsequent specifications to document existing practice for different OAuth 
profiles and register discovery metadata values supporting them.  Some of those 
values will likely define ways to discover resource servers, when applicable.

But first, we need to finish the existing spec, so that the registry enabling 
these extensions gets established in the first place.

-- Mike

From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com]
Sent: Wednesday, February 24, 2016 2:13 PM
To: Mike Jones mailto:michael.jo...@microsoft.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Yup. And because there many relations the client mist be able to discover it. 
The client does not know if the res server is legit.

The userinfo is always fix and so u dont need discovery.

Phil

On Feb 24, 2016, at 14:05, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
In OpenID Connect, there’s a resource server called the UserInfo Endpoint that 
returns claims about the authenticated user as a JSON data structure.  Its 
location is published in OpenID Connect discovery metadata as the 
“userinfo_endpoint” metadata value, which is defined at 
http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.

We didn’t include the UserInfo Endpoint in the generic OAuth discovery spec 
since in OAuth, there are lots of possible relationships between authorization 
servers and resource servers and they needn’t be one-to-one, as is being 
actively discussed by the working group.  For instance, see George Fletcher’s 
recent contribution.

Thanks for the good discussion, Phil.

-- Mike

From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com]
Sent: Wednesday, February 24, 2016 1:25 PM
To: Mike Jones
Cc: mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Where is the profile endpoint (oidc's resource server) published? (For the non 
OIDC people on the list).

Phil

On Feb 24, 2016, at 13:09, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
To the extent that generic OAuth 2.0 needs to publish some of the same 
information as OpenID Connect – which is built on generic OAuth 2.0 – it makes 
sense to publish that information using exactly the same syntax, since that 
syntax is already in widespread use.  That what this draft accomplishes.

There’s nothing Connect-specific about using metadata response values like:

   "authorization_endpoint": "https://server.example.com/authorize";,
   "token_endpoint": "https://server.example.com/token";,
   "token_endpoint_auth_methods_supported": ["client_secret_basic", 
"private_key_jwt"]

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Phil Hunt (IDM)]

Mike

Take a look at the assumptions you are making. 

You seem to be assuming application software dictates oauth infrastructure 
architecture by suggesting that apps register in iana.  

Would ms azure allow custom arch?

Phil

> On Feb 24, 2016, at 15:28, Mike Jones  wrote:
> 
> The UserInfo Endpoint path isn’t fixed and so has to be discovered.
>  
> I agree that for some OAuth profiles, one or more resource servers will have 
> to be discovered starting from the authorization server.  Working group 
> members have also described wanting to discover authorization servers 
> starting from resource servers.  There isn’t a standard practice for any of 
> this, which is why it’s intentionally left out of the current specification.
>  
> Once the IANA OAuth Discovery Metadata Registry has been established, which 
> will happen after the current specification has been approved, it will be 
> easy for subsequent specifications to document existing practice for 
> different OAuth profiles and register discovery metadata values supporting 
> them.  Some of those values will likely define ways to discover resource 
> servers, when applicable.
>  
> But first, we need to finish the existing spec, so that the registry enabling 
> these extensions gets established in the first place.
>  
> -- Mike
>  
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
> Sent: Wednesday, February 24, 2016 2:13 PM
> To: Mike Jones 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> Yup. And because there many relations the client mist be able to discover it. 
> The client does not know if the res server is legit. 
>  
> The userinfo is always fix and so u dont need discovery. 
> 
> Phil
> 
> On Feb 24, 2016, at 14:05, Mike Jones  wrote:
> 
> In OpenID Connect, there’s a resource server called the UserInfo Endpoint 
> that returns claims about the authenticated user as a JSON data structure.  
> Its location is published in OpenID Connect discovery metadata as the 
> “userinfo_endpoint” metadata value, which is defined at 
> http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.
>  
> We didn’t include the UserInfo Endpoint in the generic OAuth discovery spec 
> since in OAuth, there are lots of possible relationships between 
> authorization servers and resource servers and they needn’t be one-to-one, as 
> is being actively discussed by the working group.  For instance, see George 
> Fletcher’s recent contribution.
>  
> Thanks for the good discussion, Phil.
>  
> -- Mike
>  
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
> Sent: Wednesday, February 24, 2016 1:25 PM
> To: Mike Jones
> Cc: 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> Where is the profile endpoint (oidc's resource server) published? (For the 
> non OIDC people on the list). 
> 
> Phil
> 
> On Feb 24, 2016, at 13:09, Mike Jones  wrote:
> 
> To the extent that generic OAuth 2.0 needs to publish some of the same 
> information as OpenID Connect – which is built on generic OAuth 2.0 – it 
> makes sense to publish that information using exactly the same syntax, since 
> that syntax is already in widespread use.  That what this draft accomplishes.
>  
> There’s nothing Connect-specific about using metadata response values like:
>  
>"authorization_endpoint": "https://server.example.com/authorize";,
>"token_endpoint": "https://server.example.com/token";,
>"token_endpoint_auth_methods_supported": ["client_secret_basic", 
> "private_key_jwt"],
>"registration_endpoint": "https://server.example.com/register";,
>"response_types_supported":  ["code", "token"],
>"service_documentation": 
> "http://server.example.com/service_documentation.html";,
>  
> Is there a reason that you would like the syntax for any of these or the 
> other generally applicable OAuth 2.0 metadata values to be different?  I 
> don’t see any good reason for unnecessary differences to be introduced.
>  
> -- Mike
>  
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
> Sent: Wednesday, February 24, 2016 12:45 PM
> To: Anthony Nadalin 
> Cc: Mike Jones ;  
> 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> Mike
>  
> Publishing on dev pages does not work for software (esp open source) that is 
> deployed both in enterprises and on PaaS cloud providers. 
>  
> The current

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Mike Jones]

The UserInfo Endpoint path isn’t fixed and so has to be discovered.

I agree that for some OAuth profiles, one or more resource servers will have to 
be discovered starting from the authorization server.  Working group members 
have also described wanting to discover authorization servers starting from 
resource servers.  There isn’t a standard practice for any of this, which is 
why it’s intentionally left out of the current specification.

Once the IANA OAuth Discovery Metadata Registry has been established, which 
will happen after the current specification has been approved, it will be easy 
for subsequent specifications to document existing practice for different OAuth 
profiles and register discovery metadata values supporting them.  Some of those 
values will likely define ways to discover resource servers, when applicable.

But first, we need to finish the existing spec, so that the registry enabling 
these extensions gets established in the first place.

-- Mike

From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com]
Sent: Wednesday, February 24, 2016 2:13 PM
To: Mike Jones 
Cc:  
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Yup. And because there many relations the client mist be able to discover it. 
The client does not know if the res server is legit.

The userinfo is always fix and so u dont need discovery.

Phil

On Feb 24, 2016, at 14:05, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
In OpenID Connect, there’s a resource server called the UserInfo Endpoint that 
returns claims about the authenticated user as a JSON data structure.  Its 
location is published in OpenID Connect discovery metadata as the 
“userinfo_endpoint” metadata value, which is defined at 
http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.

We didn’t include the UserInfo Endpoint in the generic OAuth discovery spec 
since in OAuth, there are lots of possible relationships between authorization 
servers and resource servers and they needn’t be one-to-one, as is being 
actively discussed by the working group.  For instance, see George Fletcher’s 
recent contribution.

Thanks for the good discussion, Phil.

-- Mike

From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com]
Sent: Wednesday, February 24, 2016 1:25 PM
To: Mike Jones
Cc: mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Where is the profile endpoint (oidc's resource server) published? (For the non 
OIDC people on the list).

Phil

On Feb 24, 2016, at 13:09, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
To the extent that generic OAuth 2.0 needs to publish some of the same 
information as OpenID Connect – which is built on generic OAuth 2.0 – it makes 
sense to publish that information using exactly the same syntax, since that 
syntax is already in widespread use.  That what this draft accomplishes.

There’s nothing Connect-specific about using metadata response values like:

   "authorization_endpoint": "https://server.example.com/authorize";,
   "token_endpoint": "https://server.example.com/token";,
   "token_endpoint_auth_methods_supported": ["client_secret_basic", 
"private_key_jwt"],
   "registration_endpoint": "https://server.example.com/register";,
   "response_types_supported":  ["code", "token"],
   "service_documentation": 
"http://server.example.com/service_documentation.html";,

Is there a reason that you would like the syntax for any of these or the other 
generally applicable OAuth 2.0 metadata values to be different?  I don’t see 
any good reason for unnecessary differences to be introduced.

-- Mike

From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com]
Sent: Wednesday, February 24, 2016 12:45 PM
To: Anthony Nadalin mailto:tony...@microsoft.com>>
Cc: Mike Jones 
mailto:michael.jo...@microsoft.com>>; 
mailto:oauth@ietf.org>> mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Mike

Publishing on dev pages does not work for software (esp open source) that is 
deployed both in enterprises and on PaaS cloud providers.

The current draft is may codify current OIDC practice and be appropriate for 
oidc but it is not ready for generic oauth. There is no generic oauth 
experience at this time.

Phil

On Feb 24, 2016, at 10:25, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
Sure there is, it is as you have now made it far easier and the security 
considerations does not even address this

From: Mike Jones
Sent: Wednesday, February 24, 2016 10:22 AM
To: Anthony Nadalin mailto:tony...@microsoft.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Phil Hunt (IDM)]

Yup. And because there many relations the client mist be able to discover it. 
The client does not know if the res server is legit. 

The userinfo is always fix and so u dont need discovery. 

Phil

> On Feb 24, 2016, at 14:05, Mike Jones  wrote:
> 
> In OpenID Connect, there’s a resource server called the UserInfo Endpoint 
> that returns claims about the authenticated user as a JSON data structure.  
> Its location is published in OpenID Connect discovery metadata as the 
> “userinfo_endpoint” metadata value, which is defined at 
> http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.
>  
> We didn’t include the UserInfo Endpoint in the generic OAuth discovery spec 
> since in OAuth, there are lots of possible relationships between 
> authorization servers  and resource servers and they needn’t be one-to-one, 
> as is being actively discussed by the working group.  For instance, see 
> George Fletcher’s recent contribution.
>  
> Thanks for the good discussion, Phil.
>  
> -- Mike
>  
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
> Sent: Wednesday, February 24, 2016 1:25 PM
> To: Mike Jones
> Cc: 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> Where is the profile endpoint (oidc's resource server) published? (For the 
> non OIDC people on the list). 
> 
> Phil
> 
> On Feb 24, 2016, at 13:09, Mike Jones  wrote:
> 
> To the extent that generic OAuth 2.0 needs to publish some of the same 
> information as OpenID Connect – which is built on generic OAuth 2.0 – it 
> makes sense to publish that information using exactly the same syntax, since 
> that syntax is already in widespread use.  That what this draft accomplishes.
>  
> There’s nothing Connect-specific about using metadata response values like:
>  
>"authorization_endpoint": "https://server.example.com/authorize";,
>"token_endpoint": "https://server.example.com/token";,
>"token_endpoint_auth_methods_supported": ["client_secret_basic", 
> "private_key_jwt"],
>"registration_endpoint": "https://server.example.com/register";,
>"response_types_supported":  ["code", "token"],
>"service_documentation": 
> "http://server.example.com/service_documentation.html";,
>  
> Is there a reason that you would like the syntax for any of these or the 
> other generally applicable OAuth 2.0 metadata values to be different?  I 
> don’t see any good reason for unnecessary differences to be introduced.
>  
> -- Mike
>  
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
> Sent: Wednesday, February 24, 2016 12:45 PM
> To: Anthony Nadalin 
> Cc: Mike Jones ;  
> 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> Mike
>  
> Publishing on dev pages does not work for software (esp open source) that is 
> deployed both in enterprises and on PaaS cloud providers. 
>  
> The current draft is may codify current OIDC practice and be appropriate for 
> oidc but it is not ready for generic oauth. There is no generic oauth 
> experience at this time. 
> 
> Phil
> 
> On Feb 24, 2016, at 10:25, Anthony Nadalin  wrote:
> 
> Sure there is, it is as you have now made it far easier and the security 
> considerations does not even address this
>  
> From: Mike Jones 
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> As we’d discussed in person, there’s no effective security difference between 
> discovery information being published in an ad-hoc fashion on developer pages 
> and it being published in a standard format.  “Security by obscurity” adds no 
> real security at all.
>  
>   -- Mike
>  
> From: Anthony Nadalin 
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones ; Phil Hunt (IDM) 
> ; Nat Sakimura 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> > The point of the WGLC is to finish standardizing the core discovery 
> > functionality that’s already widely deployed.
>  
> That may be widely deployed for OIDC but not widely deployed for OAuth. There 
> are some authentication mechanism discovery for endpoint that really should 
> not be in an OAuth standard since it’s really not dealt with. Now that all 
> this information is available it makes poking around the endpoint more 
> focused for people that want to disrupt your endpoints, that is 

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Mike Jones]

In OpenID Connect, there’s a resource server called the UserInfo Endpoint that 
returns claims about the authenticated user as a JSON data structure.  Its 
location is published in OpenID Connect discovery metadata as the 
“userinfo_endpoint” metadata value, which is defined at 
http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.

We didn’t include the UserInfo Endpoint in the generic OAuth discovery spec 
since in OAuth, there are lots of possible relationships between authorization 
servers and resource servers and they needn’t be one-to-one, as is being 
actively discussed by the working group.  For instance, see George Fletcher’s 
recent contribution.

Thanks for the good discussion, Phil.

-- Mike

From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com]
Sent: Wednesday, February 24, 2016 1:25 PM
To: Mike Jones
Cc: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Where is the profile endpoint (oidc's resource server) published? (For the non 
OIDC people on the list).

Phil

On Feb 24, 2016, at 13:09, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
To the extent that generic OAuth 2.0 needs to publish some of the same 
information as OpenID Connect – which is built on generic OAuth 2.0 – it makes 
sense to publish that information using exactly the same syntax, since that 
syntax is already in widespread use.  That what this draft accomplishes.

There’s nothing Connect-specific about using metadata response values like:

   "authorization_endpoint": "https://server.example.com/authorize";,
   "token_endpoint": "https://server.example.com/token";,
   "token_endpoint_auth_methods_supported": ["client_secret_basic", 
"private_key_jwt"],
   "registration_endpoint": "https://server.example.com/register";,
   "response_types_supported":  ["code", "token"],
   "service_documentation": 
"http://server.example.com/service_documentation.html";,

Is there a reason that you would like the syntax for any of these or the other 
generally applicable OAuth 2.0 metadata values to be different?  I don’t see 
any good reason for unnecessary differences to be introduced.

-- Mike

From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com]
Sent: Wednesday, February 24, 2016 12:45 PM
To: Anthony Nadalin mailto:tony...@microsoft.com>>
Cc: Mike Jones 
mailto:michael.jo...@microsoft.com>>; 
mailto:oauth@ietf.org>> mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Mike

Publishing on dev pages does not work for software (esp open source) that is 
deployed both in enterprises and on PaaS cloud providers.

The current draft is may codify current OIDC practice and be appropriate for 
oidc but it is not ready for generic oauth. There is no generic oauth 
experience at this time.

Phil

On Feb 24, 2016, at 10:25, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
Sure there is, it is as you have now made it far easier and the security 
considerations does not even address this

From: Mike Jones
Sent: Wednesday, February 24, 2016 10:22 AM
To: Anthony Nadalin mailto:tony...@microsoft.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location

As we’d discussed in person, there’s no effective security difference between 
discovery information being published in an ad-hoc fashion on developer pages 
and it being published in a standard format.  “Security by obscurity” adds no 
real security at all.

  -- Mike

From: Anthony Nadalin
Sent: Wednesday, February 24, 2016 10:01 AM
To: Mike Jones 
mailto:michael.jo...@microsoft.com>>; Phil Hunt 
(IDM) mailto:phil.h...@oracle.com>>; Nat Sakimura 
mailto:sakim...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location

> The point of the WGLC is to finish standardizing the core discovery 
> functionality that’s already widely deployed.

That may be widely deployed for OIDC but not widely deployed for OAuth. There 
are some authentication mechanism discovery for endpoint that really should not 
be in an OAuth standard since it’s really not dealt with. Now that all this 
information is available it makes poking around the endpoint more focused for 
people that want to disrupt your endpoints, that is really not addressed in the 
security considerations section at all

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 24, 2016 9:54 AM
To: Phil Hunt (IDM) mailto:phil.h...@oracle.com>>; Nat 
Sakimura mailto:sakim...@gmail.com>>
Cc: mailto:oauth@ietf.org>&g

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Phil Hunt (IDM)]

Where is the profile endpoint (oidc's resource server) published? (For the non 
OIDC people on the list). 

Phil

> On Feb 24, 2016, at 13:09, Mike Jones  wrote:
> 
> To the extent that generic OAuth 2.0 needs to publish some of the same 
> information as OpenID Connect – which is built on generic OAuth 2.0 – it 
> makes sense to publish that information using exactly the same syntax, since 
> that syntax is already in widespread use.  That what this draft accomplishes.
>  
> There’s nothing Connect-specific about using metadata response values like:
>  
>"authorization_endpoint": "https://server.example.com/authorize";,
>"token_endpoint": "https://server.example.com/token";,
>"token_endpoint_auth_methods_supported": ["client_secret_basic", 
> "private_key_jwt"],
>"registration_endpoint": "https://server.example.com/register";,
>"response_types_supported":  ["code", "token"],
>"service_documentation": 
> "http://server.example.com/service_documentation.html";,
>  
> Is there a reason that you would like the syntax for any of these or the 
> other generally applicable OAuth 2.0 metadata values to be different?  I 
> don’t see any good reason for unnecessary differences to be introduced.
>  
>                 -- Mike
>  
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com] 
> Sent: Wednesday, February 24, 2016 12:45 PM
> To: Anthony Nadalin 
> Cc: Mike Jones ;  
> 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> Mike
>  
> Publishing on dev pages does not work for software (esp open source) that is 
> deployed both in enterprises and on PaaS cloud providers. 
>  
> The current draft is may codify current OIDC practice and be appropriate for 
> oidc but it is not ready for generic oauth. There is no generic oauth 
> experience at this time. 
> 
> Phil
> 
> On Feb 24, 2016, at 10:25, Anthony Nadalin  wrote:
> 
> Sure there is, it is as you have now made it far easier and the security 
> considerations does not even address this
>  
> From: Mike Jones 
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> As we’d discussed in person, there’s no effective security difference between 
> discovery information being published in an ad-hoc fashion on developer pages 
> and it being published in a standard format.  “Security by obscurity” adds no 
> real security at all.
>  
>   -- Mike
>  
> From: Anthony Nadalin 
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones ; Phil Hunt (IDM) 
> ; Nat Sakimura 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> > The point of the WGLC is to finish standardizing the core discovery 
> > functionality that’s already widely deployed.
>  
> That may be widely deployed for OIDC but not widely deployed for OAuth. There 
> are some authentication mechanism discovery for endpoint that really should 
> not be in an OAuth standard since it’s really not dealt with. Now that all 
> this information is available it makes poking around the endpoint more 
> focused for people that want to disrupt your endpoints, that is really not 
> addressed in the security considerations section at all
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Phil Hunt (IDM) ; Nat Sakimura 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> The point of the WGLC is to finish standardizing the core discovery 
> functionality that’s already widely deployed.
>  
> None of Nat or John or I are suggesting that additional related functionality 
> won’t be created.  I’m sure it will be.  Some applications will use WebFinger 
> to locate the discovery metadata.  Some will possibly use link headers.  Some 
> will possibly use application-specific .well-known values.  I’m sure there’s 
> other things I haven’t even thought about.  All of these depend upon having a 
> discovery metadata document format and none of them change it – other than 
> possibly to register additional discovery metadata values.
>  
> So by all means, the working group should continue discussing inventing 
> possible new related mechanisms that make sense in some contexts.  At the 
> same time, we can finish standardizing the already widely deployed core 
> functionality that all of these mechanisms will need.
>  
>

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Mike Jones]

To the extent that generic OAuth 2.0 needs to publish some of the same 
information as OpenID Connect – which is built on generic OAuth 2.0 – it makes 
sense to publish that information using exactly the same syntax, since that 
syntax is already in widespread use.  That what this draft accomplishes.

There’s nothing Connect-specific about using metadata response values like:

   "authorization_endpoint": "https://server.example.com/authorize";,
   "token_endpoint": "https://server.example.com/token";,
   "token_endpoint_auth_methods_supported": ["client_secret_basic", 
"private_key_jwt"],
   "registration_endpoint": "https://server.example.com/register";,
   "response_types_supported":  ["code", "token"],
   "service_documentation": 
"http://server.example.com/service_documentation.html";,

Is there a reason that you would like the syntax for any of these or the other 
generally applicable OAuth 2.0 metadata values to be different?  I don’t see 
any good reason for unnecessary differences to be introduced.

-- Mike

From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com]
Sent: Wednesday, February 24, 2016 12:45 PM
To: Anthony Nadalin 
Cc: Mike Jones ;  
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Mike

Publishing on dev pages does not work for software (esp open source) that is 
deployed both in enterprises and on PaaS cloud providers.

The current draft is may codify current OIDC practice and be appropriate for 
oidc but it is not ready for generic oauth. There is no generic oauth 
experience at this time.

Phil

On Feb 24, 2016, at 10:25, Anthony Nadalin 
mailto:tony...@microsoft.com>> wrote:
Sure there is, it is as you have now made it far easier and the security 
considerations does not even address this

From: Mike Jones
Sent: Wednesday, February 24, 2016 10:22 AM
To: Anthony Nadalin mailto:tony...@microsoft.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location

As we’d discussed in person, there’s no effective security difference between 
discovery information being published in an ad-hoc fashion on developer pages 
and it being published in a standard format.  “Security by obscurity” adds no 
real security at all.

  -- Mike

From: Anthony Nadalin
Sent: Wednesday, February 24, 2016 10:01 AM
To: Mike Jones 
mailto:michael.jo...@microsoft.com>>; Phil Hunt 
(IDM) mailto:phil.h...@oracle.com>>; Nat Sakimura 
mailto:sakim...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location

> The point of the WGLC is to finish standardizing the core discovery 
> functionality that’s already widely deployed.

That may be widely deployed for OIDC but not widely deployed for OAuth. There 
are some authentication mechanism discovery for endpoint that really should not 
be in an OAuth standard since it’s really not dealt with. Now that all this 
information is available it makes poking around the endpoint more focused for 
people that want to disrupt your endpoints, that is really not addressed in the 
security considerations section at all

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 24, 2016 9:54 AM
To: Phil Hunt (IDM) mailto:phil.h...@oracle.com>>; Nat 
Sakimura mailto:sakim...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

The point of the WGLC is to finish standardizing the core discovery 
functionality that’s already widely deployed.

None of Nat or John or I are suggesting that additional related functionality 
won’t be created.  I’m sure it will be.  Some applications will use WebFinger 
to locate the discovery metadata.  Some will possibly use link headers.  Some 
will possibly use application-specific .well-known values.  I’m sure there’s 
other things I haven’t even thought about.  All of these depend upon having a 
discovery metadata document format and none of them change it – other than 
possibly to register additional discovery metadata values.

So by all means, the working group should continue discussing inventing 
possible new related mechanisms that make sense in some contexts.  At the same 
time, we can finish standardizing the already widely deployed core 
functionality that all of these mechanisms will need.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Wednesday, February 24, 2016 8:39 AM
To: Nat Sakimura mailto:sakim...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subj

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Phil Hunt (IDM)]

Mike

Publishing on dev pages does not work for software (esp open source) that is 
deployed both in enterprises and on PaaS cloud providers. 

The current draft is may codify current OIDC practice and be appropriate for 
oidc but it is not ready for generic oauth. There is no generic oauth 
experience at this time. 

Phil

> On Feb 24, 2016, at 10:25, Anthony Nadalin  wrote:
> 
> Sure there is, it is as you have now made it far easier and the security 
> considerations does not even address this
>  
> From: Mike Jones 
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> As we’d discussed in person, there’s no effective security difference between 
> discovery information being published in an ad-hoc fashion on developer pages 
> and it being published in a standard format.  “Security by obscurity” adds no 
> real security at all.
>  
>   -- Mike
>  
> From: Anthony Nadalin 
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones ; Phil Hunt (IDM) 
> ; Nat Sakimura 
> Cc:  
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> > The point of the WGLC is to finish standardizing the core discovery 
> > functionality that’s already widely deployed.
>  
> That may be widely deployed for OIDC but not widely deployed for OAuth. There 
> are some authentication mechanism discovery for endpoint that really should 
> not be in an OAuth standard since it’s really not dealt with. Now that all 
> this information is available it makes poking around the endpoint more 
> focused for people that want to disrupt your endpoints, that is really not 
> addressed in the security considerations section at all
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Phil Hunt (IDM) ; Nat Sakimura 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> The point of the WGLC is to finish standardizing the core discovery 
> functionality that’s already widely deployed.
>  
> None of Nat or John or I are suggesting that additional related functionality 
> won’t be created.  I’m sure it will be.  Some applications will use WebFinger 
> to locate the discovery metadata.  Some will possibly use link headers.  Some 
> will possibly use application-specific .well-known values.  I’m sure there’s 
> other things I haven’t even thought about.  All of these depend upon having a 
> discovery metadata document format and none of them change it – other than 
> possibly to register additional discovery metadata values.
>  
> So by all means, the working group should continue discussing inventing 
> possible new related mechanisms that make sense in some contexts.  At the 
> same time, we can finish standardizing the already widely deployed core 
> functionality that all of these mechanisms will need.
>  
>   -- Mike
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
> Sent: Wednesday, February 24, 2016 8:39 AM
> To: Nat Sakimura 
> Cc:  
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>  
> I am suggesting that part of the discovery solution has to be the client 
> indicating what resource endpoint it wants the oauth configuration data for. 
>  
> So if res.example.evil.com is not a valid resource endpoint for 
> as.example.com the authz discovery should fail in some way (eg return 
> nothing). 
>  
> There may be better ways to do this. Eg combine discovery. Or change the 
> order of discovery. 
>  
> One of OAuth's strength's and weaknesses is that the target of authorization 
> (the resource) is never specified. It is often bound up in the client 
> registration and an often implied 1:1 relationship between resource and as. 
> Given that in discovery phase registration has not yet occurred it seems 
> important that the client know it has a valid combination of endpoints etc. 
>  
> This is why I was disappointed about wglc on discovery. We had a starting 
> point for group adoption but we haven't really defined the full requirements 
> IMO. 
>  
> I am on vacation or I would put some thought into some draft changes or a new 
> draft. I apologize I can't do it now. 
> 
> Phil
> 
> On Feb 24, 2016, at 08:12, Nat Sakimura  wrote:
> 
> Hi Phil, 
>  
> Are you suggesting that the AS metadata should include the RS URIs? 
> Currently, it does not, but it can be done, I guess. 
>  
> The way oauth-meta works is that 
>  
> 1. RS tells the client where the AS is. 
> 2. AS tells the client which RS end

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[George Fletcher]

I'm concerned that forcing the AS to know about all RS's endpoints that 
will accept it's tokens creates a very brittle deployment architecture. 
What if a RS moves to a new endpoint? All clients would be required to 
get new tokens (if I understand correctly). And the RS move would have 
to coordinate with the AS to make sure all the timing is perfect in the 
switch over of endpoints.


I suspect a common deployment architecture today is that each RS 
requires one or more scopes to access it's resources. The client then 
asks the user to authorize a token with a requested list of scopes. The 
client can then send the token to the appropriate RS endpoint. The RS 
will not authorize access unless the token has the required scopes.


If the concern is that the client may accidentally send the token to a 
"bad" RS which will then replay the token, then I'd rather use a PoP 
mechanism because the point is that you want to ensure the correct 
client is presenting the token. Trying to ensure the client doesn't send 
the token to the wrong endpoint seems fraught with problems.


Thanks,
George

On 2/24/16 9:59 AM, Phil Hunt wrote:

Nat,

I’m not sure that having the resource server tell the client where its 
authorization server is secure by itself. The relationship between the 
Authorization Server and the Resource server need to be bound together 
in one of the discovery endpoints (the resource and/or the oauth 
service discovery).


If a client discovers a fake resource server that is proxying for a 
real resource server the current discovery spec will not lead the 
client to understand it has the wrong resource server. Rather the fake 
resource service will just have a fake discovery service. The hacker 
can now intercept resource payload as well as tokens because they were 
able to convince the client to use the legit authorization service but 
use the token against the hackers proxy.


The OAuth Discovery service needs to confirm to the client that the 
server is able to issue tokens for a stated resource endpoint.


This not only works in normal OAuth but should add security even to 
UMA situations.


Phil

@independentid
www.independentid.com 
phil.h...@oracle.com 





On Feb 24, 2016, at 3:54 AM, Nat Sakimura > wrote:



Hi Thomas,

inline:

2016年2月22日(月) 18:44 Thomas Broyer >:


Couldn't the document only describe the metadata?
I quite like the idea of draft-sakimura-oauth-meta if you really
want to do discovery, and leave it open to implementers / to
other specs to define a .well-known URL for "auto-configuration".
The metadata described here would then either be used as-is, at
any URL, returned as draft-sakimura-oauth-meta metadata at the
RS; or as a basis for other metadata specs (like OpenID Connect).

With draft-sakimura-oauth-meta's "duri" and the "scope" attribute
of WWW-Authenticate response header, you have everything you need
to proceed


Yup. That's one of the requirements to be RESTful, is it not?

In OAuth's case, the resource and the authorization server are 
usually tightly coupled. (Otherwise, you need another specs like UMA.)
So, the resource server should be able to tell either the location of 
the authz endpoint. In some trusted environment, the resource may as 
well return the location of the authz server configuration data. In 
these cases, you do not have to decide on what .well-known uri as you 
say. This frees up developers from configuration file location 
collisions etc. We should strive not to pollute the uri space as much 
as possible.


(well, except if there are several ASs each with different
scopes; sounds like an edge-case to me though; maybe RFC6750
should instead be updated with such a parameter such that an RS
could return several WWW-Authenticate: Bearer, each with its own
"scope" and "duri" value?)


Yeah, I guess it is an edge case. I would rather like to see these 
authz servers to develop a trust framework under which they can agree 
on a single set of common scope parameter values.


Cheers,

Nat



On Fri, Feb 19, 2016 at 10:59 PM Justin Richer mailto:jric...@mit.edu>> wrote:

The newly-trimmed OAuth Discovery document is helpful and
moving in the right direction. It does, however, still have
too many vestiges of its OpenID Connect origins. One issue in
particular still really bothers me: the use of
“/.well-known/openid-configuration” in the discovery portion.
Is this an OAuth discovery document, or an OpenID Connect
one? There is absolutely no compelling reason to tie the URL
to the OIDC discovery mechanism.

I propose that we use
“/.well-known/oauth-authorization-server” as the default
discovery location, and state that the document MAY also be
reachable from “/.well-known/openid-configurat

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Mike Jones]

We could add a statement something like this to the security considerations:

“Publishing information about the authorization server in a standard format 
makes it easier for both legitimate clients and attackers to use the 
authorization server.”

I believe that speaks to the point you’re making.

  -- Mike

From: Anthony Nadalin
Sent: Wednesday, February 24, 2016 10:26 AM
To: Mike Jones 
Cc:  
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location

Sure there is, it is as you have now made it far easier and the security 
considerations does not even address this

From: Mike Jones
Sent: Wednesday, February 24, 2016 10:22 AM
To: Anthony Nadalin mailto:tony...@microsoft.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location

As we’d discussed in person, there’s no effective security difference between 
discovery information being published in an ad-hoc fashion on developer pages 
and it being published in a standard format.  “Security by obscurity” adds no 
real security at all.

  -- Mike

From: Anthony Nadalin
Sent: Wednesday, February 24, 2016 10:01 AM
To: Mike Jones 
mailto:michael.jo...@microsoft.com>>; Phil Hunt 
(IDM) mailto:phil.h...@oracle.com>>; Nat Sakimura 
mailto:sakim...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location

> The point of the WGLC is to finish standardizing the core discovery 
> functionality that’s already widely deployed.

That may be widely deployed for OIDC but not widely deployed for OAuth. There 
are some authentication mechanism discovery for endpoint that really should not 
be in an OAuth standard since it’s really not dealt with. Now that all this 
information is available it makes poking around the endpoint more focused for 
people that want to disrupt your endpoints, that is really not addressed in the 
security considerations section at all

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 24, 2016 9:54 AM
To: Phil Hunt (IDM) mailto:phil.h...@oracle.com>>; Nat 
Sakimura mailto:sakim...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

The point of the WGLC is to finish standardizing the core discovery 
functionality that’s already widely deployed.

None of Nat or John or I are suggesting that additional related functionality 
won’t be created.  I’m sure it will be.  Some applications will use WebFinger 
to locate the discovery metadata.  Some will possibly use link headers.  Some 
will possibly use application-specific .well-known values.  I’m sure there’s 
other things I haven’t even thought about.  All of these depend upon having a 
discovery metadata document format and none of them change it – other than 
possibly to register additional discovery metadata values.

So by all means, the working group should continue discussing inventing 
possible new related mechanisms that make sense in some contexts.  At the same 
time, we can finish standardizing the already widely deployed core 
functionality that all of these mechanisms will need.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Wednesday, February 24, 2016 8:39 AM
To: Nat Sakimura mailto:sakim...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I am suggesting that part of the discovery solution has to be the client 
indicating what resource endpoint it wants the oauth configuration data for.

So if 
res.example.evil.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fres.example.evil.com&data=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Pc%2b7ilnDYgfjYoTsQWoZnpobG%2bVJp5Wu9cGpFUgz3S0%3d>
 is not a valid resource endpoint for 
as.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fas.example.com&data=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6%2bqxh%2f7VCZkswXhJMv6r%2b18dTRbg2Is12WB%2fdZm3cJ4%3d>
 the authz discovery should fail in some way (eg return nothing).

There may be better ways to do this. Eg combine discovery. Or change the order 
of discovery.

One of OAuth's strength's and weaknesses is that the target of authorization 
(the resource) is never specified. It is often bound up in the client 
registration and an often implied 1:1 relationship between resource and as. 
Given that in discovery phase registration has not yet occurred it seems 
important that the client know it has a va

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Anthony Nadalin]

Sure there is, it is as you have now made it far easier and the security 
considerations does not even address this

From: Mike Jones
Sent: Wednesday, February 24, 2016 10:22 AM
To: Anthony Nadalin 
Cc:  
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location

As we’d discussed in person, there’s no effective security difference between 
discovery information being published in an ad-hoc fashion on developer pages 
and it being published in a standard format.  “Security by obscurity” adds no 
real security at all.

  -- Mike

From: Anthony Nadalin
Sent: Wednesday, February 24, 2016 10:01 AM
To: Mike Jones 
mailto:michael.jo...@microsoft.com>>; Phil Hunt 
(IDM) mailto:phil.h...@oracle.com>>; Nat Sakimura 
mailto:sakim...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location

> The point of the WGLC is to finish standardizing the core discovery 
> functionality that’s already widely deployed.

That may be widely deployed for OIDC but not widely deployed for OAuth. There 
are some authentication mechanism discovery for endpoint that really should not 
be in an OAuth standard since it’s really not dealt with. Now that all this 
information is available it makes poking around the endpoint more focused for 
people that want to disrupt your endpoints, that is really not addressed in the 
security considerations section at all

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 24, 2016 9:54 AM
To: Phil Hunt (IDM) mailto:phil.h...@oracle.com>>; Nat 
Sakimura mailto:sakim...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

The point of the WGLC is to finish standardizing the core discovery 
functionality that’s already widely deployed.

None of Nat or John or I are suggesting that additional related functionality 
won’t be created.  I’m sure it will be.  Some applications will use WebFinger 
to locate the discovery metadata.  Some will possibly use link headers.  Some 
will possibly use application-specific .well-known values.  I’m sure there’s 
other things I haven’t even thought about.  All of these depend upon having a 
discovery metadata document format and none of them change it – other than 
possibly to register additional discovery metadata values.

So by all means, the working group should continue discussing inventing 
possible new related mechanisms that make sense in some contexts.  At the same 
time, we can finish standardizing the already widely deployed core 
functionality that all of these mechanisms will need.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Wednesday, February 24, 2016 8:39 AM
To: Nat Sakimura mailto:sakim...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I am suggesting that part of the discovery solution has to be the client 
indicating what resource endpoint it wants the oauth configuration data for.

So if 
res.example.evil.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fres.example.evil.com&data=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Pc%2b7ilnDYgfjYoTsQWoZnpobG%2bVJp5Wu9cGpFUgz3S0%3d>
 is not a valid resource endpoint for 
as.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fas.example.com&data=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6%2bqxh%2f7VCZkswXhJMv6r%2b18dTRbg2Is12WB%2fdZm3cJ4%3d>
 the authz discovery should fail in some way (eg return nothing).

There may be better ways to do this. Eg combine discovery. Or change the order 
of discovery.

One of OAuth's strength's and weaknesses is that the target of authorization 
(the resource) is never specified. It is often bound up in the client 
registration and an often implied 1:1 relationship between resource and as. 
Given that in discovery phase registration has not yet occurred it seems 
important that the client know it has a valid combination of endpoints etc.

This is why I was disappointed about wglc on discovery. We had a starting point 
for group adoption but we haven't really defined the full requirements IMO.

I am on vacation or I would put some thought into some draft changes or a new 
draft. I apologize I can't do it now.

Phil

On Feb 24, 2016, at 08:12, Nat Sakimura 
mailto:sakim...@gmail.com>> wrote:
Hi Phil,

Are you suggesting that the AS metadata should include the RS URIs? Currently, 
it does not, but it can be done, I guess.

The way oauth-meta works is that

1. RS tells the client 

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Mike Jones]

As we’d discussed in person, there’s no effective security difference between 
discovery information being published in an ad-hoc fashion on developer pages 
and it being published in a standard format.  “Security by obscurity” adds no 
real security at all.

  -- Mike

From: Anthony Nadalin
Sent: Wednesday, February 24, 2016 10:01 AM
To: Mike Jones ; Phil Hunt (IDM) 
; Nat Sakimura 
Cc:  
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location

> The point of the WGLC is to finish standardizing the core discovery 
> functionality that’s already widely deployed.

That may be widely deployed for OIDC but not widely deployed for OAuth. There 
are some authentication mechanism discovery for endpoint that really should not 
be in an OAuth standard since it’s really not dealt with. Now that all this 
information is available it makes poking around the endpoint more focused for 
people that want to disrupt your endpoints, that is really not addressed in the 
security considerations section at all

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 24, 2016 9:54 AM
To: Phil Hunt (IDM) mailto:phil.h...@oracle.com>>; Nat 
Sakimura mailto:sakim...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

The point of the WGLC is to finish standardizing the core discovery 
functionality that’s already widely deployed.

None of Nat or John or I are suggesting that additional related functionality 
won’t be created.  I’m sure it will be.  Some applications will use WebFinger 
to locate the discovery metadata.  Some will possibly use link headers.  Some 
will possibly use application-specific .well-known values.  I’m sure there’s 
other things I haven’t even thought about.  All of these depend upon having a 
discovery metadata document format and none of them change it – other than 
possibly to register additional discovery metadata values.

So by all means, the working group should continue discussing inventing 
possible new related mechanisms that make sense in some contexts.  At the same 
time, we can finish standardizing the already widely deployed core 
functionality that all of these mechanisms will need.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Wednesday, February 24, 2016 8:39 AM
To: Nat Sakimura mailto:sakim...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I am suggesting that part of the discovery solution has to be the client 
indicating what resource endpoint it wants the oauth configuration data for.

So if 
res.example.evil.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fres.example.evil.com&data=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Pc%2b7ilnDYgfjYoTsQWoZnpobG%2bVJp5Wu9cGpFUgz3S0%3d>
 is not a valid resource endpoint for 
as.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fas.example.com&data=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6%2bqxh%2f7VCZkswXhJMv6r%2b18dTRbg2Is12WB%2fdZm3cJ4%3d>
 the authz discovery should fail in some way (eg return nothing).

There may be better ways to do this. Eg combine discovery. Or change the order 
of discovery.

One of OAuth's strength's and weaknesses is that the target of authorization 
(the resource) is never specified. It is often bound up in the client 
registration and an often implied 1:1 relationship between resource and as. 
Given that in discovery phase registration has not yet occurred it seems 
important that the client know it has a valid combination of endpoints etc.

This is why I was disappointed about wglc on discovery. We had a starting point 
for group adoption but we haven't really defined the full requirements IMO.

I am on vacation or I would put some thought into some draft changes or a new 
draft. I apologize I can't do it now.

Phil

On Feb 24, 2016, at 08:12, Nat Sakimura 
mailto:sakim...@gmail.com>> wrote:
Hi Phil,

Are you suggesting that the AS metadata should include the RS URIs? Currently, 
it does not, but it can be done, I guess.

The way oauth-meta works is that

1. RS tells the client where the AS is.
2. AS tells the client which RS endpoints the token can be used.

Even if there is a bad AS with a valid certs that proxies to the good RS, the 
client will not send the token there as the authz server will say that is not 
the place the client may want to send the token to.

Nat

2016年2月24日(水) 23:59 Phil Hunt 
mailto:phil.h...@oracle.com>>:
Nat,

I’m not sure that having the resource server tell the client whe

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Anthony Nadalin]

> The point of the WGLC is to finish standardizing the core discovery 
> functionality that’s already widely deployed.
That may be widely deployed for OIDC but not widely deployed for OAuth. There 
are some authentication mechanism discovery for endpoint that really should not 
be in an OAuth standard since it’s really not dealt with. Now that all this 
information is available it makes poking around the endpoint more focused for 
people that want to disrupt your endpoints, that is really not addressed in the 
security considerations section at all

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 24, 2016 9:54 AM
To: Phil Hunt (IDM) ; Nat Sakimura 
Cc:  
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

The point of the WGLC is to finish standardizing the core discovery 
functionality that’s already widely deployed.

None of Nat or John or I are suggesting that additional related functionality 
won’t be created.  I’m sure it will be.  Some applications will use WebFinger 
to locate the discovery metadata.  Some will possibly use link headers.  Some 
will possibly use application-specific .well-known values.  I’m sure there’s 
other things I haven’t even thought about.  All of these depend upon having a 
discovery metadata document format and none of them change it – other than 
possibly to register additional discovery metadata values.

So by all means, the working group should continue discussing inventing 
possible new related mechanisms that make sense in some contexts.  At the same 
time, we can finish standardizing the already widely deployed core 
functionality that all of these mechanisms will need.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Wednesday, February 24, 2016 8:39 AM
To: Nat Sakimura mailto:sakim...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I am suggesting that part of the discovery solution has to be the client 
indicating what resource endpoint it wants the oauth configuration data for.

So if 
res.example.evil.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fres.example.evil.com&data=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Pc%2b7ilnDYgfjYoTsQWoZnpobG%2bVJp5Wu9cGpFUgz3S0%3d>
 is not a valid resource endpoint for 
as.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fas.example.com&data=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6%2bqxh%2f7VCZkswXhJMv6r%2b18dTRbg2Is12WB%2fdZm3cJ4%3d>
 the authz discovery should fail in some way (eg return nothing).

There may be better ways to do this. Eg combine discovery. Or change the order 
of discovery.

One of OAuth's strength's and weaknesses is that the target of authorization 
(the resource) is never specified. It is often bound up in the client 
registration and an often implied 1:1 relationship between resource and as. 
Given that in discovery phase registration has not yet occurred it seems 
important that the client know it has a valid combination of endpoints etc.

This is why I was disappointed about wglc on discovery. We had a starting point 
for group adoption but we haven't really defined the full requirements IMO.

I am on vacation or I would put some thought into some draft changes or a new 
draft. I apologize I can't do it now.

Phil

On Feb 24, 2016, at 08:12, Nat Sakimura 
mailto:sakim...@gmail.com>> wrote:
Hi Phil,

Are you suggesting that the AS metadata should include the RS URIs? Currently, 
it does not, but it can be done, I guess.

The way oauth-meta works is that

1. RS tells the client where the AS is.
2. AS tells the client which RS endpoints the token can be used.

Even if there is a bad AS with a valid certs that proxies to the good RS, the 
client will not send the token there as the authz server will say that is not 
the place the client may want to send the token to.

Nat

2016年2月24日(水) 23:59 Phil Hunt 
mailto:phil.h...@oracle.com>>:
Nat,

I’m not sure that having the resource server tell the client where its 
authorization server is secure by itself. The relationship between the 
Authorization Server and the Resource server need to be bound together in one 
of the discovery endpoints (the resource and/or the oauth service discovery).

If a client discovers a fake resource server that is proxying for a real 
resource server the current discovery spec will not lead the client to 
understand it has the wrong resource server. Rather the fake resource service 
will just have a fake discovery service. The hacker can now intercept resource 
payload as well as tokens because they were able to convince the client to use 
the

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Mike Jones]

The point of the WGLC is to finish standardizing the core discovery 
functionality that’s already widely deployed.

None of Nat or John or I are suggesting that additional related functionality 
won’t be created.  I’m sure it will be.  Some applications will use WebFinger 
to locate the discovery metadata.  Some will possibly use link headers.  Some 
will possibly use application-specific .well-known values.  I’m sure there’s 
other things I haven’t even thought about.  All of these depend upon having a 
discovery metadata document format and none of them change it – other than 
possibly to register additional discovery metadata values.

So by all means, the working group should continue discussing inventing 
possible new related mechanisms that make sense in some contexts.  At the same 
time, we can finish standardizing the already widely deployed core 
functionality that all of these mechanisms will need.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Wednesday, February 24, 2016 8:39 AM
To: Nat Sakimura 
Cc:  
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I am suggesting that part of the discovery solution has to be the client 
indicating what resource endpoint it wants the oauth configuration data for.

So if res.example.evil.com<http://res.example.evil.com> is not a valid resource 
endpoint for as.example.com<http://as.example.com> the authz discovery should 
fail in some way (eg return nothing).

There may be better ways to do this. Eg combine discovery. Or change the order 
of discovery.

One of OAuth's strength's and weaknesses is that the target of authorization 
(the resource) is never specified. It is often bound up in the client 
registration and an often implied 1:1 relationship between resource and as. 
Given that in discovery phase registration has not yet occurred it seems 
important that the client know it has a valid combination of endpoints etc.

This is why I was disappointed about wglc on discovery. We had a starting point 
for group adoption but we haven't really defined the full requirements IMO.

I am on vacation or I would put some thought into some draft changes or a new 
draft. I apologize I can't do it now.

Phil

On Feb 24, 2016, at 08:12, Nat Sakimura 
mailto:sakim...@gmail.com>> wrote:
Hi Phil,

Are you suggesting that the AS metadata should include the RS URIs? Currently, 
it does not, but it can be done, I guess.

The way oauth-meta works is that

1. RS tells the client where the AS is.
2. AS tells the client which RS endpoints the token can be used.

Even if there is a bad AS with a valid certs that proxies to the good RS, the 
client will not send the token there as the authz server will say that is not 
the place the client may want to send the token to.

Nat

2016年2月24日(水) 23:59 Phil Hunt 
mailto:phil.h...@oracle.com>>:
Nat,

I’m not sure that having the resource server tell the client where its 
authorization server is secure by itself. The relationship between the 
Authorization Server and the Resource server need to be bound together in one 
of the discovery endpoints (the resource and/or the oauth service discovery).

If a client discovers a fake resource server that is proxying for a real 
resource server the current discovery spec will not lead the client to 
understand it has the wrong resource server. Rather the fake resource service 
will just have a fake discovery service. The hacker can now intercept resource 
payload as well as tokens because they were able to convince the client to use 
the legit authorization service but use the token against the hackers proxy.

The OAuth Discovery service needs to confirm to the client that the server is 
able to issue tokens for a stated resource endpoint.

This not only works in normal OAuth but should add security even to UMA 
situations.

Phil

@independentid
www.independentid.com<http://www.independentid.com>
phil.h...@oracle.com<mailto:phil.h...@oracle.com>




On Feb 24, 2016, at 3:54 AM, Nat Sakimura 
mailto:sakim...@gmail.com>> wrote:


Hi Thomas,

inline:

2016年2月22日(月) 18:44 Thomas Broyer 
mailto:t.bro...@gmail.com>>:
Couldn't the document only describe the metadata?
I quite like the idea of draft-sakimura-oauth-meta if you really want to do 
discovery, and leave it open to implementers / to other specs to define a 
.well-known URL for "auto-configuration".
The metadata described here would then either be used as-is, at any URL, 
returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for 
other metadata specs (like OpenID Connect).
With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of 
WWW-Authenticate response header, you have everything you need to proceed

Yup. That's one of the requirements to be RESTful, is it not?

In OAuth's case, the resource and

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Phil Hunt (IDM)]

I am suggesting that part of the discovery solution has to be the client 
indicating what resource endpoint it wants the oauth configuration data for. 

So if res.example.evil.com is not a valid resource endpoint for as.example.com 
the authz discovery should fail in some way (eg return nothing). 

There may be better ways to do this. Eg combine discovery. Or change the order 
of discovery. 

One of OAuth's strength's and weaknesses is that the target of authorization 
(the resource) is never specified. It is often bound up in the client 
registration and an often implied 1:1 relationship between resource and as. 
Given that in discovery phase registration has not yet occurred it seems 
important that the client know it has a valid combination of endpoints etc. 

This is why I was disappointed about wglc on discovery. We had a starting point 
for group adoption but we haven't really defined the full requirements IMO. 

I am on vacation or I would put some thought into some draft changes or a new 
draft. I apologize I can't do it now. 

Phil

> On Feb 24, 2016, at 08:12, Nat Sakimura  wrote:
> 
> Hi Phil, 
> 
> Are you suggesting that the AS metadata should include the RS URIs? 
> Currently, it does not, but it can be done, I guess. 
> 
> The way oauth-meta works is that 
> 
> 1. RS tells the client where the AS is. 
> 2. AS tells the client which RS endpoints the token can be used. 
> 
> Even if there is a bad AS with a valid certs that proxies to the good RS, the 
> client will not send the token there as the authz server will say that is not 
> the place the client may want to send the token to. 
> 
> Nat
> 
> 2016年2月24日(水) 23:59 Phil Hunt :
>> Nat,
>> 
>> I’m not sure that having the resource server tell the client where its 
>> authorization server is secure by itself. The relationship between the 
>> Authorization Server and the Resource server need to be bound together in 
>> one of the discovery endpoints (the resource and/or the oauth service 
>> discovery).
>> 
>> If a client discovers a fake resource server that is proxying for a real 
>> resource server the current discovery spec will not lead the client to 
>> understand it has the wrong resource server. Rather the fake resource 
>> service will just have a fake discovery service. The hacker can now 
>> intercept resource payload as well as tokens because they were able to 
>> convince the client to use the legit authorization service but use the token 
>> against the hackers proxy.
>> 
>> The OAuth Discovery service needs to confirm to the client that the server 
>> is able to issue tokens for a stated resource endpoint.
>> 
>> This not only works in normal OAuth but should add security even to UMA 
>> situations.
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> phil.h...@oracle.com
>> 
>> 
>> 
>> 
>> 
>>> On Feb 24, 2016, at 3:54 AM, Nat Sakimura  wrote:
>>> 
>>> 
>>> Hi Thomas, 
>>> 
>>> inline: 
>>> 
>>> 2016年2月22日(月) 18:44 Thomas Broyer :
 Couldn't the document only describe the metadata?
 I quite like the idea of draft-sakimura-oauth-meta if you really want to 
 do discovery, and leave it open to implementers / to other specs to define 
 a .well-known URL for "auto-configuration".
 The metadata described here would then either be used as-is, at any URL, 
 returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis 
 for other metadata specs (like OpenID Connect). 
 With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of 
 WWW-Authenticate response header, you have everything you need to proceed 
>>> 
>>> Yup. That's one of the requirements to be RESTful, is it not?  
>>> 
>>> In OAuth's case, the resource and the authorization server are usually 
>>> tightly coupled. (Otherwise, you need another specs like UMA.) 
>>> So, the resource server should be able to tell either the location of the 
>>> authz endpoint. In some trusted environment, the resource may as well 
>>> return the location of the authz server configuration data. In these cases, 
>>> you do not have to decide on what .well-known uri as you say. This frees up 
>>> developers from configuration file location collisions etc. We should 
>>> strive not to pollute the uri space as much as possible. 
>>>  
 (well, except if there are several ASs each with different scopes; sounds 
 like an edge-case to me though; maybe RFC6750 should instead be updated 
 with such a parameter such that an RS could return several 
 WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
>>> 
>>> Yeah, I guess it is an edge case. I would rather like to see these authz 
>>> servers to develop a trust framework under which they can agree on a single 
>>> set of common scope parameter values. 
>>> 
>>> Cheers, 
>>> 
>>> Nat
>>> 
 
 
> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer  wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in the 
> right direction.

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Nat Sakimura]

Hi Phil,

Are you suggesting that the AS metadata should include the RS URIs?
Currently, it does not, but it can be done, I guess.

The way oauth-meta works is that

1. RS tells the client where the AS is.
2. AS tells the client which RS endpoints the token can be used.

Even if there is a bad AS with a valid certs that proxies to the good RS,
the client will not send the token there as the authz server will say that
is not the place the client may want to send the token to.

Nat

2016年2月24日(水) 23:59 Phil Hunt :

> Nat,
>
> I’m not sure that having the resource server tell the client where its
> authorization server is secure by itself. The relationship between the
> Authorization Server and the Resource server need to be bound together in
> one of the discovery endpoints (the resource and/or the oauth service
> discovery).
>
> If a client discovers a fake resource server that is proxying for a real
> resource server the current discovery spec will not lead the client to
> understand it has the wrong resource server. Rather the fake resource
> service will just have a fake discovery service. The hacker can now
> intercept resource payload as well as tokens because they were able to
> convince the client to use the legit authorization service but use the
> token against the hackers proxy.
>
> The OAuth Discovery service needs to confirm to the client that the server
> is able to issue tokens for a stated resource endpoint.
>
> This not only works in normal OAuth but should add security even to UMA
> situations.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
>
>
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura  wrote:
>
>
> Hi Thomas,
>
> inline:
>
> 2016年2月22日(月) 18:44 Thomas Broyer :
>
>> Couldn't the document only describe the metadata?
>> I quite like the idea of draft-sakimura-oauth-meta if you really want to
>> do discovery, and leave it open to implementers / to other specs to define
>> a .well-known URL for "auto-configuration".
>> The metadata described here would then either be used as-is, at any URL,
>> returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for
>> other metadata specs (like OpenID Connect).
>>
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of
>> WWW-Authenticate response header, you have everything you need to proceed
>>
>>
>
> Yup. That's one of the requirements to be RESTful, is it not?
>
> In OAuth's case, the resource and the authorization server are usually
> tightly coupled. (Otherwise, you need another specs like UMA.)
> So, the resource server should be able to tell either the location of the
> authz endpoint. In some trusted environment, the resource may as well
> return the location of the authz server configuration data. In these cases,
> you do not have to decide on what .well-known uri as you say. This frees up
> developers from configuration file location collisions etc. We should
> strive not to pollute the uri space as much as possible.
>
>
>> (well, except if there are several ASs each with different scopes; sounds
>> like an edge-case to me though; maybe RFC6750 should instead be updated
>> with such a parameter such that an RS could return several
>> WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
>>
>
> Yeah, I guess it is an edge case. I would rather like to see these authz
> servers to develop a trust framework under which they can agree on a single
> set of common scope parameter values.
>
> Cheers,
>
> Nat
>
>
>>
>> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer  wrote:
>>
>>> The newly-trimmed OAuth Discovery document is helpful and moving in the
>>> right direction. It does, however, still have too many vestiges of its
>>> OpenID Connect origins. One issue in particular still really bothers me:
>>> the use of “/.well-known/openid-configuration” in the discovery portion. Is
>>> this an OAuth discovery document, or an OpenID Connect one? There is
>>> absolutely no compelling reason to tie the URL to the OIDC discovery
>>> mechanism.
>>>
>>> I propose that we use “/.well-known/oauth-authorization-server” as the
>>> default discovery location, and state that the document MAY also be
>>> reachable from “/.well-known/openid-configuration” if the server also
>>> provides OpenID Connect on the same domain. Other applications SHOULD use
>>> the same parameter names to describe OAuth endpoints and functions inside
>>> their service-specific discovery document.
>>>
>>>  — Justin
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
___
OAuth mailing list
OAuth@ietf.org

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Nat Sakimura]

Right. As there can be multiple WWW-authenticate header, it is doable that
way. Maybe that's better in this respect, though it becomes a bit different
than other metadata. Alternatively, the scope can be added as a parameter
in the auri Web  Link header.
Good things about the Link Header is that you can just configure the web
server config to return them. There is no code needed.

2016年2月25日(木) 0:01 Thomas Broyer :

> Hi Nat,
>
> On Wed, Feb 24, 2016 at 12:54 PM Nat Sakimura  wrote:
>
>>
>> 2016年2月22日(月) 18:44 Thomas Broyer :
>>
>
>>
>>> (well, except if there are several ASs each with different scopes;
>>> sounds like an edge-case to me though; maybe RFC6750 should instead be
>>> updated with such a parameter such that an RS could return several
>>> WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
>>>
>>
>> Yeah, I guess it is an edge case. I would rather like to see these authz
>> servers to develop a trust framework under which they can agree on a single
>> set of common scope parameter values.
>>
>
> Well, except that adding the "duri" and "auri" metadata links to the
> "WWW-Authenticate: Bearer" response header(s) would easily solve those
> issues (without judging here whether they're edge-case or not), and I don't
> really see any other use-case for that metadata outside the unauthorized
> use of a resource (your draft admits it's the "typical use-case").
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Thomas Broyer]

Hi Nat,

On Wed, Feb 24, 2016 at 12:54 PM Nat Sakimura  wrote:

>
> 2016年2月22日(月) 18:44 Thomas Broyer :
>
>
>> (well, except if there are several ASs each with different scopes; sounds
>> like an edge-case to me though; maybe RFC6750 should instead be updated
>> with such a parameter such that an RS could return several
>> WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
>>
>
> Yeah, I guess it is an edge case. I would rather like to see these authz
> servers to develop a trust framework under which they can agree on a single
> set of common scope parameter values.
>

Well, except that adding the "duri" and "auri" metadata links to the
"WWW-Authenticate: Bearer" response header(s) would easily solve those
issues (without judging here whether they're edge-case or not), and I don't
really see any other use-case for that metadata outside the unauthorized
use of a resource (your draft admits it's the "typical use-case").
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Phil Hunt]

Nat,

I’m not sure that having the resource server tell the client where its 
authorization server is secure by itself. The relationship between the 
Authorization Server and the Resource server need to be bound together in one 
of the discovery endpoints (the resource and/or the oauth service discovery).

If a client discovers a fake resource server that is proxying for a real 
resource server the current discovery spec will not lead the client to 
understand it has the wrong resource server. Rather the fake resource service 
will just have a fake discovery service. The hacker can now intercept resource 
payload as well as tokens because they were able to convince the client to use 
the legit authorization service but use the token against the hackers proxy.

The OAuth Discovery service needs to confirm to the client that the server is 
able to issue tokens for a stated resource endpoint.

This not only works in normal OAuth but should add security even to UMA 
situations.

Phil

@independentid
www.independentid.com phil.h...@oracle.com 






> On Feb 24, 2016, at 3:54 AM, Nat Sakimura  wrote:
> 
> 
> Hi Thomas, 
> 
> inline: 
> 
> 2016年2月22日(月) 18:44 Thomas Broyer  >:
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want to do 
> discovery, and leave it open to implementers / to other specs to define a 
> .well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any URL, 
> returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for 
> other metadata specs (like OpenID Connect). 
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of 
> WWW-Authenticate response header, you have everything you need to proceed 
> 
> Yup. That's one of the requirements to be RESTful, is it not?  
> 
> In OAuth's case, the resource and the authorization server are usually 
> tightly coupled. (Otherwise, you need another specs like UMA.) 
> So, the resource server should be able to tell either the location of the 
> authz endpoint. In some trusted environment, the resource may as well return 
> the location of the authz server configuration data. In these cases, you do 
> not have to decide on what .well-known uri as you say. This frees up 
> developers from configuration file location collisions etc. We should strive 
> not to pollute the uri space as much as possible. 
>  
> (well, except if there are several ASs each with different scopes; sounds 
> like an edge-case to me though; maybe RFC6750 should instead be updated with 
> such a parameter such that an RS could return several WWW-Authenticate: 
> Bearer, each with its own "scope" and "duri" value?)
> 
> Yeah, I guess it is an edge case. I would rather like to see these authz 
> servers to develop a trust framework under which they can agree on a single 
> set of common scope parameter values. 
> 
> Cheers, 
> 
> Nat
> 
> 
> 
> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer  > wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in the right 
> direction. It does, however, still have too many vestiges of its OpenID 
> Connect origins. One issue in particular still really bothers me: the use of 
> “/.well-known/openid-configuration” in the discovery portion. Is this an 
> OAuth discovery document, or an OpenID Connect one? There is absolutely no 
> compelling reason to tie the URL to the OIDC discovery mechanism.
> 
> I propose that we use “/.well-known/oauth-authorization-server” as the 
> default discovery location, and state that the document MAY also be reachable 
> from “/.well-known/openid-configuration” if the server also provides OpenID 
> Connect on the same domain. Other applications SHOULD use the same parameter 
> names to describe OAuth endpoints and functions inside their service-specific 
> discovery document.
> 
>  — Justin
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Nat Sakimura]

Hi Thomas,

inline:

2016年2月22日(月) 18:44 Thomas Broyer :

> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want to
> do discovery, and leave it open to implementers / to other specs to define
> a .well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any URL,
> returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for
> other metadata specs (like OpenID Connect).
>
With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of
> WWW-Authenticate response header, you have everything you need to proceed
>

Yup. That's one of the requirements to be RESTful, is it not?

In OAuth's case, the resource and the authorization server are usually
tightly coupled. (Otherwise, you need another specs like UMA.)
So, the resource server should be able to tell either the location of the
authz endpoint. In some trusted environment, the resource may as well
return the location of the authz server configuration data. In these cases,
you do not have to decide on what .well-known uri as you say. This frees up
developers from configuration file location collisions etc. We should
strive not to pollute the uri space as much as possible.


> (well, except if there are several ASs each with different scopes; sounds
> like an edge-case to me though; maybe RFC6750 should instead be updated
> with such a parameter such that an RS could return several
> WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
>

Yeah, I guess it is an edge case. I would rather like to see these authz
servers to develop a trust framework under which they can agree on a single
set of common scope parameter values.

Cheers,

Nat


>
> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer  wrote:
>
>> The newly-trimmed OAuth Discovery document is helpful and moving in the
>> right direction. It does, however, still have too many vestiges of its
>> OpenID Connect origins. One issue in particular still really bothers me:
>> the use of “/.well-known/openid-configuration” in the discovery portion. Is
>> this an OAuth discovery document, or an OpenID Connect one? There is
>> absolutely no compelling reason to tie the URL to the OIDC discovery
>> mechanism.
>>
>> I propose that we use “/.well-known/oauth-authorization-server” as the
>> default discovery location, and state that the document MAY also be
>> reachable from “/.well-known/openid-configuration” if the server also
>> provides OpenID Connect on the same domain. Other applications SHOULD use
>> the same parameter names to describe OAuth endpoints and functions inside
>> their service-specific discovery document.
>>
>>  — Justin
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Justin Richer]

I think you can really do both parts in the document without harm. 
Specifying a ".well-known" location doesn't preclude you from including 
the same metadata elsewhere as well, such as with oauth-meta or with a 
service-specific discovery document (like openid-configuration). But it 
would be nice to have a generic authorization server discovery endpoint 
that I can build for a domain so I don't have to always find somewhere 
to put it.


 -- Justin

On 2/22/2016 4:44 AM, Thomas Broyer wrote:

Couldn't the document only describe the metadata?
I quite like the idea of draft-sakimura-oauth-meta if you really want 
to do discovery, and leave it open to implementers / to other specs to 
define a .well-known URL for "auto-configuration".
The metadata described here would then either be used as-is, at any 
URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a 
basis for other metadata specs (like OpenID Connect).
With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of 
WWW-Authenticate response header, you have everything you need to 
proceed (well, except if there are several ASs each with different 
scopes; sounds like an edge-case to me though; maybe RFC6750 should 
instead be updated with such a parameter such that an RS could return 
several WWW-Authenticate: Bearer, each with its own "scope" and "duri" 
value?)


On Fri, Feb 19, 2016 at 10:59 PM Justin Richer > wrote:


The newly-trimmed OAuth Discovery document is helpful and moving
in the right direction. It does, however, still have too many
vestiges of its OpenID Connect origins. One issue in particular
still really bothers me: the use of
“/.well-known/openid-configuration” in the discovery portion. Is
this an OAuth discovery document, or an OpenID Connect one? There
is absolutely no compelling reason to tie the URL to the OIDC
discovery mechanism.

I propose that we use “/.well-known/oauth-authorization-server” as
the default discovery location, and state that the document MAY
also be reachable from “/.well-known/openid-configuration” if the
server also provides OpenID Connect on the same domain. Other
applications SHOULD use the same parameter names to describe OAuth
endpoints and functions inside their service-specific discovery
document.

 — Justin
___
OAuth mailing list
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Thomas Broyer]

Couldn't the document only describe the metadata?
I quite like the idea of draft-sakimura-oauth-meta if you really want to do
discovery, and leave it open to implementers / to other specs to define a
.well-known URL for "auto-configuration".
The metadata described here would then either be used as-is, at any URL,
returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for
other metadata specs (like OpenID Connect).
With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of
WWW-Authenticate response header, you have everything you need to proceed
(well, except if there are several ASs each with different scopes; sounds
like an edge-case to me though; maybe RFC6750 should instead be updated
with such a parameter such that an RS could return several
WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)

On Fri, Feb 19, 2016 at 10:59 PM Justin Richer  wrote:

> The newly-trimmed OAuth Discovery document is helpful and moving in the
> right direction. It does, however, still have too many vestiges of its
> OpenID Connect origins. One issue in particular still really bothers me:
> the use of “/.well-known/openid-configuration” in the discovery portion. Is
> this an OAuth discovery document, or an OpenID Connect one? There is
> absolutely no compelling reason to tie the URL to the OIDC discovery
> mechanism.
>
> I propose that we use “/.well-known/oauth-authorization-server” as the
> default discovery location, and state that the document MAY also be
> reachable from “/.well-known/openid-configuration” if the server also
> provides OpenID Connect on the same domain. Other applications SHOULD use
> the same parameter names to describe OAuth endpoints and functions inside
> their service-specific discovery document.
>
>  — Justin
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Samuel Erdtman]

Hi,

I agree that the user of “/.well-known/openid-configuration” is confusing and
that it would be preferable with something else, but it is written as an
example not necessarily a default.

However to use “/.well-known/oauth-authorization-server” might be
problematic if as written different applications needs different content in
the discovery endpoint. (3.  Obtaining Authorization Server Discovery
Metadata)

//Samuel

On Fri, Feb 19, 2016 at 10:59 PM, Justin Richer  wrote:

> The newly-trimmed OAuth Discovery document is helpful and moving in the
> right direction. It does, however, still have too many vestiges of its
> OpenID Connect origins. One issue in particular still really bothers me:
> the use of “/.well-known/openid-configuration” in the discovery portion. Is
> this an OAuth discovery document, or an OpenID Connect one? There is
> absolutely no compelling reason to tie the URL to the OIDC discovery
> mechanism.
>
> I propose that we use “/.well-known/oauth-authorization-server” as the
> default discovery location, and state that the document MAY also be
> reachable from “/.well-known/openid-configuration” if the server also
> provides OpenID Connect on the same domain. Other applications SHOULD use
> the same parameter names to describe OAuth endpoints and functions inside
> their service-specific discovery document.
>
>  — Justin
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth 2.0 Discovery Location

[Samuel Erdtman]

Hi,

Here coms some review comments, In general I think this is a good document.

//Samuel


2.  Authorization Server Metadata

token_endpoint, I would prefer if the requiredness of this parameter was
put in the beginning instead of the end as with the other parameters.

jwks_uri, I would like to change to recommended since this is not a
parameter required by the base OAuth 2.0 framework similar to
registration_endpoint

jwks_uri, It would be nice with a referens to the definition of jwks_uri.

jwks_uri, “When both signing and encryption keys are made available, a
"use" (public key use) parameter value is REQUIRED for all keys in the
referenced JWK Set to indicate each key's intended usage”
The text would be simpler if it just said that “use” always was required.
It would also be one less thing to argue about when it comes to
interoperability if it was always required.

response_types_supported, an example would be appreciated and maybe a
referees to the response type definition

response_types_supported, What is the difference between
response_types_supported and grant_types_supported, with a quick look they
seem very similar. Could it be enough with one of them?


introspection_endpoint_auth_signing_alg_values_supported,
revocation_endpoint_auth_signing_alg_values_supported and
token_endpoint_auth_signing_alg_values_supported, it would be good with a
reference to the definition of "private_key_jwt" and "client_secret_jwt"

token_endpoint_auth_methods_supported, why not refer to IANA registry for
"OAuth Token Endpoint Authentication Methods" under [IANA.OAuth.Parameters]
in the same way as with
introspection_endpoint_auth_signing_alg_values_supported and
revocation_endpoint_auth_signing_alg_values_supported



3.  Obtaining Authorization Server Discovery Metadata
As also mentioned by Justin I think it is a bit confusing with the example
opened-configuration as .well-known/ postfix could it be made clearer that
it is ab example maybe by making "/.well-known/example-configuration" the
primary example.



5.  Compatibility Notes
”http://openid.net/specs/connect/1.0/issuer"; is only used in this section,
maybe it should be removed?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Vladimir Dzhuvinov]

+1

On 19/02/16 23:59, Justin Richer wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in the right 
> direction. It does, however, still have too many vestiges of its OpenID 
> Connect origins. One issue in particular still really bothers me: the use of 
> “/.well-known/openid-configuration” in the discovery portion. Is this an 
> OAuth discovery document, or an OpenID Connect one? There is absolutely no 
> compelling reason to tie the URL to the OIDC discovery mechanism.
>
> I propose that we use “/.well-known/oauth-authorization-server” as the 
> default discovery location, and state that the document MAY also be reachable 
> from “/.well-known/openid-configuration” if the server also provides OpenID 
> Connect on the same domain. Other applications SHOULD use the same parameter 
> names to describe OAuth endpoints and functions inside their service-specific 
> discovery document. 
>
>  — Justin
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth




smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth 2.0 Discovery Location

[Justin Richer]

The newly-trimmed OAuth Discovery document is helpful and moving in the right 
direction. It does, however, still have too many vestiges of its OpenID Connect 
origins. One issue in particular still really bothers me: the use of 
“/.well-known/openid-configuration” in the discovery portion. Is this an OAuth 
discovery document, or an OpenID Connect one? There is absolutely no compelling 
reason to tie the URL to the OIDC discovery mechanism.

I propose that we use “/.well-known/oauth-authorization-server” as the default 
discovery location, and state that the document MAY also be reachable from 
“/.well-known/openid-configuration” if the server also provides OpenID Connect 
on the same domain. Other applications SHOULD use the same parameter names to 
describe OAuth endpoints and functions inside their service-specific discovery 
document. 

 — Justin
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth