Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Thomas Broyer]

On Sat, Mar 12, 2016 at 6:01 PM Anthony Nadalin 
wrote:

> This is not discovery, its simply metadata, […], I don’t understand the
> rush to get this document out when we already know it’s incomplete
>
+1
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Phil Hunt (IDM)]

I will put that forward in an alternate draft. 

Phil

> On Mar 12, 2016, at 08:28, Mike Jones <michael.jo...@microsoft.com> wrote:
> 
> The AS metadata format is a necessary part of discovery.  No, it doesn’t 
> accomplish every possible aspect of discovery – nor was it ever intended to.  
> I’ve consistently encouraged Phil and others to write down additional aspects 
> of discovery in specifications that build upon this one so that the working 
> group and implementers can evaluate them.
>  
> Since we’re chartered to do discovery and this is part of discovery, no 
> rechartering is needed either for the current specification or for new 
> specifications performing additional discovery tasks.
>  
>   -- Mike
>  
> From: Anthony Nadalin 
> Sent: Saturday, March 12, 2016 8:20 AM
> To: Mike Jones <michael.jo...@microsoft.com>; Brian Campbell 
> <bcampb...@pingidentity.com>; John Bradley <ve7...@ve7jtb.com>
> Cc: oauth <oauth@ietf.org>
> Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>  
> We agreed upon a discovery specification that the WG would work on, we did 
> not agree upon what this has turned out to actually be, so at the minimum the 
> chairs should call for adoption of a Authorization Server Metadata 
> specification and we can continue to work on a Discovery specification
>  
> From: Mike Jones 
> Sent: Saturday, March 12, 2016 8:06 AM
> To: Anthony Nadalin <tony...@microsoft.com>; Brian Campbell 
> <bcampb...@pingidentity.com>; John Bradley <ve7...@ve7jtb.com>
> Cc: oauth <oauth@ietf.org>
> Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>  
> The draft enables easy configuration of OAuth clients with an AS.  For 
> instance, the Microsoft “ADAL” OAuth client software uses AS metadata in this 
> format as an input at client configuration time.
>  
> As a side benefit, having this standard AS metadata format and returning the 
> issuer URL per the Mix-Up Mitigation draft will also enable clients to 
> validate that they are using a consistent set of AS endpoints and 
> information.  But even without the mitigation benefits, the client 
> configuration benefit is the primary reason for the specification.
>  
>   -- Mike
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
> Sent: Friday, March 11, 2016 3:25 PM
> To: Brian Campbell <bcampb...@pingidentity.com>; John Bradley 
> <ve7...@ve7jtb.com>
> Cc: oauth <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>  
> Disagree, what purpose is this activity solving then, it was being pushed as 
> what was need to solve the Mix-up, but that is not true. So now you are 
> suggesting a change in scope and not dealing with discovery.
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
> Sent: Friday, March 11, 2016 3:11 PM
> To: John Bradley <ve7...@ve7jtb.com>
> Cc: oauth <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>  
> I tend to agree with John that addressing the concerns Phil raises should be 
> part of (extension to) the core protocol.  And that those kinds of concerns 
> don't manifest in the way OAuth is typically deployed now. 
> 
> The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" 
> should keep it's scope to the publishing of authorization server metadata. 
> The act of doing discovery is beyond its scope and so is trying to prevent a 
> client from presenting a token to someplace it shouldn't.
> 
>  
> On Fri, Mar 11, 2016 at 9:08 AM, John Bradley <ve7...@ve7jtb.com> wrote:
> Inline
> On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) <phil.h...@oracle.com> wrote:
>  
> John
>  
> In many case all the AS has to check is the domain name component to check 
> for mitm. 
>  
> POP and the other solns are dramatically more complex than a simple check. 
>  
> I was proposing ding that check at the authorization endpoint or token 
> endpoint as part of AT issuance. 
>  
> It is up to the AS how much of the path to validate and or put in the aud or 
> dst. 
>  
>  
>  
> I see it as part of the discovery(bad name aside) problem because we 
> discussed that if a client finds app.example.com how do we ensure it gets a 
> complete set of oauth endpoints as a valid set of endpoints--that a hacker 
> has not inserted one of their own endpoints. The most important endpoint to 
> get right is ensuring the resource server (and optionally the path) is the 
&

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Anthony Nadalin]

This is not discovery, its simply metadata, it’s unclear if this is all the 
metadata that is needed  because discovery has not been fully thought out as 
apparent from all the exchanges that have been going on, I don’t understand the 
rush to get this document out when we already know it’s incomplete

There are still documents from Nat, and I believe there will be one from Phil 
and maybe others.

From: Mike Jones
Sent: Saturday, March 12, 2016 8:29 AM
To: Anthony Nadalin <tony...@microsoft.com>; Brian Campbell 
<bcampb...@pingidentity.com>; John Bradley <ve7...@ve7jtb.com>
Cc: oauth <oauth@ietf.org>
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

The AS metadata format is a necessary part of discovery.  No, it doesn’t 
accomplish every possible aspect of discovery – nor was it ever intended to.  
I’ve consistently encouraged Phil and others to write down additional aspects 
of discovery in specifications that build upon this one so that the working 
group and implementers can evaluate them.

Since we’re chartered to do discovery and this is part of discovery, no 
rechartering is needed either for the current specification or for new 
specifications performing additional discovery tasks.

  -- Mike

From: Anthony Nadalin
Sent: Saturday, March 12, 2016 8:20 AM
To: Mike Jones 
<michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>>; Brian 
Campbell <bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>>; John 
Bradley <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>
Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

We agreed upon a discovery specification that the WG would work on, we did not 
agree upon what this has turned out to actually be, so at the minimum the 
chairs should call for adoption of a Authorization Server Metadata 
specification and we can continue to work on a Discovery specification

From: Mike Jones
Sent: Saturday, March 12, 2016 8:06 AM
To: Anthony Nadalin <tony...@microsoft.com<mailto:tony...@microsoft.com>>; 
Brian Campbell <bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>>; 
John Bradley <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>
Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

The draft enables easy configuration of OAuth clients with an AS.  For 
instance, the Microsoft “ADAL” OAuth client software uses AS metadata in this 
format as an input at client configuration time.

As a side benefit, having this standard AS metadata format and returning the 
issuer URL per the Mix-Up Mitigation draft will also enable clients to validate 
that they are using a consistent set of AS endpoints and information.  But even 
without the mitigation benefits, the client configuration benefit is the 
primary reason for the specification.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Friday, March 11, 2016 3:25 PM
To: Brian Campbell 
<bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>>; John Bradley 
<ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>
Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

Disagree, what purpose is this activity solving then, it was being pushed as 
what was need to solve the Mix-up, but that is not true. So now you are 
suggesting a change in scope and not dealing with discovery.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, March 11, 2016 3:11 PM
To: John Bradley <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>
Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I tend to agree with John that addressing the concerns Phil raises should be 
part of (extension to) the core protocol.  And that those kinds of concerns 
don't manifest in the way OAuth is typically deployed now.

The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" should 
keep it's scope to the publishing of authorization server metadata. The act of 
doing discovery is beyond its scope and so is trying to prevent a client from 
presenting a token to someplace it shouldn't.

On Fri, Mar 11, 2016 at 9:08 AM, John Bradley 
<ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>> wrote:
Inline
On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) 
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote:

John

In many case all the AS has to check is the domain name component to check for 
mitm.

POP and the other solns are dramatically more complex than a simple ch

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Mike Jones]

The AS metadata format is a necessary part of discovery.  No, it doesn’t 
accomplish every possible aspect of discovery – nor was it ever intended to.  
I’ve consistently encouraged Phil and others to write down additional aspects 
of discovery in specifications that build upon this one so that the working 
group and implementers can evaluate them.

Since we’re chartered to do discovery and this is part of discovery, no 
rechartering is needed either for the current specification or for new 
specifications performing additional discovery tasks.

  -- Mike

From: Anthony Nadalin
Sent: Saturday, March 12, 2016 8:20 AM
To: Mike Jones <michael.jo...@microsoft.com>; Brian Campbell 
<bcampb...@pingidentity.com>; John Bradley <ve7...@ve7jtb.com>
Cc: oauth <oauth@ietf.org>
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

We agreed upon a discovery specification that the WG would work on, we did not 
agree upon what this has turned out to actually be, so at the minimum the 
chairs should call for adoption of a Authorization Server Metadata 
specification and we can continue to work on a Discovery specification

From: Mike Jones
Sent: Saturday, March 12, 2016 8:06 AM
To: Anthony Nadalin <tony...@microsoft.com<mailto:tony...@microsoft.com>>; 
Brian Campbell <bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>>; 
John Bradley <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>
Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

The draft enables easy configuration of OAuth clients with an AS.  For 
instance, the Microsoft “ADAL” OAuth client software uses AS metadata in this 
format as an input at client configuration time.

As a side benefit, having this standard AS metadata format and returning the 
issuer URL per the Mix-Up Mitigation draft will also enable clients to validate 
that they are using a consistent set of AS endpoints and information.  But even 
without the mitigation benefits, the client configuration benefit is the 
primary reason for the specification.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Friday, March 11, 2016 3:25 PM
To: Brian Campbell 
<bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>>; John Bradley 
<ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>
Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

Disagree, what purpose is this activity solving then, it was being pushed as 
what was need to solve the Mix-up, but that is not true. So now you are 
suggesting a change in scope and not dealing with discovery.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, March 11, 2016 3:11 PM
To: John Bradley <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>
Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I tend to agree with John that addressing the concerns Phil raises should be 
part of (extension to) the core protocol.  And that those kinds of concerns 
don't manifest in the way OAuth is typically deployed now.

The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" should 
keep it's scope to the publishing of authorization server metadata. The act of 
doing discovery is beyond its scope and so is trying to prevent a client from 
presenting a token to someplace it shouldn't.

On Fri, Mar 11, 2016 at 9:08 AM, John Bradley 
<ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>> wrote:
Inline
On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) 
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote:

John

In many case all the AS has to check is the domain name component to check for 
mitm.

POP and the other solns are dramatically more complex than a simple check.

I was proposing ding that check at the authorization endpoint or token endpoint 
as part of AT issuance.

It is up to the AS how much of the path to validate and or put in the aud or 
dst.



I see it as part of the discovery(bad name aside) problem because we discussed 
that if a client finds 
app.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com%2f=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1=fiS8f60ypiXhyM0qVTeql%2b%2bOzH2wbmECQE7J5TtGPQM%3d>
 how do we ensure it gets a complete set of oauth endpoints as a valid set of 
endpoints--that a hacker has not inserted one of their own endpoints. The most 
important endpoint to get right is ensuring the resource server (and optionally 
the path) is the correct one. W

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Anthony Nadalin]

We agreed upon a discovery specification that the WG would work on, we did not 
agree upon what this has turned out to actually be, so at the minimum the 
chairs should call for adoption of a Authorization Server Metadata 
specification and we can continue to work on a Discovery specification

From: Mike Jones
Sent: Saturday, March 12, 2016 8:06 AM
To: Anthony Nadalin <tony...@microsoft.com>; Brian Campbell 
<bcampb...@pingidentity.com>; John Bradley <ve7...@ve7jtb.com>
Cc: oauth <oauth@ietf.org>
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

The draft enables easy configuration of OAuth clients with an AS.  For 
instance, the Microsoft “ADAL” OAuth client software uses AS metadata in this 
format as an input at client configuration time.

As a side benefit, having this standard AS metadata format and returning the 
issuer URL per the Mix-Up Mitigation draft will also enable clients to validate 
that they are using a consistent set of AS endpoints and information.  But even 
without the mitigation benefits, the client configuration benefit is the 
primary reason for the specification.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Friday, March 11, 2016 3:25 PM
To: Brian Campbell 
<bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>>; John Bradley 
<ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>
Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

Disagree, what purpose is this activity solving then, it was being pushed as 
what was need to solve the Mix-up, but that is not true. So now you are 
suggesting a change in scope and not dealing with discovery.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, March 11, 2016 3:11 PM
To: John Bradley <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>
Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I tend to agree with John that addressing the concerns Phil raises should be 
part of (extension to) the core protocol.  And that those kinds of concerns 
don't manifest in the way OAuth is typically deployed now.

The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" should 
keep it's scope to the publishing of authorization server metadata. The act of 
doing discovery is beyond its scope and so is trying to prevent a client from 
presenting a token to someplace it shouldn't.

On Fri, Mar 11, 2016 at 9:08 AM, John Bradley 
<ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>> wrote:
Inline
On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) 
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote:

John

In many case all the AS has to check is the domain name component to check for 
mitm.

POP and the other solns are dramatically more complex than a simple check.

I was proposing ding that check at the authorization endpoint or token endpoint 
as part of AT issuance.

It is up to the AS how much of the path to validate and or put in the aud or 
dst.



I see it as part of the discovery(bad name aside) problem because we discussed 
that if a client finds 
app.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com%2f=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1=fiS8f60ypiXhyM0qVTeql%2b%2bOzH2wbmECQE7J5TtGPQM%3d>
 how do we ensure it gets a complete set of oauth endpoints as a valid set of 
endpoints--that a hacker has not inserted one of their own endpoints. The most 
important endpoint to get right is ensuring the resource server (and optionally 
the path) is the correct one. We can't really define resource discovery but we 
can validate it to some degree.

I think it is part of core protocol security and should/must not require 
discovery.

What is 
app.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1=jAsZQeChJ%2bR1lbyBoVKwheIYi3PiWLrq%2bxDLbqU6rxk%3d>
 ?

If it is the resource then the client would be preconfigured for it’s AS out of 
band or optionally would do discovery on the issuer uri that you admit needs to 
be configured out of band some way (note discovery is optional)

In the AS meta-data draft it would do a get on a well known file that would 
have configuration for the AS, but not the RS, though some API may optionally 
list a API endpoint like connect has.

The client then makes a authorization request (after registering out of band or 
dynamically).
As part of the authorization request for implicit it could provide the aud/dst 
that it wants the token for.
If that 

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Mike Jones]

The draft enables easy configuration of OAuth clients with an AS.  For 
instance, the Microsoft “ADAL” OAuth client software uses AS metadata in this 
format as an input at client configuration time.

As a side benefit, having this standard AS metadata format and returning the 
issuer URL per the Mix-Up Mitigation draft will also enable clients to validate 
that they are using a consistent set of AS endpoints and information.  But even 
without the mitigation benefits, the client configuration benefit is the 
primary reason for the specification.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Friday, March 11, 2016 3:25 PM
To: Brian Campbell <bcampb...@pingidentity.com>; John Bradley 
<ve7...@ve7jtb.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

Disagree, what purpose is this activity solving then, it was being pushed as 
what was need to solve the Mix-up, but that is not true. So now you are 
suggesting a change in scope and not dealing with discovery.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, March 11, 2016 3:11 PM
To: John Bradley <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>
Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I tend to agree with John that addressing the concerns Phil raises should be 
part of (extension to) the core protocol.  And that those kinds of concerns 
don't manifest in the way OAuth is typically deployed now.

The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" should 
keep it's scope to the publishing of authorization server metadata. The act of 
doing discovery is beyond its scope and so is trying to prevent a client from 
presenting a token to someplace it shouldn't.

On Fri, Mar 11, 2016 at 9:08 AM, John Bradley 
<ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>> wrote:
Inline
On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) 
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote:

John

In many case all the AS has to check is the domain name component to check for 
mitm.

POP and the other solns are dramatically more complex than a simple check.

I was proposing ding that check at the authorization endpoint or token endpoint 
as part of AT issuance.

It is up to the AS how much of the path to validate and or put in the aud or 
dst.



I see it as part of the discovery(bad name aside) problem because we discussed 
that if a client finds 
app.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com%2f=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1=fiS8f60ypiXhyM0qVTeql%2b%2bOzH2wbmECQE7J5TtGPQM%3d>
 how do we ensure it gets a complete set of oauth endpoints as a valid set of 
endpoints--that a hacker has not inserted one of their own endpoints. The most 
important endpoint to get right is ensuring the resource server (and optionally 
the path) is the correct one. We can't really define resource discovery but we 
can validate it to some degree.

I think it is part of core protocol security and should/must not require 
discovery.

What is 
app.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1=jAsZQeChJ%2bR1lbyBoVKwheIYi3PiWLrq%2bxDLbqU6rxk%3d>
 ?

If it is the resource then the client would be preconfigured for it’s AS out of 
band or optionally would do discovery on the issuer uri that you admit needs to 
be configured out of band some way (note discovery is optional)

In the AS meta-data draft it would do a get on a well known file that would 
have configuration for the AS, but not the RS, though some API may optionally 
list a API endpoint like connect has.

The client then makes a authorization request (after registering out of band or 
dynamically).
As part of the authorization request for implicit it could provide the aud/dst 
that it wants the token for.
If that is not sent then the aud/dst are implicit in the scopes.

The client gets back a AT with a list of scopes granted, aud/dst allowed and 
time to live for the token (one extra thing returned)

This doesn’t require any discovery (yes there is a optional AS meta-data 
discovery but not required)

I prefer to fix the RS man in the middle issue as part of the protocol and not 
part of discovery that should remain optional.

I honestly don’t quite know how the client learns about this bad RS and starts 
talking to it, so this may be a solution to a problem that doesn’t yet exist.   
The one place this is posable is if the registration for the client is 
compromised.  However we are discussing other mitiga

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Brian Campbell]

Good to see you are following along with what's happened.

On Fri, Mar 11, 2016 at 5:00 PM, Anthony Nadalin <tony...@microsoft.com>
wrote:

> Sorry but not true, this started out as “discovery” and now it’s not
>
>
>
> *From:* Brian Campbell [mailto:bcampb...@pingidentity.com]
> *Sent:* Friday, March 11, 2016 3:59 PM
> *To:* Anthony Nadalin <tony...@microsoft.com>
> *Cc:* John Bradley <ve7...@ve7jtb.com>; oauth <oauth@ietf.org>
>
> *Subject:* Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>
>
>
> That *is* the scope of the current document, which a majority of folks
> have agreed with. I was reiterating that the name of the document should
> reflect its content, something else that has been widely agreed with.
>
>
>
> On Fri, Mar 11, 2016 at 4:24 PM, Anthony Nadalin <tony...@microsoft.com>
> wrote:
>
> Disagree, what purpose is this activity solving then, it was being pushed
> as what was need to solve the Mix-up, but that is not true. So now you are
> suggesting a change in scope and not dealing with discovery.
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian
> Campbell
> *Sent:* Friday, March 11, 2016 3:11 PM
> *To:* John Bradley <ve7...@ve7jtb.com>
>
>
> *Cc:* oauth <oauth@ietf.org>
> *Subject:* Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>
>
>
> I tend to agree with John that addressing the concerns Phil raises should
> be part of (extension to) the core protocol.  And that those kinds of
> concerns don't manifest in the way OAuth is typically deployed now.
>
> The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata"
> should keep it's scope to the publishing of authorization server metadata.
> The act of doing discovery is beyond its scope and so is trying to prevent
> a client from presenting a token to someplace it shouldn't.
>
>
>
> On Fri, Mar 11, 2016 at 9:08 AM, John Bradley <ve7...@ve7jtb.com> wrote:
>
> Inline
>
> On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) <phil.h...@oracle.com>
> wrote:
>
>
>
> John
>
>
>
> In many case all the AS has to check is the domain name component to check
> for mitm.
>
>
>
> POP and the other solns are dramatically more complex than a simple check.
>
>
>
> I was proposing ding that check at the authorization endpoint or token
> endpoint as part of AT issuance.
>
>
>
> It is up to the AS how much of the path to validate and or put in the aud
> or dst.
>
>
>
>
>
>
>
> I see it as part of the discovery(bad name aside) problem because we
> discussed that if a client finds app.example.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com%2f=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1=fiS8f60ypiXhyM0qVTeql%2b%2bOzH2wbmECQE7J5TtGPQM%3d>
> how do we ensure it gets a complete set of oauth endpoints as a valid set
> of endpoints--that a hacker has not inserted one of their own endpoints.
> The most important endpoint to get right is ensuring the resource server
> (and optionally the path) is the correct one. We can't really define
> resource discovery but we can validate it to some degree.
>
>
>
> I think it is part of core protocol security and should/must not require
> discovery.
>
>
>
> What is app.example.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1=jAsZQeChJ%2bR1lbyBoVKwheIYi3PiWLrq%2bxDLbqU6rxk%3d>
> ?
>
>
>
> If it is the resource then the client would be preconfigured for it’s AS
> out of band or optionally would do discovery on the issuer uri that you
> admit needs to be configured out of band some way (note discovery is
> optional)
>
>
>
> In the AS meta-data draft it would do a get on a well known file that
> would have configuration for the AS, but not the RS, though some API may
> optionally list a API endpoint like connect has.
>
>
>
> The client then makes a authorization request (after registering out of
> band or dynamically).
>
> As part of the authorization request for implicit it could provide the
> aud/dst that it wants the token for.
>
> If that is not sent then the aud/dst are implicit in the scopes.
>
>
>
> The client gets back a AT with a list of scopes granted, aud/dst allowed
> and time to live for the token (one extra thing returned)
>
>
>
> This doesn’t require any discovery (yes there is a optional AS meta-data
> discovery but not required)
>

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Anthony Nadalin]

Sorry but not true, this started out as “discovery” and now it’s not

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Friday, March 11, 2016 3:59 PM
To: Anthony Nadalin <tony...@microsoft.com>
Cc: John Bradley <ve7...@ve7jtb.com>; oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

That *is* the scope of the current document, which a majority of folks have 
agreed with. I was reiterating that the name of the document should reflect its 
content, something else that has been widely agreed with.

On Fri, Mar 11, 2016 at 4:24 PM, Anthony Nadalin 
<tony...@microsoft.com<mailto:tony...@microsoft.com>> wrote:
Disagree, what purpose is this activity solving then, it was being pushed as 
what was need to solve the Mix-up, but that is not true. So now you are 
suggesting a change in scope and not dealing with discovery.

From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Brian Campbell
Sent: Friday, March 11, 2016 3:11 PM
To: John Bradley <ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>>

Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I tend to agree with John that addressing the concerns Phil raises should be 
part of (extension to) the core protocol.  And that those kinds of concerns 
don't manifest in the way OAuth is typically deployed now.

The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" should 
keep it's scope to the publishing of authorization server metadata. The act of 
doing discovery is beyond its scope and so is trying to prevent a client from 
presenting a token to someplace it shouldn't.

On Fri, Mar 11, 2016 at 9:08 AM, John Bradley 
<ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>> wrote:
Inline
On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) 
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote:

John

In many case all the AS has to check is the domain name component to check for 
mitm.

POP and the other solns are dramatically more complex than a simple check.

I was proposing ding that check at the authorization endpoint or token endpoint 
as part of AT issuance.

It is up to the AS how much of the path to validate and or put in the aud or 
dst.



I see it as part of the discovery(bad name aside) problem because we discussed 
that if a client finds 
app.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com%2f=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1=fiS8f60ypiXhyM0qVTeql%2b%2bOzH2wbmECQE7J5TtGPQM%3d>
 how do we ensure it gets a complete set of oauth endpoints as a valid set of 
endpoints--that a hacker has not inserted one of their own endpoints. The most 
important endpoint to get right is ensuring the resource server (and optionally 
the path) is the correct one. We can't really define resource discovery but we 
can validate it to some degree.

I think it is part of core protocol security and should/must not require 
discovery.

What is 
app.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1=jAsZQeChJ%2bR1lbyBoVKwheIYi3PiWLrq%2bxDLbqU6rxk%3d>
 ?

If it is the resource then the client would be preconfigured for it’s AS out of 
band or optionally would do discovery on the issuer uri that you admit needs to 
be configured out of band some way (note discovery is optional)

In the AS meta-data draft it would do a get on a well known file that would 
have configuration for the AS, but not the RS, though some API may optionally 
list a API endpoint like connect has.

The client then makes a authorization request (after registering out of band or 
dynamically).
As part of the authorization request for implicit it could provide the aud/dst 
that it wants the token for.
If that is not sent then the aud/dst are implicit in the scopes.

The client gets back a AT with a list of scopes granted, aud/dst allowed and 
time to live for the token (one extra thing returned)

This doesn’t require any discovery (yes there is a optional AS meta-data 
discovery but not required)

I prefer to fix the RS man in the middle issue as part of the protocol and not 
part of discovery that should remain optional.

I honestly don’t quite know how the client learns about this bad RS and starts 
talking to it, so this may be a solution to a problem that doesn’t yet exist.   
The one place this is posable is if the registration for the client is 
compromised.  However we are discussing other mitigations for that that also 
explicitly do not require discovery.

John B.


I am not stuck on webfinger or well-known. Because this is config maybe it 
should be an oauth endpoint.

Phil

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Brian Campbell]

That *is* the scope of the current document, which a majority of folks have
agreed with. I was reiterating that the name of the document should reflect
its content, something else that has been widely agreed with.

On Fri, Mar 11, 2016 at 4:24 PM, Anthony Nadalin <tony...@microsoft.com>
wrote:

> Disagree, what purpose is this activity solving then, it was being pushed
> as what was need to solve the Mix-up, but that is not true. So now you are
> suggesting a change in scope and not dealing with discovery.
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian
> Campbell
> *Sent:* Friday, March 11, 2016 3:11 PM
> *To:* John Bradley <ve7...@ve7jtb.com>
>
> *Cc:* oauth <oauth@ietf.org>
> *Subject:* Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>
>
>
> I tend to agree with John that addressing the concerns Phil raises should
> be part of (extension to) the core protocol.  And that those kinds of
> concerns don't manifest in the way OAuth is typically deployed now.
>
> The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata"
> should keep it's scope to the publishing of authorization server metadata.
> The act of doing discovery is beyond its scope and so is trying to prevent
> a client from presenting a token to someplace it shouldn't.
>
>
>
> On Fri, Mar 11, 2016 at 9:08 AM, John Bradley <ve7...@ve7jtb.com> wrote:
>
> Inline
>
> On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) <phil.h...@oracle.com>
> wrote:
>
>
>
> John
>
>
>
> In many case all the AS has to check is the domain name component to check
> for mitm.
>
>
>
> POP and the other solns are dramatically more complex than a simple check.
>
>
>
> I was proposing ding that check at the authorization endpoint or token
> endpoint as part of AT issuance.
>
>
>
> It is up to the AS how much of the path to validate and or put in the aud
> or dst.
>
>
>
>
>
>
>
> I see it as part of the discovery(bad name aside) problem because we
> discussed that if a client finds app.example.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com%2f=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1=fiS8f60ypiXhyM0qVTeql%2b%2bOzH2wbmECQE7J5TtGPQM%3d>
> how do we ensure it gets a complete set of oauth endpoints as a valid set
> of endpoints--that a hacker has not inserted one of their own endpoints.
> The most important endpoint to get right is ensuring the resource server
> (and optionally the path) is the correct one. We can't really define
> resource discovery but we can validate it to some degree.
>
>
>
> I think it is part of core protocol security and should/must not require
> discovery.
>
>
>
> What is app.example.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1=jAsZQeChJ%2bR1lbyBoVKwheIYi3PiWLrq%2bxDLbqU6rxk%3d>
> ?
>
>
>
> If it is the resource then the client would be preconfigured for it’s AS
> out of band or optionally would do discovery on the issuer uri that you
> admit needs to be configured out of band some way (note discovery is
> optional)
>
>
>
> In the AS meta-data draft it would do a get on a well known file that
> would have configuration for the AS, but not the RS, though some API may
> optionally list a API endpoint like connect has.
>
>
>
> The client then makes a authorization request (after registering out of
> band or dynamically).
>
> As part of the authorization request for implicit it could provide the
> aud/dst that it wants the token for.
>
> If that is not sent then the aud/dst are implicit in the scopes.
>
>
>
> The client gets back a AT with a list of scopes granted, aud/dst allowed
> and time to live for the token (one extra thing returned)
>
>
>
> This doesn’t require any discovery (yes there is a optional AS meta-data
> discovery but not required)
>
>
>
> I prefer to fix the RS man in the middle issue as part of the protocol and
> not part of discovery that should remain optional.
>
>
>
> I honestly don’t quite know how the client learns about this bad RS and
> starts talking to it, so this may be a solution to a problem that doesn’t
> yet exist.   The one place this is posable is if the registration for the
> client is compromised.  However we are discussing other mitigations for
> that that also explicitly do not require discovery.
>
>
>
> John B.
>
>
>
>
>
> I am not stuck on webfinger or well

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Anthony Nadalin]

Disagree, what purpose is this activity solving then, it was being pushed as 
what was need to solve the Mix-up, but that is not true. So now you are 
suggesting a change in scope and not dealing with discovery.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, March 11, 2016 3:11 PM
To: John Bradley <ve7...@ve7jtb.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I tend to agree with John that addressing the concerns Phil raises should be 
part of (extension to) the core protocol.  And that those kinds of concerns 
don't manifest in the way OAuth is typically deployed now.

The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" should 
keep it's scope to the publishing of authorization server metadata. The act of 
doing discovery is beyond its scope and so is trying to prevent a client from 
presenting a token to someplace it shouldn't.


On Fri, Mar 11, 2016 at 9:08 AM, John Bradley 
<ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>> wrote:
Inline
On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) 
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>> wrote:

John

In many case all the AS has to check is the domain name component to check for 
mitm.

POP and the other solns are dramatically more complex than a simple check.

I was proposing ding that check at the authorization endpoint or token endpoint 
as part of AT issuance.

It is up to the AS how much of the path to validate and or put in the aud or 
dst.



I see it as part of the discovery(bad name aside) problem because we discussed 
that if a client finds 
app.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com%2f=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1=fiS8f60ypiXhyM0qVTeql%2b%2bOzH2wbmECQE7J5TtGPQM%3d>
 how do we ensure it gets a complete set of oauth endpoints as a valid set of 
endpoints--that a hacker has not inserted one of their own endpoints. The most 
important endpoint to get right is ensuring the resource server (and optionally 
the path) is the correct one. We can't really define resource discovery but we 
can validate it to some degree.

I think it is part of core protocol security and should/must not require 
discovery.

What is 
app.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1=jAsZQeChJ%2bR1lbyBoVKwheIYi3PiWLrq%2bxDLbqU6rxk%3d>
 ?

If it is the resource then the client would be preconfigured for it’s AS out of 
band or optionally would do discovery on the issuer uri that you admit needs to 
be configured out of band some way (note discovery is optional)

In the AS meta-data draft it would do a get on a well known file that would 
have configuration for the AS, but not the RS, though some API may optionally 
list a API endpoint like connect has.

The client then makes a authorization request (after registering out of band or 
dynamically).
As part of the authorization request for implicit it could provide the aud/dst 
that it wants the token for.
If that is not sent then the aud/dst are implicit in the scopes.

The client gets back a AT with a list of scopes granted, aud/dst allowed and 
time to live for the token (one extra thing returned)

This doesn’t require any discovery (yes there is a optional AS meta-data 
discovery but not required)

I prefer to fix the RS man in the middle issue as part of the protocol and not 
part of discovery that should remain optional.

I honestly don’t quite know how the client learns about this bad RS and starts 
talking to it, so this may be a solution to a problem that doesn’t yet exist.   
The one place this is posable is if the registration for the client is 
compromised.  However we are discussing other mitigations for that that also 
explicitly do not require discovery.

John B.



I am not stuck on webfinger or well-known. Because this is config maybe it 
should be an oauth endpoint.

Phil

On Mar 11, 2016, at 06:51, John Bradley 
<ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>> wrote:
I think Phil is proposing something different.   Should the client send a token 
from this AS to that RS.

His goal is to prevent man in the middle attacks where a bad RS gets a AT that 
is audianced to/accepted by another RS.

That is separate from the question of if a RS accepts tokens from a good AS.   
A bad AS would always say yes.

We need to be careful of what if anything the RS provides to the client as 
meta-data without validation.

Currently the client can provide a list of scopes required to get access.   I 
personally feel it would be useful to also include in the unauthenticated error 
response an indication of what API the resource supports.  Say “scim2” as an 
example.

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Brian Campbell]

t of a AS meta-data discovery problem.
>
> I do however think that it is important.
>
> We have been discussing this as a separate problem to AS meta-data
> discovery where the endpoints of the AS and it’s configuration are
> discovery.   Sorry for perhaps stating the obvious, but the RS is
> explicitly not part of the AS in OAuth 2.   Starting in WAP that was a core
> principal.
>
> So we have a number of options to address the RS token leakage via MiTM
> attacks.
>
> 1) PoP bound tokens.  If they are bound to the TLS channel by mutual TLS
> or Token binding they cannot be replayed.  Signed messages where the
> signing covers the RS Host and path components,  also would work.
>
> 2) Have the AS audience restrict the resources the AT is good at. (AT
> should be doing that now)
> In the token response include the list of audience/s the token is
> presentable at.  The client would throw an error if the RS it intends to
> send the token to is not on the list.   The RS the token is good at might
> change based on scopes, client_id and resource owner.   This is the place
> where all of that comes together.   In some cases the RS and AS might not
> have a pre-established relationship.   The client should send the RS base
> URI to the AS as part of the request.  The AS can use that to audience
> restrict the AT and issue the AT or refuse to issue the AT based on policy.
> It can also use the audience in the request to down audience the AT if the
> default is to have multiple audiences.We may want to use a term other
> than audience for this like resource or destination.  It is a audience but
> that term might confuse people with AT.
>
> We did talk about breaking audience out of POP key distribution, and Brian
> Campbell did a draft
> https://tools.ietf.org/html/draft-campbell-oauth-dst4jwt.
>
> To do this we could take dst4jwt and add another spec that adds a new dst
> parameter to the token and authorization endpoints requests That would be a
> space separated list of dst values.  and in the response from the token
> endpoint would be a JSON array of dst values.
>
> 3) Have the AS always return all the list of all RS the token can be used
> at (basically Nat's link relationship proposal).  It needs a way to handle
> down destinationing of AT and to allow for un-configured RS that it might
> issue a token for.  So could be combined with dst from 2.  Basically
> returning the acceptable destinations as link headers vs JS in the response
> is mostly a style issue that other people can bike shed.
>
>
> 4) Trying to add all the RS to the AS discovery document.  This seems
> impractical as there would be multiple protocols and doesn’t address
> un-configured RS.
>
> 5) Some new AS endpoint that the client could introspect the RS URI and
> get back metadata about if the client should send tokens there.
> A couple of problems with this.  The first is that it would not
> support un-configured RS unless you add dst to the token and authorization
> endpoints.   The other is that the introspection endpoint doesn’t have the
> context of the RO and client_id unless you also pass the code/RT and
> client_id, and probably client credentials.Basically this is trying to
> introspect the AT to determine the audiance/dst.   By the time you build a
> new introspection endpoint securely it is going to look like the token
> endpoint with a bit more meta data about the token beyond expiry and scopes.
>
>
> I think we should go a head with the renamed "OAuth 2.0 Authorization
> Server Discovery Metadata”
> I am also fine with making the default document 'openid-configuration’  as
> long as we allow for protocol specific variation so that SCIM2 could define
> a file name.If people want we could do a API  to file name registry so
> that protocol specific ones can be defined.
>
> We are all-ready working on option 1 to secure AT, we need a spec like I
> propose in 2 for bearer tokens.  We can add one request parameter and a bit
> more token meta-data to the token response and that takes care of the
> problem.   Honestly we probably should have separated scope and destination
> in the first place and returned both dst and scope in the response all
> along, so this is update that is consistent with the eisting architecture
> of OAuth 2.
>
> Lets keep the two issues separate.
>
> John B.
>
>
>
>
> On Mar 11, 2016, at 12:07 AM, Anthony Nadalin <tony...@microsoft.com>
> wrote:
>
> The relationship between AS and RS need to be scoped to “does this RS
> accept tokens from this AS” as a list is too much information that could be
> used in the wrong way
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org <oauth-boun...@ietf.org>] *On
> Behalf Of

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[John Bradley]

f they are bound to the TLS channel by mutual TLS or 
>> Token binding they cannot be replayed.  Signed messages where the signing 
>> covers the RS Host and path components,  also would work.
>> 
>> 2) Have the AS audience restrict the resources the AT is good at. (AT should 
>> be doing that now) 
>> In the token response include the list of audience/s the token is 
>> presentable at.  The client would throw an error if the RS it intends to 
>> send the token to is not on the list.   The RS the token is good at might 
>> change based on scopes, client_id and resource owner.   This is the place 
>> where all of that comes together.   In some cases the RS and AS might not 
>> have a pre-established relationship.   The client should send the RS base 
>> URI to the AS as part of the request.  The AS can use that to audience 
>> restrict the AT and issue the AT or refuse to issue the AT based on policy.
>> It can also use the audience in the request to down audience the AT if the 
>> default is to have multiple audiences.We may want to use a term other 
>> than audience for this like resource or destination.  It is a audience but 
>> that term might confuse people with AT.
>> 
>> We did talk about breaking audience out of POP key distribution, and Brian 
>> Campbell did a draft 
>> https://tools.ietf.org/html/draft-campbell-oauth-dst4jwt 
>> <https://tools.ietf.org/html/draft-campbell-oauth-dst4jwt>.   
>> 
>> To do this we could take dst4jwt and add another spec that adds a new dst 
>> parameter to the token and authorization endpoints requests That would be a 
>> space separated list of dst values.  and in the response from the token 
>> endpoint would be a JSON array of dst values.
>> 
>> 3) Have the AS always return all the list of all RS the token can be used at 
>> (basically Nat's link relationship proposal).  It needs a way to handle 
>> down destinationing of AT and to allow for un-configured RS that it might 
>> issue a token for.  So could be combined with dst from 2.  Basically 
>> returning the acceptable destinations as link headers vs JS in the response 
>> is mostly a style issue that other people can bike shed.
>> 
>> 
>> 4) Trying to add all the RS to the AS discovery document.  This seems 
>> impractical as there would be multiple protocols and doesn’t address 
>> un-configured RS.
>> 
>> 5) Some new AS endpoint that the client could introspect the RS URI and get 
>> back metadata about if the client should send tokens there.
>> A couple of problems with this.  The first is that it would not support 
>> un-configured RS unless you add dst to the token and authorization 
>> endpoints.   The other is that the introspection endpoint doesn’t have the 
>> context of the RO and client_id unless you also pass the code/RT and 
>> client_id, and probably client credentials.Basically this is trying to 
>> introspect the AT to determine the audiance/dst.   By the time you build a 
>> new introspection endpoint securely it is going to look like the token 
>> endpoint with a bit more meta data about the token beyond expiry and scopes.
>> 
>> 
>> I think we should go a head with the renamed "OAuth 2.0 Authorization Server 
>> Discovery Metadata” 
>> I am also fine with making the default document 'openid-configuration’  as 
>> long as we allow for protocol specific variation so that SCIM2 could define 
>> a file name.If people want we could do a API  to file name registry so 
>> that protocol specific ones can be defined.
>> 
>> We are all-ready working on option 1 to secure AT, we need a spec like I 
>> propose in 2 for bearer tokens.  We can add one request parameter and a bit 
>> more token meta-data to the token response and that takes care of the 
>> problem.   Honestly we probably should have separated scope and destination 
>> in the first place and returned both dst and scope in the response all 
>> along, so this is update that is consistent with the eisting architecture of 
>> OAuth 2.
>> 
>> Lets keep the two issues separate.
>> 
>> John B.
>>  
>> 
>> 
>> 
>>> On Mar 11, 2016, at 12:07 AM, Anthony Nadalin <tony...@microsoft.com 
>>> <mailto:tony...@microsoft.com>> wrote:
>>> 
>>> The relationship between AS and RS need to be scoped to “does this RS 
>>> accept tokens from this AS” as a list is too much information that could be 
>>> used in the wrong way
>>>   <>
>>> From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ie

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Anthony Nadalin]

There have been way too many issues, confused conversations and discussions on 
and off list to have this document move forward, suggest that this be one of 
the main items on the agenda for when we meet.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Thursday, March 10, 2016 9:09 AM
To: Vladimir Dzhuvinov <vladi...@connect2id.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I strongly oppose. 2 major issues.

This is not service discovery this is configuration lookup. The client must 
have already discovered the oauth issuer uri and the resource uri.

The objective was to provide a method to ensure the client has a valid set of 
endpoints to prevent mitm of endpoints like the token endpoint to the resource 
server.

The draft does not address the issue of a client being given a bad endpoint for 
an rs. What we end up with is a promiscuous authz service giving out tokens to 
an unwitting client.

Phil

On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov 
<vladi...@connect2id.com<mailto:vladi...@connect2id.com>> wrote:
+1 to move forward with these
On 10/03/16 17:35, Brian Campbell wrote:

+1



On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 
<roland.hedb...@umu.se><mailto:roland.hedb...@umu.se>

wrote:



I support this document being moved forward with these two changes:



- change name to “OAuth 2.0 Authorization Server Discovery Metadata” as

proposed by Brian and

- use the URI path suffix ’oauth-authorization-server’ instead of

’openid-configuration’ as proposed by Justin.



18 feb 2016 kl. 14:40 skrev Hannes Tschofenig 
<hannes.tschofe...@gmx.net<mailto:hannes.tschofe...@gmx.net>

:



Hi all,



This is a Last Call for comments on the  OAuth 2.0 Discovery

specification:

https://tools.ietf.org/html/draft-ietf-oauth-discovery-01<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-discovery-01=01%7c01%7ctonynad%40microsoft.com%7caeeff0cf0b5d44d8ade808d349073b5d%7c72f988bf86f141af91ab2d7cd011db47%7c1=CdkVvfNBrMho0Fhfri9J3WXztcjcW2jIPI7yv%2f7hf6A%3d>



Since this document was only adopted recently we are running this last

call for **3 weeks**.



Please have your comments in no later than March 10th.



Ciao

Hannes & Derek



___

OAuth mailing list

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

https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth=01%7c01%7ctonynad%40microsoft.com%7caeeff0cf0b5d44d8ade808d349073b5d%7c72f988bf86f141af91ab2d7cd011db47%7c1=um6A5NXgypvNEdAGBEatm1sKhG7yiOEfsDAgWvgjjC4%3d>

— Roland



”Everybody should be quiet near a little stream and listen."

From ’Open House for Butterflies’ by Ruth Krauss





___

OAuth mailing list

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

https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth=01%7c01%7ctonynad%40microsoft.com%7caeeff0cf0b5d44d8ade808d349073b5d%7c72f988bf86f141af91ab2d7cd011db47%7c1=um6A5NXgypvNEdAGBEatm1sKhG7yiOEfsDAgWvgjjC4%3d>








___

OAuth mailing list

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

https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth=01%7c01%7ctonynad%40microsoft.com%7caeeff0cf0b5d44d8ade808d349073b5d%7c72f988bf86f141af91ab2d7cd011db47%7c1=um6A5NXgypvNEdAGBEatm1sKhG7yiOEfsDAgWvgjjC4%3d>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Phil Hunt (IDM)]

n bike shed.
> 
> 
> 4) Trying to add all the RS to the AS discovery document.  This seems 
> impractical as there would be multiple protocols and doesn’t address 
> un-configured RS.
> 
> 5) Some new AS endpoint that the client could introspect the RS URI and get 
> back metadata about if the client should send tokens there.
> A couple of problems with this.  The first is that it would not support 
> un-configured RS unless you add dst to the token and authorization endpoints. 
>   The other is that the introspection endpoint doesn’t have the context of 
> the RO and client_id unless you also pass the code/RT and client_id, and 
> probably client credentials.Basically this is trying to introspect the AT 
> to determine the audiance/dst.   By the time you build a new introspection 
> endpoint securely it is going to look like the token endpoint with a bit more 
> meta data about the token beyond expiry and scopes.
> 
> 
> I think we should go a head with the renamed "OAuth 2.0 Authorization Server 
> Discovery Metadata” 
> I am also fine with making the default document 'openid-configuration’  as 
> long as we allow for protocol specific variation so that SCIM2 could define a 
> file name.If people want we could do a API  to file name registry so that 
> protocol specific ones can be defined.
> 
> We are all-ready working on option 1 to secure AT, we need a spec like I 
> propose in 2 for bearer tokens.  We can add one request parameter and a bit 
> more token meta-data to the token response and that takes care of the 
> problem.   Honestly we probably should have separated scope and destination 
> in the first place and returned both dst and scope in the response all along, 
> so this is update that is consistent with the eisting architecture of OAuth 2.
> 
> Lets keep the two issues separate.
> 
> John B.
>  
> 
> 
> 
>> On Mar 11, 2016, at 12:07 AM, Anthony Nadalin <tony...@microsoft.com> wrote:
>> 
>> The relationship between AS and RS need to be scoped to “does this RS accept 
>> tokens from this AS” as a list is too much information that could be used in 
>> the wrong way
>>  
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
>> Sent: Thursday, March 10, 2016 6:25 PM
>> To: Phil Hunt (IDM) <phil.h...@oracle.com>
>> Cc: oauth <oauth@ietf.org>
>> Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>>  
>> Phil, 
>>  
>> Right. So what my conditional approvals (11 conditions in total) said was to 
>> drop the word "discovery" from everywhere. This is not a discovery spec. 
>> This is a configuration lookup spec as you correctly points out. So, I am 
>> with you here. 
>>  
>> Also, my 2nd conditiion is essentially saying to drop section 3. 
>>  
>> One thing that I overlooked and am with you is that we need to be able to 
>> express the AS-RS relationships. I have been preaching this in the other 
>> thread for so many times as you know so I thought I pointed it out, but 
>> missed apparently in my previous comment. So, I would add my 12th condition: 
>>  
>> 12. A way to express a list of valid RSs for this AS needs to be added to 
>> section 2. 
>>  
>> Best, 
>>  
>> Nat
>>  
>> 2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) <phil.h...@oracle.com>:
>> I strongly oppose. 2 major issues. 
>>  
>> This is not service discovery this is configuration lookup. The client must 
>> have already discovered the oauth issuer uri and the resource uri. 
>>  
>> The objective was to provide a method to ensure the client has a valid set 
>> of endpoints to prevent mitm of endpoints like the token endpoint to the 
>> resource server. 
>>  
>> The draft does not address the issue of a client being given a bad endpoint 
>> for an rs. What we end up with is a promiscuous authz service giving out 
>> tokens to an unwitting client. 
>> 
>> Phil
>> 
>> On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov <vladi...@connect2id.com> 
>> wrote:
>> 
>> +1 to move forward with these
>> 
>> On 10/03/16 17:35, Brian Campbell wrote:
>> +1
>>  
>> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg <roland.hedb...@umu.se>
>> wrote:
>>  
>> I support this document being moved forward with these two changes:
>>  
>> - change name to “OAuth 2.0 Authorization Server Discovery Metadata” as
>> proposed by Brian and
>> - use the URI path suffix ’oauth-authorization-server’ instead of
>> ’openid-configuration’ as proposed by Justin.
>>  
>

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[John Bradley]

ld do a API  to file name registry so that 
protocol specific ones can be defined.

We are all-ready working on option 1 to secure AT, we need a spec like I 
propose in 2 for bearer tokens.  We can add one request parameter and a bit 
more token meta-data to the token response and that takes care of the problem.  
 Honestly we probably should have separated scope and destination in the first 
place and returned both dst and scope in the response all along, so this is 
update that is consistent with the eisting architecture of OAuth 2.

Lets keep the two issues separate.

John B.
 



> On Mar 11, 2016, at 12:07 AM, Anthony Nadalin <tony...@microsoft.com> wrote:
> 
> The relationship between AS and RS need to be scoped to “does this RS accept 
> tokens from this AS” as a list is too much information that could be used in 
> the wrong way
>   <>
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
> Sent: Thursday, March 10, 2016 6:25 PM
> To: Phil Hunt (IDM) <phil.h...@oracle.com>
> Cc: oauth <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>  
> Phil, 
>  
> Right. So what my conditional approvals (11 conditions in total) said was to 
> drop the word "discovery" from everywhere. This is not a discovery spec. This 
> is a configuration lookup spec as you correctly points out. So, I am with you 
> here. 
>  
> Also, my 2nd conditiion is essentially saying to drop section 3. 
>  
> One thing that I overlooked and am with you is that we need to be able to 
> express the AS-RS relationships. I have been preaching this in the other 
> thread for so many times as you know so I thought I pointed it out, but 
> missed apparently in my previous comment. So, I would add my 12th condition: 
>  
> 12. A way to express a list of valid RSs for this AS needs to be added to 
> section 2. 
>  
> Best, 
>  
> Nat
>  
> 2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) <phil.h...@oracle.com 
> <mailto:phil.h...@oracle.com>>:
> I strongly oppose. 2 major issues. 
>  
> This is not service discovery this is configuration lookup. The client must 
> have already discovered the oauth issuer uri and the resource uri. 
>  
> The objective was to provide a method to ensure the client has a valid set of 
> endpoints to prevent mitm of endpoints like the token endpoint to the 
> resource server. 
>  
> The draft does not address the issue of a client being given a bad endpoint 
> for an rs. What we end up with is a promiscuous authz service giving out 
> tokens to an unwitting client. 
> 
> Phil
> 
> On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov <vladi...@connect2id.com 
> <mailto:vladi...@connect2id.com>> wrote:
> 
> +1 to move forward with these
> 
> On 10/03/16 17:35, Brian Campbell wrote:
> +1
>  
> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg <roland.hedb...@umu.se> 
> <mailto:roland.hedb...@umu.se>
> wrote:
>  
> I support this document being moved forward with these two changes:
>  
> - change name to “OAuth 2.0 Authorization Server Discovery Metadata” as
> proposed by Brian and
> - use the URI path suffix ’oauth-authorization-server’ instead of
> ’openid-configuration’ as proposed by Justin.
>  
> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig <hannes.tschofe...@gmx.net 
> <mailto:hannes.tschofe...@gmx.net>
> :
>  
> Hi all,
>  
> This is a Last Call for comments on the  OAuth 2.0 Discovery
> specification:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01 
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-discovery-01=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1=w3%2biiaWon81LJCU%2b2mCPRmA%2brECBHgqyRr0OgqiWSHU%3d>
>  
> Since this document was only adopted recently we are running this last
> call for **3 weeks**.
>  
> Please have your comments in no later than March 10th.
>  
> Ciao
> Hannes & Derek
>  
> ___
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth 
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d>
> — Roland
>  
> ”Everybody should be quiet near a little stream and listen."
> >From ’Open House for Butterflies’ by Ruth Krauss
>  
>  
> ___

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[George Fletcher]

I am strongly against requiring the AS to know about RS URIs and 
managing that based on a client request for a token. I've stated my 
reasons previously.


Happy to agree to disagree:)

Thanks,
George

On 3/10/16 10:17 PM, Phil Hunt (IDM) wrote:

Nat,

Agree with your points.

Regarding the last, I am not sure an AS should release the set of 
valid rs's. I think the returned data has to be limited somehow. Maybe 
by aud uri or maybe just a yes/no to a uri the client provides. This 
needs discussion.


Am worried about the resource side discovery and how much we can 
intrude here. It may have similar issues disclosing approved ASs.


Finally since we might not control rs discovery it may be possible 
that the discovery is fake. Maybe this is where something like 
software statements comes into play as it would at least prevent a 
mitm from changing the assertions in its discovery. It would not have 
the RS's private key and this signed statements might build trust.


Phil

On Mar 10, 2016, at 18:24, Nat Sakimura > wrote:



Phil,

Right. So what my conditional approvals (11 conditions in total) said 
was to drop the word "discovery" from everywhere. This is not a 
discovery spec. This is a configuration lookup spec as you correctly 
points out. So, I am with you here.


Also, my 2nd conditiion is essentially saying to drop section 3.

One thing that I overlooked and am with you is that we need to be 
able to express the AS-RS relationships. I have been preaching this 
in the other thread for so many times as you know so I thought I 
pointed it out, but missed apparently in my previous comment. So, I 
would add my 12th condition:


12. A way to express a list of valid RSs for this AS needs to be 
added to section 2.


Best,

Nat

2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) >:


I strongly oppose. 2 major issues.

This is not service discovery this is configuration lookup. The
client must have already discovered the oauth issuer uri and the
resource uri.

The objective was to provide a method to ensure the client has a
valid set of endpoints to prevent mitm of endpoints like the
token endpoint to the resource server.

The draft does not address the issue of a client being given a
bad endpoint for an rs. What we end up with is a promiscuous
authz service giving out tokens to an unwitting client.

Phil

On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov
> wrote:


+1 to move forward with these

On 10/03/16 17:35, Brian Campbell wrote:

+1

On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 

wrote:


I support this document being moved forward with these two changes:

- change name to “OAuth 2.0 Authorization Server Discovery Metadata” as
proposed by Brian and
- use the URI path suffix ’oauth-authorization-server’ instead of
’openid-configuration’ as proposed by Justin.


18 feb 2016 kl. 14:40 skrev Hannes Tschofenig 
:

Hi all,

This is a Last Call for comments on the  OAuth 2.0 Discovery

specification:

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

Since this document was only adopted recently we are running this last
call for **3 weeks**.

Please have your comments in no later than March 10th.

Ciao
Hannes & Derek

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

— Roland

”Everybody should be quiet near a little stream and listen."
 From ’Open House for Butterflies’ by Ruth Krauss


___
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




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



___
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] Working Group Last Call on OAuth 2.0 Discovery

[George Fletcher]

+1 for these changes and finishing the doc

On 3/10/16 10:45 AM, Nat Sakimura wrote:

+1 in proceeding with the following changes:

 1. Change name to "*OAuth 2.0 Authorization Server Metadata*",
aligning with section 2.
 2. Have the AS dictate the URI path suffix through link header in the
HEAD response to AS or OOB mechanism.
 3. Align the title of section 3 to section 2 so that it will be
"Obtaining Authorization Server Metadata"
 4. Align the title of section 3.1 to section 2 so that it will be
"Authorization Server Metadata Request"
 5. Align the title of section 3.2 to section 2 so that it will be
"Authorization Server Metadata Response"
 6. Align the title of section 3.3 to section 2 so that it will be
"Authorization Server Metadata Validation"
 7. Align the title of section 7.1 to section 2 so that it will be
"*OAuth Authorization Server Metadata Registry*"
 8. Change all the occurrence of "authorization server discovery
metadata" to "authorization server metadata".
 9. Change all the occurrence of "discovery metadata" to
"authorization server metadata" in a not-case-sensitive way but
preserving the original case.
10. Change "supporting discovery" to "supporting this specification".
11. Change abbrev="OAuth 2.0 Discovery" to abbrev="OAuth 2.0 AS Metadata"

Best,

Nat Sakimura

2016年3月10日(木) 22:05 Roland Hedberg >:


I support this document being moved forward with these two changes:

- change name to “OAuth 2.0 Authorization Server Discovery
Metadata” as proposed by Brian and
- use the URI path suffix ’oauth-authorization-server’ instead of
’openid-configuration’ as proposed by Justin.

> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig
>:
>
> Hi all,
>
> This is a Last Call for comments on the  OAuth 2.0 Discovery
specification:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>
> Since this document was only adopted recently we are running
this last
> call for **3 weeks**.
>
> Please have your comments in no later than March 10th.
>
> Ciao
> Hannes & Derek
>
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth

— Roland

”Everybody should be quiet near a little stream and listen."
>From ’Open House for Butterflies’ by Ruth Krauss

___
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


--
Chief Architect
Identity Services Engineering Work: george.fletc...@teamaol.com
AOL Inc.  AIM:  gffletch
Mobile: +1-703-462-3494   Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544   Photos: http://georgefletcher.photography

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

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Melvin Carvalho]

On 18 February 2016 at 14:40, Hannes Tschofenig 
wrote:

> Hi all,
>
> This is a Last Call for comments on the  OAuth 2.0 Discovery specification:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>
> Since this document was only adopted recently we are running this last
> call for **3 weeks**.
>
> Please have your comments in no later than March 10th.
>

Just finished reviewing this.  Since it's 1 day past the comments dealine,
I'll just leave some high level thoughts, based on how I may implement some
of this.  No need to respond.

1. I'd like to see a path supporting the increasingly popular w3c REC, JSON
LD.

2. General feedback I've had since the inception of webfinger was that it's
had decreasing adoption.  Perhaps an idea to remove reference.  Usage stats
would be interesting if public.

3. I feel the mandatory-ness of TLS/SSL slightly over the top.  I dont
think we are at HTTPS everywhere yet, and it's still a pain for the long
tail of developers.

Ill be interested to see this work in action.

>
>
> Ciao
> Hannes & Derek
>
>
> ___
> 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] Working Group Last Call on OAuth 2.0 Discovery

[Phil Hunt (IDM)]

Nat,

Agree with your points. 

Regarding the last, I am not sure an AS should release the set of valid rs's. I 
think the returned data has to be limited somehow. Maybe by aud uri or maybe 
just a yes/no to a uri the client provides. This needs discussion. 

Am worried about the resource side discovery and how much we can intrude here. 
It may have similar issues disclosing approved ASs. 

Finally since we might not control rs discovery it may be possible that the 
discovery is fake. Maybe this is where something like software statements comes 
into play as it would at least prevent a mitm from changing the assertions in 
its discovery. It would not have the RS's private key and this signed 
statements might build trust.  

Phil

> On Mar 10, 2016, at 18:24, Nat Sakimura  wrote:
> 
> Phil, 
> 
> Right. So what my conditional approvals (11 conditions in total) said was to 
> drop the word "discovery" from everywhere. This is not a discovery spec. This 
> is a configuration lookup spec as you correctly points out. So, I am with you 
> here. 
> 
> Also, my 2nd conditiion is essentially saying to drop section 3. 
> 
> One thing that I overlooked and am with you is that we need to be able to 
> express the AS-RS relationships. I have been preaching this in the other 
> thread for so many times as you know so I thought I pointed it out, but 
> missed apparently in my previous comment. So, I would add my 12th condition: 
> 
> 12. A way to express a list of valid RSs for this AS needs to be added to 
> section 2. 
> 
> Best, 
> 
> Nat
> 
> 2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) :
>> I strongly oppose. 2 major issues. 
>> 
>> This is not service discovery this is configuration lookup. The client must 
>> have already discovered the oauth issuer uri and the resource uri. 
>> 
>> The objective was to provide a method to ensure the client has a valid set 
>> of endpoints to prevent mitm of endpoints like the token endpoint to the 
>> resource server. 
>> 
>> The draft does not address the issue of a client being given a bad endpoint 
>> for an rs. What we end up with is a promiscuous authz service giving out 
>> tokens to an unwitting client. 
>> 
>> Phil
>> 
>>> On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov  
>>> wrote:
>>> 
>>> +1 to move forward with these
>>> 
 On 10/03/16 17:35, Brian Campbell wrote:
 +1
 
 On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 
 wrote:
 
> I support this document being moved forward with these two changes:
> 
> - change name to “OAuth 2.0 Authorization Server Discovery Metadata” as
> proposed by Brian and
> - use the URI path suffix ’oauth-authorization-server’ instead of
> ’openid-configuration’ as proposed by Justin.
> 
>> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig > :
>> 
>> Hi all,
>> 
>> This is a Last Call for comments on the  OAuth 2.0 Discovery
> specification:
>> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>> 
>> Since this document was only adopted recently we are running this last
>> call for **3 weeks**.
>> 
>> Please have your comments in no later than March 10th.
>> 
>> Ciao
>> Hannes & Derek
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> — Roland
> 
> ”Everybody should be quiet near a little stream and listen."
> From ’Open House for Butterflies’ by Ruth Krauss
> 
> 
> ___
> 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
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Anthony Nadalin]

The relationship between AS and RS need to be scoped to “does this RS accept 
tokens from this AS” as a list is too much information that could be used in 
the wrong way

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Thursday, March 10, 2016 6:25 PM
To: Phil Hunt (IDM) <phil.h...@oracle.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

Phil,

Right. So what my conditional approvals (11 conditions in total) said was to 
drop the word "discovery" from everywhere. This is not a discovery spec. This 
is a configuration lookup spec as you correctly points out. So, I am with you 
here.

Also, my 2nd conditiion is essentially saying to drop section 3.

One thing that I overlooked and am with you is that we need to be able to 
express the AS-RS relationships. I have been preaching this in the other thread 
for so many times as you know so I thought I pointed it out, but missed 
apparently in my previous comment. So, I would add my 12th condition:

12. A way to express a list of valid RSs for this AS needs to be added to 
section 2.

Best,

Nat

2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) 
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>>:
I strongly oppose. 2 major issues.

This is not service discovery this is configuration lookup. The client must 
have already discovered the oauth issuer uri and the resource uri.

The objective was to provide a method to ensure the client has a valid set of 
endpoints to prevent mitm of endpoints like the token endpoint to the resource 
server.

The draft does not address the issue of a client being given a bad endpoint for 
an rs. What we end up with is a promiscuous authz service giving out tokens to 
an unwitting client.

Phil

On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov 
<vladi...@connect2id.com<mailto:vladi...@connect2id.com>> wrote:
+1 to move forward with these
On 10/03/16 17:35, Brian Campbell wrote:

+1



On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 
<roland.hedb...@umu.se><mailto:roland.hedb...@umu.se>

wrote:



I support this document being moved forward with these two changes:



- change name to “OAuth 2.0 Authorization Server Discovery Metadata” as

proposed by Brian and

- use the URI path suffix ’oauth-authorization-server’ instead of

’openid-configuration’ as proposed by Justin.



18 feb 2016 kl. 14:40 skrev Hannes Tschofenig 
<hannes.tschofe...@gmx.net<mailto:hannes.tschofe...@gmx.net>

:



Hi all,



This is a Last Call for comments on the  OAuth 2.0 Discovery

specification:

https://tools.ietf.org/html/draft-ietf-oauth-discovery-01<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-discovery-01=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1=w3%2biiaWon81LJCU%2b2mCPRmA%2brECBHgqyRr0OgqiWSHU%3d>



Since this document was only adopted recently we are running this last

call for **3 weeks**.



Please have your comments in no later than March 10th.



Ciao

Hannes & Derek



___

OAuth mailing list

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

https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d>

— Roland



”Everybody should be quiet near a little stream and listen."

>From ’Open House for Butterflies’ by Ruth Krauss





___

OAuth mailing list

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

https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d>






___

OAuth mailing list

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

https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d>

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1=tNCikmXDBF

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Nat Sakimura]

Phil,

Right. So what my conditional approvals (11 conditions in total) said was
to drop the word "discovery" from everywhere. This is not a discovery spec.
This is a configuration lookup spec as you correctly points out. So, I am
with you here.

Also, my 2nd conditiion is essentially saying to drop section 3.

One thing that I overlooked and am with you is that we need to be able to
express the AS-RS relationships. I have been preaching this in the other
thread for so many times as you know so I thought I pointed it out, but
missed apparently in my previous comment. So, I would add my 12th
condition:

12. A way to express a list of valid RSs for this AS needs to be added to
section 2.

Best,

Nat

2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) :

> I strongly oppose. 2 major issues.
>
> This is not service discovery this is configuration lookup. The client
> must have already discovered the oauth issuer uri and the resource uri.
>
> The objective was to provide a method to ensure the client has a valid set
> of endpoints to prevent mitm of endpoints like the token endpoint to the
> resource server.
>
> The draft does not address the issue of a client being given a bad
> endpoint for an rs. What we end up with is a promiscuous authz service
> giving out tokens to an unwitting client.
>
> Phil
>
> On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov 
> wrote:
>
> +1 to move forward with these
>
> On 10/03/16 17:35, Brian Campbell wrote:
>
> +1
>
> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg  
> 
> wrote:
>
>
> I support this document being moved forward with these two changes:
>
> - change name to “OAuth 2.0 Authorization Server Discovery Metadata” as
> proposed by Brian and
> - use the URI path suffix ’oauth-authorization-server’ instead of
> ’openid-configuration’ as proposed by Justin.
>
>
> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig  :
>
> Hi all,
>
> This is a Last Call for comments on the  OAuth 2.0 Discovery
>
> specification:
>
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>
> Since this document was only adopted recently we are running this last
> call for **3 weeks**.
>
> Please have your comments in no later than March 10th.
>
> Ciao
> Hannes & Derek
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> — Roland
>
> ”Everybody should be quiet near a little stream and listen."
> From ’Open House for Butterflies’ by Ruth Krauss
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Phil Hunt (IDM)]

I strongly oppose. 2 major issues. 

This is not service discovery this is configuration lookup. The client must 
have already discovered the oauth issuer uri and the resource uri. 

The objective was to provide a method to ensure the client has a valid set of 
endpoints to prevent mitm of endpoints like the token endpoint to the resource 
server. 

The draft does not address the issue of a client being given a bad endpoint for 
an rs. What we end up with is a promiscuous authz service giving out tokens to 
an unwitting client. 

Phil

> On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov  wrote:
> 
> +1 to move forward with these
> 
>> On 10/03/16 17:35, Brian Campbell wrote:
>> +1
>> 
>> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 
>> wrote:
>> 
>>> I support this document being moved forward with these two changes:
>>> 
>>> - change name to “OAuth 2.0 Authorization Server Discovery Metadata” as
>>> proposed by Brian and
>>> - use the URI path suffix ’oauth-authorization-server’ instead of
>>> ’openid-configuration’ as proposed by Justin.
>>> 
 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig >> specification:
 https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
 
 Since this document was only adopted recently we are running this last
 call for **3 weeks**.
 
 Please have your comments in no later than March 10th.
 
 Ciao
 Hannes & Derek
 
 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth
>>> — Roland
>>> 
>>> ”Everybody should be quiet near a little stream and listen."
>>> From ’Open House for Butterflies’ by Ruth Krauss
>>> 
>>> 
>>> ___
>>> 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] Working Group Last Call on OAuth 2.0 Discovery

[William Denniss]

I support the document moving forward, and agree with the proposal to
rename it to "OAuth 2.0 Authorization Server Discovery Metadata".

Personally I was fine with re-using 'openid-configuration' for
compatibility, but I suppose it's not a big burden for everyone who is
already using that to setup an alias, as long as the AS metadata and OIDC
discovery specs remain compatible which I expect they will.

On Thu, Mar 10, 2016 at 5:04 AM, Roland Hedberg 
wrote:

> I support this document being moved forward with these two changes:
>
> - change name to “OAuth 2.0 Authorization Server Discovery Metadata” as
> proposed by Brian and
> - use the URI path suffix ’oauth-authorization-server’ instead of
> ’openid-configuration’ as proposed by Justin.
>
> > 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig  >:
> >
> > Hi all,
> >
> > This is a Last Call for comments on the  OAuth 2.0 Discovery
> specification:
> > https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
> >
> > Since this document was only adopted recently we are running this last
> > call for **3 weeks**.
> >
> > Please have your comments in no later than March 10th.
> >
> > Ciao
> > Hannes & Derek
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> — Roland
>
> ”Everybody should be quiet near a little stream and listen."
> From ’Open House for Butterflies’ by Ruth Krauss
>
>
> ___
> 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] Working Group Last Call on OAuth 2.0 Discovery

[Vladimir Dzhuvinov]

+1 to move forward with these

On 10/03/16 17:35, Brian Campbell wrote:
> +1
>
> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 
> wrote:
>
>> I support this document being moved forward with these two changes:
>>
>> - change name to “OAuth 2.0 Authorization Server Discovery Metadata” as
>> proposed by Brian and
>> - use the URI path suffix ’oauth-authorization-server’ instead of
>> ’openid-configuration’ as proposed by Justin.
>>
>>> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig >> :
>>>
>>> Hi all,
>>>
>>> This is a Last Call for comments on the  OAuth 2.0 Discovery
>> specification:
>>> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>>>
>>> Since this document was only adopted recently we are running this last
>>> call for **3 weeks**.
>>>
>>> Please have your comments in no later than March 10th.
>>>
>>> Ciao
>>> Hannes & Derek
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> — Roland
>>
>> ”Everybody should be quiet near a little stream and listen."
>> From ’Open House for Butterflies’ by Ruth Krauss
>>
>>
>> ___
>> 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] Working Group Last Call on OAuth 2.0 Discovery

[Nat Sakimura]

+1 in proceeding with the following changes:

   1. Change name to "*OAuth 2.0 Authorization Server Metadata*", aligning
   with section 2.
   2. Have the AS dictate the URI path suffix through link header in the
   HEAD response to AS or OOB mechanism.
   3. Align the title of section 3 to section 2 so that it will be "Obtaining
   Authorization Server Metadata"
   4. Align the title of section 3.1 to section 2 so that it will be
"Authorization
   Server Metadata Request"
   5. Align the title of section 3.2 to section 2 so that it will be
"Authorization
   Server Metadata Response"
   6. Align the title of section 3.3 to section 2 so that it will be
"Authorization
   Server Metadata Validation"
   7. Align the title of section 7.1 to section 2 so that it will be "*OAuth
   Authorization Server Metadata Registry*"
   8. Change all the occurrence of "authorization server discovery
   metadata" to "authorization server metadata".
   9. Change all the occurrence of "discovery metadata" to "authorization
   server metadata" in a not-case-sensitive way but preserving the original
   case.
   10. Change "supporting discovery" to "supporting this specification".
   11. Change abbrev="OAuth 2.0 Discovery" to abbrev="OAuth 2.0 AS Metadata"

Best,

Nat Sakimura

2016年3月10日(木) 22:05 Roland Hedberg :

> I support this document being moved forward with these two changes:
>
> - change name to “OAuth 2.0 Authorization Server Discovery Metadata” as
> proposed by Brian and
> - use the URI path suffix ’oauth-authorization-server’ instead of
> ’openid-configuration’ as proposed by Justin.
>
> > 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig  >:
> >
> > Hi all,
> >
> > This is a Last Call for comments on the  OAuth 2.0 Discovery
> specification:
> > https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
> >
> > Since this document was only adopted recently we are running this last
> > call for **3 weeks**.
> >
> > Please have your comments in no later than March 10th.
> >
> > Ciao
> > Hannes & Derek
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> — Roland
>
> ”Everybody should be quiet near a little stream and listen."
> From ’Open House for Butterflies’ by Ruth Krauss
>
> ___
> 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] Working Group Last Call on OAuth 2.0 Discovery

[Brian Campbell]

+1

On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg 
wrote:

> I support this document being moved forward with these two changes:
>
> - change name to “OAuth 2.0 Authorization Server Discovery Metadata” as
> proposed by Brian and
> - use the URI path suffix ’oauth-authorization-server’ instead of
> ’openid-configuration’ as proposed by Justin.
>
> > 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig  >:
> >
> > Hi all,
> >
> > This is a Last Call for comments on the  OAuth 2.0 Discovery
> specification:
> > https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
> >
> > Since this document was only adopted recently we are running this last
> > call for **3 weeks**.
> >
> > Please have your comments in no later than March 10th.
> >
> > Ciao
> > Hannes & Derek
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> — Roland
>
> ”Everybody should be quiet near a little stream and listen."
> From ’Open House for Butterflies’ by Ruth Krauss
>
>
> ___
> 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] Working Group Last Call on OAuth 2.0 Discovery

[Roland Hedberg]

I support this document being moved forward with these two changes:

- change name to “OAuth 2.0 Authorization Server Discovery Metadata” as 
proposed by Brian and
- use the URI path suffix ’oauth-authorization-server’ instead of 
’openid-configuration’ as proposed by Justin.

> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig :
> 
> Hi all,
> 
> This is a Last Call for comments on the  OAuth 2.0 Discovery specification:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
> 
> Since this document was only adopted recently we are running this last
> call for **3 weeks**.
> 
> Please have your comments in no later than March 10th.
> 
> Ciao
> Hannes & Derek
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

— Roland

”Everybody should be quiet near a little stream and listen."
From ’Open House for Butterflies’ by Ruth Krauss



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[Samuel Erdtman]

Thanks Mike!

Then lets take it to the next level :)

//Samuel

On Thu, Mar 10, 2016 at 12:33 PM, Mike Jones <michael.jo...@microsoft.com>
wrote:

> Thanks for your comments, Samuel.  Yes, you’re right that jwks_uri should
> be OPTIONAL, since not all use cases need keys.  Likewise,
> registration_endpoint should be OPTIONAL, rather than RECOMMENDED.
>
>
>
> The grant_type values are defined in OAuth Dynamic Client Registration
> [RFC 7591] and are identifiers for the grant type concept defined in RFC
> 6749.  They identify the grant types that can be used at the Token
> Endpoint.  The response_type concept is defined in RFC 6749, and identifies
> a response syntax from the authorization endpoint.  We can say more to
> differentiate these in the next draft.
>
>
>
> BTW, lest it be in doubt, I support this draft moving forward, with the
> name changed to “OAuth 2.0 Authorization Server Discovery” or “OAuth 2.0
> Authorization Server Discovery Metadata” – as discussed in the thread
> “OAuth 2.0 Discovery Location”.  I’m also open to introducing the 
> “/.well-known/oauth-authorization-server”
> identifier, as discussed in that thread.
>
>
>
>   -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Samuel
> Erdtman
> *Sent:* Wednesday, March 9, 2016 11:28 PM
> *To:* Hannes Tschofenig <hannes.tschofe...@gmx.net>
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>
>
>
> Hi,
>
>
>
> I sent a few comments two weeks ago that has not been explicitly commented
> on. (I might have sent them in the wrong way, if so sorry about that)
>
>
>
> https://mailarchive.ietf.org/arch/msg/oauth/Z0LCBuvFDCQTd4xfwoddlbC2P7w
>
>
>
> Most of the comments are minor but I would like to se
>
> jwks_uri to be changed from REQUIRED to OPTIONAL or RECOMMENDED
>
> and at least get a comment of the difference
> between response_types_supported and grant_types_supported
>
>
>
> Best regards
>
> //Samuel
>
>
>
>
>
>
>
>
>
> On Thu, Feb 18, 2016 at 2:40 PM, Hannes Tschofenig <
> hannes.tschofe...@gmx.net> wrote:
>
> Hi all,
>
> This is a Last Call for comments on the  OAuth 2.0 Discovery specification:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>
> Since this document was only adopted recently we are running this last
> call for **3 weeks**.
>
> Please have your comments in no later than March 10th.
>
> Ciao
> Hannes & Derek
>
>
> ___
> 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] Working Group Last Call on OAuth 2.0 Discovery

[Thomas Broyer]

I agree with Samuel's comments wrt jwks_uri and registration_endpoint; and
support the name change to “OAuth 2.0 Authorization Server Discovery
Metadata” (or possibly “OAuth 2.0 Authorization Server Discovery”; but I'd
rather narrow down the scope to only talk about metadata, without discovery
mechanism of that metadata; I won't fight for that though, it's just a
preference, not a strong opinion)

On Thu, Mar 10, 2016 at 12:33 PM Mike Jones <michael.jo...@microsoft.com>
wrote:

> Thanks for your comments, Samuel.  Yes, you’re right that jwks_uri should
> be OPTIONAL, since not all use cases need keys.  Likewise,
> registration_endpoint should be OPTIONAL, rather than RECOMMENDED.
>
>
>
> The grant_type values are defined in OAuth Dynamic Client Registration
> [RFC 7591] and are identifiers for the grant type concept defined in RFC
> 6749.  They identify the grant types that can be used at the Token
> Endpoint.  The response_type concept is defined in RFC 6749, and identifies
> a response syntax from the authorization endpoint.  We can say more to
> differentiate these in the next draft.
>
>
>
> BTW, lest it be in doubt, I support this draft moving forward, with the
> name changed to “OAuth 2.0 Authorization Server Discovery” or “OAuth 2.0
> Authorization Server Discovery Metadata” – as discussed in the thread
> “OAuth 2.0 Discovery Location”.  I’m also open to introducing the 
> “/.well-known/oauth-authorization-server”
> identifier, as discussed in that thread.
>
>
>
>   -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Samuel
> Erdtman
> *Sent:* Wednesday, March 9, 2016 11:28 PM
> *To:* Hannes Tschofenig <hannes.tschofe...@gmx.net>
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>
>
>
> Hi,
>
>
>
> I sent a few comments two weeks ago that has not been explicitly commented
> on. (I might have sent them in the wrong way, if so sorry about that)
>
>
>
> https://mailarchive.ietf.org/arch/msg/oauth/Z0LCBuvFDCQTd4xfwoddlbC2P7w
>
>
>
> Most of the comments are minor but I would like to se
>
> jwks_uri to be changed from REQUIRED to OPTIONAL or RECOMMENDED
>
> and at least get a comment of the difference
> between response_types_supported and grant_types_supported
>
>
>
> Best regards
>
> //Samuel
>
>
>
>
>
>
>
>
>
> On Thu, Feb 18, 2016 at 2:40 PM, Hannes Tschofenig <
> hannes.tschofe...@gmx.net> wrote:
>
> Hi all,
>
> This is a Last Call for comments on the  OAuth 2.0 Discovery specification:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>
> Since this document was only adopted recently we are running this last
> call for **3 weeks**.
>
> Please have your comments in no later than March 10th.
>
> Ciao
> Hannes & Derek
>
>
> ___
> 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] Working Group Last Call on OAuth 2.0 Discovery

[Mike Jones]

Thanks for your comments, Samuel.  Yes, you’re right that jwks_uri should be 
OPTIONAL, since not all use cases need keys.  Likewise, registration_endpoint 
should be OPTIONAL, rather than RECOMMENDED.

The grant_type values are defined in OAuth Dynamic Client Registration [RFC 
7591] and are identifiers for the grant type concept defined in RFC 6749.  They 
identify the grant types that can be used at the Token Endpoint.  The 
response_type concept is defined in RFC 6749, and identifies a response syntax 
from the authorization endpoint.  We can say more to differentiate these in the 
next draft.

BTW, lest it be in doubt, I support this draft moving forward, with the name 
changed to “OAuth 2.0 Authorization Server Discovery” or “OAuth 2.0 
Authorization Server Discovery Metadata” – as discussed in the thread “OAuth 
2.0 Discovery Location”.  I’m also open to introducing the 
“/.well-known/oauth-authorization-server” identifier, as discussed in that 
thread.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Samuel Erdtman
Sent: Wednesday, March 9, 2016 11:28 PM
To: Hannes Tschofenig <hannes.tschofe...@gmx.net>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

Hi,

I sent a few comments two weeks ago that has not been explicitly commented on. 
(I might have sent them in the wrong way, if so sorry about that)

https://mailarchive.ietf.org/arch/msg/oauth/Z0LCBuvFDCQTd4xfwoddlbC2P7w

Most of the comments are minor but I would like to se
jwks_uri to be changed from REQUIRED to OPTIONAL or RECOMMENDED
and at least get a comment of the difference between response_types_supported 
and grant_types_supported

Best regards
//Samuel




On Thu, Feb 18, 2016 at 2:40 PM, Hannes Tschofenig 
<hannes.tschofe...@gmx.net<mailto:hannes.tschofe...@gmx.net>> wrote:
Hi all,

This is a Last Call for comments on the  OAuth 2.0 Discovery specification:
https://tools.ietf.org/html/draft-ietf-oauth-discovery-01

Since this document was only adopted recently we are running this last
call for **3 weeks**.

Please have your comments in no later than March 10th.

Ciao
Hannes & Derek


___
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] Working Group Last Call on OAuth 2.0 Discovery

[Samuel Erdtman]

Hi,

I sent a few comments two weeks ago that has not been explicitly commented
on. (I might have sent them in the wrong way, if so sorry about that)

https://mailarchive.ietf.org/arch/msg/oauth/Z0LCBuvFDCQTd4xfwoddlbC2P7w

Most of the comments are minor but I would like to se
jwks_uri to be changed from REQUIRED to OPTIONAL or RECOMMENDED
and at least get a comment of the difference between response_types_supported
and grant_types_supported

Best regards
//Samuel




On Thu, Feb 18, 2016 at 2:40 PM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:

> Hi all,
>
> This is a Last Call for comments on the  OAuth 2.0 Discovery specification:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>
> Since this document was only adopted recently we are running this last
> call for **3 weeks**.
>
> Please have your comments in no later than March 10th.
>
> Ciao
> Hannes & Derek
>
>
> ___
> 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] Working Group Last Call on OAuth 2.0 Discovery

[Hannes Tschofenig]

Hi all,

This is a Last Call for comments on the  OAuth 2.0 Discovery specification:
https://tools.ietf.org/html/draft-ietf-oauth-discovery-01

Since this document was only adopted recently we are running this last
call for **3 weeks**.

Please have your comments in no later than March 10th.

Ciao
Hannes & Derek



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth