Subject: [OAUTH-WG] OAuth 2.0 Discovery Location

From: Justin Richer <[email-masked]>
Date: Fri, 19 Feb 2016 16:59:32 -0500

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

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

 — Justin

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 20 Feb 2016 06:28:06 +0200

+1

On 19/02/16 23:59, Justin Richer wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Samuel Erdtman <[email-masked]>
Date: Mon, 22 Feb 2016 07:20:40 +0100

Hi,

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

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

//Samuel

On Fri, Feb 19, 2016 at 10:59 PM, Justin Richer <[email-masked]> wrote:

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

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 22 Feb 2016 09:44:16 +0000

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

---

From: Justin Richer <[email-masked]>
Date: Mon, 22 Feb 2016 06:57:02 -0500

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

  -- Justin

On 2/22/2016 4:44 AM, Thomas Broyer wrote:
> I quite like the idea of draft-sakimura-oauth-meta if you really want 
> to do discovery, and leave it open to implementers / to other specs to 
> define a .well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any 
> URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a 
> basis for other metadata specs (like OpenID Connect).
> WWW-Authenticate response header, you have everything you need to 
> proceed (well, except if there are several ASs each with different 
> scopes; sounds like an edge-case to me though; maybe RFC6750 should 
> instead be updated with such a parameter such that an RS could return 
> several WWW-Authenticate: Bearer, each with its own "scope" and "duri" 
> value?)
>
> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     The newly-trimmed OAuth Discovery document is helpful and moving
>     in the right direction. It does, however, still have too many
>     vestiges of its OpenID Connect origins. One issue in particular
>     still really bothers me: the use of
>     “/.well-known/openid-configuration” in the discovery portion. Is
>     this an OAuth discovery document, or an OpenID Connect one? There
>     is absolutely no compelling reason to tie the URL to the OIDC
>     discovery mechanism.
>
>     I propose that we use “/.well-known/oauth-authorization-server” as
>     the default discovery location, and state that the document MAY
>     also be reachable from “/.well-known/openid-configuration” if the
>     server also provides OpenID Connect on the same domain. Other
>     applications SHOULD use the same parameter names to describe OAuth
>     endpoints and functions inside their service-specific discovery
>     document.
>
>      — Justin
>     [email-masked] <mailto:[email-masked]>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 24 Feb 2016 11:54:49 +0000

Hi Thomas,

inline:

2016年2月22日(月) 18:44 Thomas Broyer <[email-masked]>:

> I quite like the idea of draft-sakimura-oauth-meta if you really want to
> do discovery, and leave it open to implementers / to other specs to define
> a .well-known URL for "auto-configuration".
> WWW-Authenticate response header, you have everything you need to proceed

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

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

> WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)

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

Cheers,

Nat

---

From: Phil Hunt <[email-masked]>
Date: Wed, 24 Feb 2016 06:59:46 -0800

Nat,

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

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

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

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

Phil

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

> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <[email-masked]> wrote:
> 
> 
> Hi Thomas, 
> 
> inline: 
> 
> 2016年2月22日(月) 18:44 Thomas Broyer <[email-masked] <mailto:[email-masked]>>:
> I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect). 
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed 
> 
> In OAuth's case, the resource and the authorization server are usually tightly coupled. (Otherwise, you need another specs like UMA.) 
> So, the resource server should be able to tell either the location of the authz endpoint. In some trusted environment, the resource may as well return the location of the authz server configuration data. In these cases, you do not have to decide on what .well-known uri as you say. This frees up developers from configuration file location collisions etc. We should strive not to pollute the uri space as much as possible. 
>  
> (well, except if there are several ASs each with different scopes; sounds like an edge-case to me though; maybe RFC6750 should instead be updated with such a parameter such that an RS could return several WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
> 
> Yeah, I guess it is an edge case. I would rather like to see these authz servers to develop a trust framework under which they can agree on a single set of common scope parameter values. 
> 
> Cheers, 
> 
> Nat
> 
> 
> 
> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 24 Feb 2016 15:00:58 +0000

Hi Nat,

> set of common scope parameter values.

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

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 24 Feb 2016 15:51:49 +0000

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

2016年2月25日(木) 0:01 Thomas Broyer <[email-masked]>:

>>> (well, except if there are several ASs each with different scopes;
>>> sounds like an edge-case to me though; maybe RFC6750 should instead be
>>> updated with such a parameter such that an RS could return several

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 24 Feb 2016 16:12:41 +0000

Hi Phil,

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

The way oauth-meta works is that

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

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

Nat

2016年2月24日(水) 23:59 Phil Hunt <[email-masked]>:

> Nat,
>
> I’m not sure that having the resource server tell the client where its
> authorization server is secure by itself. The relationship between the
> Authorization Server and the Resource server need to be bound together in
> one of the discovery endpoints (the resource and/or the oauth service
> discovery).
>
> If a client discovers a fake resource server that is proxying for a real
> resource server the current discovery spec will not lead the client to
> understand it has the wrong resource server. Rather the fake resource
> service will just have a fake discovery service. The hacker can now
> intercept resource payload as well as tokens because they were able to
> convince the client to use the legit authorization service but use the
> token against the hackers proxy.
>
> The OAuth Discovery service needs to confirm to the client that the server
> is able to issue tokens for a stated resource endpoint.
>
> www.independentid.com
> [email-masked]

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 24 Feb 2016 08:39:15 -0800

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

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

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

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

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

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

Phil

> On Feb 24, 2016, at 08:12, Nat Sakimura <[email-masked]> wrote:
> 
> Hi Phil, 
> 
> Are you suggesting that the AS metadata should include the RS URIs? Currently, it does not, but it can be done, I guess. 
> 
> Even if there is a bad AS with a valid certs that proxies to the good RS, the client will not send the token there as the authz server will say that is not the place the client may want to send the token to. 
> 
> Nat
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 24 Feb 2016 17:53:31 +0000

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

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

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

                                                          -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Phil Hunt (IDM)
Sent: Wednesday, February 24, 2016 8:39 AM
To: Nat Sakimura <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

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

Phil

On Feb 24, 2016, at 08:12, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:
Hi Phil,

Nat

2016年2月24日(水) 23:59 Phil Hunt <[email-masked]<mailto:[email-masked]>>:
Nat,

Phil

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

On Feb 24, 2016, at 3:54 AM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:

Hi Thomas,

inline:

2016年2月22日(月) 18:44 Thomas Broyer <[email-masked]<mailto:[email-masked]>>:

Cheers,

Nat

On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.

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

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 24 Feb 2016 18:01:17 +0000

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

From: OAuth [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, February 24, 2016 9:54 AM
To: Phil Hunt (IDM) <[email-masked]>; Nat Sakimura <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

                                                          -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Phil Hunt (IDM)
Sent: Wednesday, February 24, 2016 8:39 AM
To: Nat Sakimura <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

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

Phil

Nat

Phil

@independentid
www.independentid.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.independentid.com&data=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MJWpFB12vTLB4ecKyYwlZLnRJInaNEw1MwlvtU26BPA%3d>
[email-masked]<mailto:[email-masked]>

Hi Thomas,

inline:

Cheers,

Nat

 — Justin
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=go1FhL%2bDa6yBSKmcs3wql71BskY7N7EJx40pZPJxtl4%3d>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=go1FhL%2bDa6yBSKmcs3wql71BskY7N7EJx40pZPJxtl4%3d>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7cf6a32a770d6c4f0aaad708d33d437cf9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=go1FhL%2bDa6yBSKmcs3wql71BskY7N7EJx40pZPJxtl4%3d>

---

From: Mike Jones <[email-masked]>
Date: Wed, 24 Feb 2016 18:22:04 +0000

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

                                                          -- Mike

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

To: Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>>; Nat Sakimura <[email-masked]<mailto:[email-masked]>>

                                                          -- Mike

Phil

Nat

Phil

@independentid

Hi Thomas,

inline:

Cheers,

Nat

 — Justin

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 24 Feb 2016 18:25:42 +0000

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

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

                                                          -- Mike

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

                                                          -- Mike

Phil

Nat

Phil

@independentid

Hi Thomas,

inline:

Cheers,

Nat

 — Justin

---

From: Mike Jones <[email-masked]>
Date: Wed, 24 Feb 2016 18:31:05 +0000

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

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

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

                                                          -- Mike

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

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

                                                          -- Mike

From: Anthony Nadalin

                                                          -- Mike

Phil

Nat

Phil

@independentid

Hi Thomas,

inline:

Cheers,

Nat

 — Justin

---

From: George Fletcher <[email-masked]>
Date: Wed, 24 Feb 2016 14:17:05 -0500

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

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

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

Thanks,
George

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

-- 
Chief Architect
Identity Services Engineering     Work: [email-masked]
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 24 Feb 2016 12:45:13 -0800

Mike

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

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

Phil

> On Feb 24, 2016, at 10:25, Anthony Nadalin <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 24 Feb 2016 21:09:04 +0000

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

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

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

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

                                                                -- Mike

From: Phil Hunt (IDM) [mailto:[email-masked]]
Sent: Wednesday, February 24, 2016 12:45 PM
To: Anthony Nadalin <[email-masked]>
Cc: Mike Jones <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Mike

Phil

On Feb 24, 2016, at 10:25, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:
Sure there is, it is as you have now made it far easier and the security considerations does not even address this

From: Mike Jones

                                                          -- Mike

From: Anthony Nadalin

                                                          -- Mike

Phil

Nat

Phil

@independentid

Hi Thomas,

inline:

Cheers,

Nat

 — Justin

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 24 Feb 2016 13:24:48 -0800

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

Phil

> On Feb 24, 2016, at 13:09, Mike Jones <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 24 Feb 2016 22:05:04 +0000

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

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

Thanks for the good discussion, Phil.

                                                                -- Mike

From: Phil Hunt (IDM) [mailto:[email-masked]]
Sent: Wednesday, February 24, 2016 1:25 PM
To: Mike Jones
Cc: <[email-masked]>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Phil

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

                                                                -- Mike

Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>

Mike

Phil

From: Mike Jones

                                                          -- Mike

From: Anthony Nadalin

                                                          -- Mike

Phil

Nat

Phil

@independentid

Hi Thomas,

inline:

Cheers,

Nat

 — Justin

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 24 Feb 2016 14:12:47 -0800

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

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

Phil

> On Feb 24, 2016, at 14:05, Mike Jones <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 24 Feb 2016 23:28:26 +0000

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

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

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

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

                                                                -- Mike

Sent: Wednesday, February 24, 2016 2:13 PM

Phil

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

                                                                -- Mike

From: Phil Hunt (IDM) [mailto:[email-masked]]
Sent: Wednesday, February 24, 2016 1:25 PM
To: Mike Jones
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Phil

                                                                -- Mike

Mike

Phil

From: Mike Jones

                                                          -- Mike

From: Anthony Nadalin

                                                          -- Mike

Phil

Nat

Phil

@independentid

Hi Thomas,

inline:

Cheers,

Nat

 — Justin

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 24 Feb 2016 15:52:17 -0800

Mike

Take a look at the assumptions you are making. 

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

Would ms azure allow custom arch?

Phil

> On Feb 24, 2016, at 15:28, Mike Jones <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 25 Feb 2016 00:04:12 +0000

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

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

                                                                -- Mike

From: Phil Hunt (IDM) [mailto:[email-masked]]
Sent: Wednesday, February 24, 2016 3:52 PM
To: Mike Jones
Cc: <[email-masked]>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Mike

Phil

On Feb 24, 2016, at 15:28, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
The UserInfo Endpoint path isn’t fixed and so has to be discovered.

                                                                -- Mike

To: Mike Jones <[email-masked]<mailto:[email-masked]>>

Phil

                                                                -- Mike

Phil

                                                                -- Mike

Mike

Phil

From: Mike Jones

                                                          -- Mike

From: Anthony Nadalin

                                                          -- Mike

Phil

Nat

Phil

@independentid

Hi Thomas,

inline:

Cheers,

Nat

 — Justin

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 24 Feb 2016 16:25:26 -0800

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

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

Phil

> On Feb 24, 2016, at 16:04, Mike Jones <[email-masked]> wrote:
>

---

From: "Manger, James" <[email-masked]>
Date: Thu, 25 Feb 2016 18:02:35 +1100

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

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

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

--
James Manger

From: OAuth [mailto:[email-masked]] On Behalf Of George Fletcher
Sent: Thursday, 25 February 2016 6:17 AM
To: Phil Hunt <[email-masked]>; Nat Sakimura <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

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

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

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

Thanks,
George

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 25 Feb 2016 09:22:37 +0200

+1

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

Cheers,
Vladimir

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 25 Feb 2016 10:58:52 +0200

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

Here are some example OIDC discovery docs:

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

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

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

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

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

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

Cheers,

Vladimir

-- 
Vladimir Dzhuvinov :: [email-masked]

---

From: "Donald F. Coffin" <[email-masked]>
Date: Thu, 25 Feb 2016 09:02:48 -0500

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

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

Phone:      (949) 636-8571

Email:        <mailto:[email-masked]>
[email-masked]

From: Vladimir Dzhuvinov [mailto:[email-masked]] 
Sent: Thursday, February 25, 2016 2:23 AM
To: [email-masked]
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

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

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

+1 

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

Cheers,
Vladimir

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

---

From: George Fletcher <[email-masked]>
Date: Thu, 25 Feb 2016 10:14:13 -0500

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

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

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

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

Thanks,
George

On 2/25/16 2:02 AM, Manger, James wrote:
>
> > I'm concerned that forcing the AS to know about all RS's endpoints 
> that will accept it's tokens creates a very brittle deployment 
> architecture
>
> doesn’t know where those credentials will work? That’s broken.
>
> draft-sakimura-oauth-meta suggests indicating this with 1 or more 
> “ruri” (resource URI) values in an HTTP Link header. A better approach 
> would be including a list of web origins in the token response beside 
> the access_token field.
>
> --
>
> James Manger
>
> *From:*OAuth [mailto:[email-masked]] *On Behalf Of *George 
> Fletcher
> *Sent:* Thursday, 25 February 2016 6:17 AM
> *To:* Phil Hunt <[email-masked]>; Nat Sakimura <[email-masked]>
> *Cc:* <[email-masked]> <[email-masked]>
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> I'm concerned that forcing the AS to know about all RS's endpoints 
> that will accept it's tokens creates a very brittle deployment 
> architecture. What if a RS moves to a new endpoint? All clients would 
> be required to get new tokens (if I understand correctly). And the RS 
> move would have to coordinate with the AS to make sure all the timing 
> is perfect in the switch over of endpoints.
>
> asks the user to authorize a token with a requested list of scopes. 
> The client can then send the token to the appropriate RS endpoint. The 
> RS will not authorize access unless the token has the required scopes.
>
> client is presenting the token. Trying to ensure the client doesn't 
> send the token to the wrong endpoint seems fraught with problems.
>
> Thanks,
> George
>

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 25 Feb 2016 15:16:37 +0000

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

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

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

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

Nat

2016年2月25日(木) 23:05 Donald F. Coffin <[email-masked]>:

> Button Connect My Data interface (North American Energy Standards Boards’
> (NAESB) Retail Energy Quadrant 21 (REQ.21) Standard (Energy Service
> Provider Interface – ESPI).  The Green Button Alliance is in the processing
> of updating the specification to use OAuth 2.0.  The industry OpenADE Task
> information be returned with the OAuth 2.0  Token Response that includes
> the URI of the resource to which the AT can be used.
>
>
>
> Best regards,
>
> Don
>
> Donald F. Coffin
>
> Founder/CTO
>
>
>
> REMI Networks
>
> 2335 Dunwoody Xing #E
>
> Dunwoody, GA 30338-8221
>
>
>
> Phone:      (949) 636-8571
>
> Email:       [email-masked]
>
>
>
> *From:* Vladimir Dzhuvinov [mailto:[email-masked]]
> *Sent:* Thursday, February 25, 2016 2:23 AM
> *To:* [email-masked]
>
>
> From: OAuth [mailto:[email-masked] <[email-masked]>] On Behalf Of George Fletcher
>
> To: Phil Hunt <[email-masked]> <[email-masked]>; Nat Sakimura <[email-masked]> <[email-masked]>
>
> Cc: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
>

---

From: George Fletcher <[email-masked]>
Date: Thu, 25 Feb 2016 10:25:31 -0500

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

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

Thanks,
George

On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
> This will appear more consistent with the current experience, and 
> OAuth does allow the token response JSON object to be extended with 
> additional members (as it's done in OpenID Connect already).
>
> Cheers,
> Vladimir
>
>> --
>> James Manger
>>
>> To: Phil Hunt<[email-masked]>; Nat Sakimura<[email-masked]>
>> Cc:<[email-masked]>  <[email-masked]>

---

From: George Fletcher <[email-masked]>
Date: Thu, 25 Feb 2016 10:27:53 -0500

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

Thanks,
George

On 2/25/16 10:25 AM, George Fletcher wrote:
> putting a "v2" or"v3" in it's API path... then a token issued for v2 
> of the API can not be sent to v3 of the API, because v3 wasn't wasn't

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 25 Feb 2016 17:52:08 +0200

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

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

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

On 25/02/16 17:27, George Fletcher wrote:
> However, identifying the actual endpoint seems overly complex when
> what is really trying to be protected is a token from being used where
> it shouldn't be (which is solved by Pop)
>
> Thanks,
> George
>
>> Interesting... this is not at all my current experience:) If a RS
>> goes from v2 of it's API to v3 and that RS uses the current standard
>> of putting a "v2" or"v3" in it's API path... then a token issued for
>> v2 of the API can not be sent to v3 of the API, because v3 wasn't
>> wasn't registered/deployed when the token was issued.
>>
>>>> The AS is issuing temporary credentials (access_tokens) to clients
>>>> but doesn’t know where those credentials will work? That’s broken.
>>>>
>>>> “ruri” (resource URI) values in an HTTP Link header. A better
>>>> approach would be including a list of web origins in the token
>>>> response beside the access_token field.
>>> +1
>>>
>>>> architecture. What if a RS moves to a new endpoint? All clients
>>>> would be required to get new tokens (if I understand correctly).
>>>> And the RS move would have to coordinate with the AS to make sure
>>>> all the timing is perfect in the switch over of endpoints.
>>>>
>>>> requires one or more scopes to access it's resources. The client
>>>> then asks the user to authorize a token with a requested list of
>>>> scopes. The client can then send the token to the appropriate RS
>>>> endpoint. The RS will not authorize access unless the token has the
>>>> required scopes.
>>>>
>>>> If the concern is that the client may accidentally send the token
>>>> to a "bad" RS which will then replay the token, then I'd rather use
>>>> a PoP mechanism because the point is that you want to ensure the
>>>> correct client is presenting the token. Trying to ensure the client
>>>> doesn't send the token to the wrong endpoint seems fraught with
>>>> problems.
>>>>
>>>> Thanks,
>>>> George
>>>>
>>>>

---

From: "Donald F. Coffin" <[email-masked]>
Date: Thu, 25 Feb 2016 10:57:58 -0500

Nat,

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

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

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

Phone:      (949) 636-8571

Email:        <mailto:[email-masked]> [email-masked]

From: Nat Sakimura [mailto:[email-masked]] 
Sent: Thursday, February 25, 2016 10:17 AM
To: Donald F. Coffin <[email-masked]>; Vladimir Dzhuvinov <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

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

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

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

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

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

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

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

Nat

2016年2月25日(木) 23:05 Donald F. Coffin <[email-masked] <mailto:[email-masked]> >:

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

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

Phone:      (949) 636-8571

Email:        <mailto:[email-masked]> [email-masked]

From: Vladimir Dzhuvinov [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, February 25, 2016 2:23 AM
To: [email-masked] <mailto:[email-masked]> 

 

 

+1 

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

Cheers,
Vladimir

--
James Manger
 
From: OAuth [mailto:[email-masked]] On Behalf Of George Fletcher
Sent: Thursday, 25 February 2016 6:17 AM
To: Phil Hunt  <mailto:[email-masked]> <[email-masked]>; Nat Sakimura  <mailto:[email-masked]> <[email-masked]>
Cc:  <mailto:[email-masked]> <[email-masked]>  <mailto:[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

 
 
Thanks,
George

---

From: Thomas Broyer <[email-masked]>
Date: Thu, 25 Feb 2016 17:08:36 +0000

On Thu, Feb 25, 2016 at 4:25 PM George Fletcher <[email-masked]> wrote:

> from v2 of it's API to v3 and that RS uses the current standard of putting
> a "v2" or"v3" in it's API path... then a token issued for v2 of the API can
> not be sent to v3 of the API, because v3 wasn't wasn't registered/deployed
> when the token was issued.
>

Add to that:

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

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

+1

---

From: Mike Jones <[email-masked]>
Date: Thu, 25 Feb 2016 19:10:16 +0000

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

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

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

In summary, which title do people prefer?

·       “OAuth 2.0 Discovery”

·       “OAuth 2.0 Authorization Server Discovery”

                                                          -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Vladimir Dzhuvinov
Sent: Thursday, February 25, 2016 12:59 AM
To: [email-masked]
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

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

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

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

Cheers,

Vladimir

Phil

On Feb 24, 2016, at 16:04, Mike Jones <[email-masked]><mailto:[email-masked]> wrote:

                                                                -- Mike

To: Mike Jones

Cc: <[email-masked]><mailto:[email-masked]>

Mike

Phil

On Feb 24, 2016, at 15:28, Mike Jones <[email-masked]><mailto:[email-masked]> wrote:

                                                                -- Mike

To: Mike Jones <[email-masked]><mailto:[email-masked]>

Cc: <[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

Phil

On Feb 24, 2016, at 14:05, Mike Jones <[email-masked]><mailto:[email-masked]> wrote:

                                                                -- Mike

To: Mike Jones

Cc: <[email-masked]><mailto:[email-masked]>

Phil

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

   "authorization_endpoint": "https://server.example.com/authorize"<https://server.example.com/authorize>,

   "token_endpoint": "https://server.example.com/token"<https://server.example.com/token>,

   "registration_endpoint": "https://server.example.com/register"<https://server.example.com/register>,

   "service_documentation": "http://server.example.com/service_documentation.html"<http://server.example.com/service_documentation.html>,

                                                                -- Mike

To: Anthony Nadalin <[email-masked]><mailto:[email-masked]>

Cc: Mike Jones <[email-masked]><mailto:[email-masked]>; <[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

Mike

Phil

On Feb 24, 2016, at 10:25, Anthony Nadalin <[email-masked]><mailto:[email-masked]> wrote:

From: Mike Jones

To: Anthony Nadalin <[email-masked]><mailto:[email-masked]>

Cc: <[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

                                                          -- Mike

From: Anthony Nadalin

To: Mike Jones <[email-masked]><mailto:[email-masked]>; Phil Hunt (IDM) <[email-masked]><mailto:[email-masked]>; Nat Sakimura <[email-masked]><mailto:[email-masked]>

Cc: <[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

To: Phil Hunt (IDM) <[email-masked]><mailto:[email-masked]>; Nat Sakimura <[email-masked]><mailto:[email-masked]>

Cc: <[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

                                                          -- Mike

To: Nat Sakimura <[email-masked]><mailto:[email-masked]>

Cc: <[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

Phil

On Feb 24, 2016, at 08:12, Nat Sakimura <[email-masked]><mailto:[email-masked]> wrote:

Hi Phil,

Nat

2016年2月24日(水) 23:59 Phil Hunt <[email-masked]><mailto:[email-masked]>:

Nat,

Phil

@independentid

On Feb 24, 2016, at 3:54 AM, Nat Sakimura <[email-masked]><mailto:[email-masked]> wrote:

Hi Thomas,

inline:

2016年2月22日(月) 18:44 Thomas Broyer <[email-masked]><mailto:[email-masked]>:

Cheers,

Nat

On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <[email-masked]><mailto:[email-masked]> wrote:

 — Justin

OAuth mailing list

OAuth mailing list

OAuth mailing list

OAuth mailing list

OAuth mailing list

--

Vladimir Dzhuvinov :: [email-masked]<mailto:[email-masked]>

---

From: George Fletcher <[email-masked]>
Date: Thu, 25 Feb 2016 14:20:13 -0500

+1 for “OAuth 2.0 Authorization Server Discovery”

On 2/25/16 2:10 PM, Mike Jones wrote:
>
> Thanks for your thoughts, Vladimir.  I’m increasingly inclined to 
> accept your suggestion to change the title from “OAuth 2.0 Discovery” 
> to “OAuth 2.0 Authorization Server Discovery”. While the abstract 
> already makes it clear that the scope of the document is AS discovery, 
> doing so in the title seems like it could help clarify things, given 
> that a lot of the discussion seems to be about resource discovery, 
> which is out of scope of the document.
>
> I’m not saying that resource discovery isn’t important – it is – but 
> unlike authorization server discovery, where there’s lots of existing 
> practice, including using the existing data format for describing 
> OAuth implementations that aren’t being used with OpenID Connect, 
> there’s no existing practice to standardize for resource discovery.  
> The time to create a standard for that seems to be after existing 
> practice has emerged.  It **might** or might not use new metadata 
> values in the AS discovery document, but that’s still to be 
> determined.  The one reason to leave the title as-is is that resource 
> discovery might end up involving extensions to this metadata format in 
> some cases.
>
> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 
> applies.  6749 is about the AS.  6750 is about the RS.  The discovery 
> document is about the AS.  We don’t yet have a specification or 
> existing practice for RS discovery, which would be the 6750 analogy.
>
> ·“OAuth 2.0 Discovery”
> ·“OAuth 2.0 Authorization Server Discovery”
>
> -- Mike
>
> *From:*OAuth [mailto:[email-masked]] *On Behalf Of *Vladimir 
> Dzhuvinov
> *Sent:* Thursday, February 25, 2016 12:59 AM
> *To:* [email-masked]
> deployment, compared to traditional online docs, which may be not be 
> up to date, or even missing. Very much like auto-generated Swagger and 
> JavaDocs.
>
> the spec is that it doesn't, and it shouldn't either. By staying 
> neutral on the topics of RS discovery and registering RPs with RSs. 
> And how one arrives at the ".well-known/...". I'm not even sure that 
> resource discovery should be a topic of this WG. Perhaps to this end, 
> and to prevent confusion that the spec is trying to do something more, 
> a more specific title would suit it better. E.g. "AS Discovery".
>
> Cheers,
>
> Vladimir
>
>
>
>         On Feb 24, 2016, at 16:04, Mike Jones<[email-masked]> <mailto:[email-masked]>  wrote:
>
>         Cc:<[email-masked]> <mailto:[email-masked]>
>
>         On Feb 24, 2016, at 15:28, Mike Jones<[email-masked]> <mailto:[email-masked]>  wrote:
>
>         To: Mike Jones<[email-masked]> <mailto:[email-masked]>
>
>         Cc:<[email-masked]> <mailto:[email-masked]>  <[email-masked]> <mailto:[email-masked]>
>
>         On Feb 24, 2016, at 14:05, Mike Jones<[email-masked]> <mailto:[email-masked]>  wrote:
>
>         In OpenID Connect, there’s a resource server called the UserInfo Endpoint that returns claims about the authenticated user as a JSON data structure.  Its location is published in OpenID Connect discovery metadata as the “userinfo_endpoint” metadata value, which is defined athttp://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.
>
>           
>
>         Cc:<[email-masked]> <mailto:[email-masked]>
>
>         On Feb 24, 2016, at 13:09, Mike Jones<[email-masked]> <mailto:[email-masked]>  wrote:
>
>             "authorization_endpoint":"https://server.example.com/authorize"
>         <https://server.example.com/authorize>,
>
>             "token_endpoint":"https://server.example.com/token"
>         <https://server.example.com/token>,
>
>             "registration_endpoint":"https://server.example.com/register"
>         <https://server.example.com/register>,
>
>             "service_documentation":"http://server.example.com/service_documentation.html"
>         <http://server.example.com/service_documentation.html>,
>
>           
>
>         To: Anthony Nadalin<[email-masked]> <mailto:[email-masked]>
>
>         Cc: Mike Jones<[email-masked]> <mailto:[email-masked]>;<[email-masked]> <mailto:[email-masked]>  <[email-masked]> <mailto:[email-masked]>
>
>         On Feb 24, 2016, at 10:25, Anthony Nadalin<[email-masked]> <mailto:[email-masked]>  wrote:
>
>         To: Anthony Nadalin<[email-masked]> <mailto:[email-masked]>
>
>         Cc:<[email-masked]> <mailto:[email-masked]>  <[email-masked]> <mailto:[email-masked]>
>
>         To: Mike Jones<[email-masked]> <mailto:[email-masked]>; Phil Hunt (IDM)<[email-masked]> <mailto:[email-masked]>; Nat Sakimura<[email-masked]> <mailto:[email-masked]>
>
>         Cc:<[email-masked]> <mailto:[email-masked]>  <[email-masked]> <mailto:[email-masked]>
>
>         To: Phil Hunt (IDM)<[email-masked]> <mailto:[email-masked]>; Nat Sakimura<[email-masked]> <mailto:[email-masked]>
>
>         Cc:<[email-masked]> <mailto:[email-masked]>  <[email-masked]> <mailto:[email-masked]>
>
>         To: Nat Sakimura<[email-masked]> <mailto:[email-masked]>
>
>         Cc:<[email-masked]> <mailto:[email-masked]>  <[email-masked]> <mailto:[email-masked]>
>
>         On Feb 24, 2016, at 08:12, Nat Sakimura<[email-masked]> <mailto:[email-masked]>  wrote:
>
>         Hi Phil,
>
>           
>
>         2016年2月24日(水) 23:59 Phil Hunt<[email-masked]> <mailto:[email-masked]>:
>
>         Nat,
>
>           
>
>         On Feb 24, 2016, at 3:54 AM, Nat Sakimura<[email-masked]> <mailto:[email-masked]>  wrote:
>
>           
>
>         Hi Thomas,
>
>           
>
>         inline:
>
>           
>
>         2016年2月22日(月) 18:44 Thomas Broyer<[email-masked]> <mailto:[email-masked]>:
>
>         On Fri, Feb 19, 2016 at 10:59 PM Justin Richer<[email-masked]> <mailto:[email-masked]>  wrote:
>
> Vladimir Dzhuvinov ::[email-masked] <mailto:[email-masked]>
>
>

---

From: "Donald F. Coffin" <[email-masked]>
Date: Thu, 25 Feb 2016 14:50:06 -0500

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

Phone:      (949) 636-8571

From: Mike Jones [mailto:[email-masked]] 
Sent: Thursday, February 25, 2016 2:10 PM
To: Vladimir Dzhuvinov <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

*         “OAuth 2.0 Discovery”

*         “OAuth 2.0 Authorization Server Discovery”

                                                          -- Mike

Cheers,

Vladimir

 
 
Phil

On Feb 24, 2016, at 16:04, Mike Jones  <mailto:[email-masked]> <[email-masked]> wrote:

 
                                                                -- Mike
 
From: Phil Hunt (IDM) [mailto:[email-masked]] 
Sent: Wednesday, February 24, 2016 3:52 PM
To: Mike Jones
Cc:  <mailto:[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
 
Mike

 
 
Phil
 
On Feb 24, 2016, at 15:28, Mike Jones  <mailto:[email-masked]> <[email-masked]> wrote:

 

                                                                -- Mike
 
To: Mike Jones  <mailto:[email-masked]> <[email-masked]>

 
Phil
 
On Feb 24, 2016, at 14:05, Mike Jones  <mailto:[email-masked]> <[email-masked]> wrote:

 
 
                                                                -- Mike
 
From: Phil Hunt (IDM) [mailto:[email-masked]] 
Sent: Wednesday, February 24, 2016 1:25 PM
To: Mike Jones
Cc:  <mailto:[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Phil
 
On Feb 24, 2016, at 13:09, Mike Jones  <mailto:[email-masked]> <[email-masked]> wrote:

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

                                                                -- Mike
 
From: Phil Hunt (IDM) [mailto:[email-masked]] 
Sent: Wednesday, February 24, 2016 12:45 PM
To: Anthony Nadalin  <mailto:[email-masked]> <[email-masked]>
Cc: Mike Jones  <mailto:[email-masked]> <[email-masked]>;  <mailto:[email-masked]> <[email-masked]>  <mailto:[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
 
Mike

 
Phil
 
On Feb 24, 2016, at 10:25, Anthony Nadalin  <mailto:[email-masked]> <[email-masked]> wrote:

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

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

 
To: Phil Hunt (IDM)  <mailto:[email-masked]> <[email-masked]>; Nat Sakimura  <mailto:[email-masked]> <[email-masked]>

 
 
                                                          -- Mike
 
To: Nat Sakimura  <mailto:[email-masked]> <[email-masked]>

 

 
 
Phil
 
On Feb 24, 2016, at 08:12, Nat Sakimura  <mailto:[email-masked]> <[email-masked]> wrote:
 
Hi Phil, 

 

Nat
 
2016年2月24日(水) 23:59 Phil Hunt  <mailto:[email-masked]> <[email-masked]>:
Nat,

 

Phil
 
@independentid

On Feb 24, 2016, at 3:54 AM, Nat Sakimura  <mailto:[email-masked]> <[email-masked]> wrote:

Hi Thomas, 
 
inline: 
 
2016年2月22日(月) 18:44 Thomas Broyer  <mailto:[email-masked]> <[email-masked]>:

 

Cheers, 
 
Nat

On Fri, Feb 19, 2016 at 10:59 PM Justin Richer  <mailto:[email-masked]> <[email-masked]> wrote:
The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.

 — Justin

-- 
Vladimir Dzhuvinov :: [email-masked] <mailto:[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Thu, 25 Feb 2016 20:57:32 +0100

Authorization server discovery.

> On Feb 25, 2016, at 8:10 PM, Mike Jones <[email-masked]> wrote:
> 
>   <>
> https://accounts.google.com/.well-known/openid-configuration <https://accounts.google.com/.well-known/openid-configuration>
> 
> https://www.paypalobjects.com/.well-known/openid-configuration <https://www.paypalobjects.com/.well-known/openid-configuration>
> 
> https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration <https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration>
> 
> 
> http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html <http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html>
> 
> 
> On Feb 24, 2016, at 16:04, Mike Jones <[email-masked]> <mailto:[email-masked]> wrote:
>  
> From: Phil Hunt (IDM) [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: <[email-masked]> <mailto:[email-masked]>
> On Feb 24, 2016, at 15:28, Mike Jones <[email-masked]> <mailto:[email-masked]> wrote:
>  
> From: Phil Hunt (IDM) [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Mike Jones <[email-masked]> <mailto:[email-masked]>
> Cc: <[email-masked]> <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
> On Feb 24, 2016, at 14:05, Mike Jones <[email-masked]> <mailto:[email-masked]> wrote:
>  
> In OpenID Connect, there’s a resource server called the UserInfo Endpoint that returns claims about the authenticated user as a JSON data structure.  Its location is published in OpenID Connect discovery metadata as the “userinfo_endpoint” metadata value, which is defined at http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata <http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata>.
>  
> From: Phil Hunt (IDM) [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: <[email-masked]> <mailto:[email-masked]>
> On Feb 24, 2016, at 13:09, Mike Jones <[email-masked]> <mailto:[email-masked]> wrote:
>  
>    "authorization_endpoint": "https://server.example.com/authorize" <https://server.example.com/authorize>,
>    "token_endpoint": "https://server.example.com/token" <https://server.example.com/token>,
>    "registration_endpoint": "https://server.example.com/register" <https://server.example.com/register>,
>    "service_documentation": "http://server.example.com/service_documentation.html" <http://server.example.com/service_documentation.html>,
>  
> From: Phil Hunt (IDM) [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Anthony Nadalin <[email-masked]> <mailto:[email-masked]>
> Cc: Mike Jones <[email-masked]> <mailto:[email-masked]>; <[email-masked]> <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
> On Feb 24, 2016, at 10:25, Anthony Nadalin <[email-masked]> <mailto:[email-masked]> wrote:
>  
> To: Anthony Nadalin <[email-masked]> <mailto:[email-masked]>
> Cc: <[email-masked]> <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
> To: Mike Jones <[email-masked]> <mailto:[email-masked]>; Phil Hunt (IDM) <[email-masked]> <mailto:[email-masked]>; Nat Sakimura <[email-masked]> <mailto:[email-masked]>
> Cc: <[email-masked]> <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Mike Jones
> To: Phil Hunt (IDM) <[email-masked]> <mailto:[email-masked]>; Nat Sakimura <[email-masked]> <mailto:[email-masked]>
> Cc: <[email-masked]> <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Phil Hunt (IDM)
> To: Nat Sakimura <[email-masked]> <mailto:[email-masked]>
> Cc: <[email-masked]> <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
> On Feb 24, 2016, at 08:12, Nat Sakimura <[email-masked]> <mailto:[email-masked]> wrote:
>  
> Hi Phil, 
>  
> 2016年2月24日(水) 23:59 Phil Hunt <[email-masked]> <mailto:[email-masked]>:
> Nat,
>  
> www.independentid.com <http://www.independentid.com/>
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <[email-masked]> <mailto:[email-masked]> wrote:
>  
>  
> Hi Thomas, 
>  
> inline: 
>  
> 2016年2月22日(月) 18:44 Thomas Broyer <[email-masked]> <mailto:[email-masked]>:
> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <[email-masked]> <mailto:[email-masked]> wrote:
> Vladimir Dzhuvinov :: [email-masked] <mailto:[email-masked]>_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: "Manger, James" <[email-masked]>
Date: Fri, 26 Feb 2016 15:04:57 +1100

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

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

--
James Manger

From: OAuth [mailto:[email-masked]] On Behalf Of George Fletcher
Sent: Friday, 26 February 2016 2:28 AM
To: Vladimir Dzhuvinov <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

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

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

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

Thanks,
George

Cheers,
Vladimir

--

James Manger

To: Phil Hunt <[email-masked]><mailto:[email-masked]>; Nat Sakimura <[email-masked]><mailto:[email-masked]>

Thanks,

George

OAuth mailing list

OAuth mailing list

OAuth mailing list

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 26 Feb 2016 04:08:28 +0000

I will include the origin in the next rev.

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

> You are right, George, that making the AS track /v2/… or /v3/… in RS paths
> is likely to be brittle — but tracking RS web origins is not too onerous.
>
>
>
> PoP has some nice security advantages over bearer tokens or passwords.
> However, it should still be possible to use the latter fairly safely — but
> it does require the issuer of credentials to indicate where they can be
> used.
>
>
>
> --
>
> James Manger
>
>
>
>
>
>
>
> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *George
> Fletcher
> *Sent:* Friday, 26 February 2016 2:28 AM
> *To:* Vladimir Dzhuvinov <[email-masked]>; [email-masked]
>
>
> That said, I'm not against the AS informing the client that the token can
> be used at the MailResource, ContactResource and MessagingResource to help
> the client know not to send the token to a BlogResource. However,
> identifying the actual endpoint seems overly complex when what is really
> trying to be protected is a token from being used where it shouldn't be
> (which is solved by Pop)
>
> Thanks,
> George
>

---

From: nov matake <[email-masked]>
Date: Fri, 26 Feb 2016 14:52:02 +0900

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

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

Thanks,
Nov

> On Feb 26, 2016, at 13:08, Nat Sakimura <[email-masked]> wrote:
> 
> 2016年2月26日(金) 13:05 Manger, James <[email-masked] <mailto:[email-masked]>>:
> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of George Fletcher
> To: Vladimir Dzhuvinov <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> 
> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of George Fletcher
> To: Phil Hunt <[email-masked]> <mailto:[email-masked]>; Nat Sakimura <[email-masked]> <mailto:[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Fri, 26 Feb 2016 10:06:42 +0100

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

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

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

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

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

John B.
> On Feb 26, 2016, at 6:52 AM, nov matake <[email-masked]> wrote:
> 
>> On Feb 26, 2016, at 13:08, Nat Sakimura <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: George Fletcher <[email-masked]>
Date: Fri, 26 Feb 2016 10:28:23 -0500

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

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

Thanks,
George

On 2/26/16 12:52 AM, nov matake wrote:
> It sounds like we want to return a list of available access tokens 
> “aud” values from AS config discovery endpoint (and also via 
> oauth-meta too?), doesn’t it?
>
> and RS config discovery endpoint will return acceptable access token 
> “iss” values, a list of every RS endpoints, required scopes per 
> endpoint etc.
>> 2016年2月26日(金) 13:05 Manger, James 
>> <[email-masked] 
>> <mailto:[email-masked]>>:
>>
>>     You are right, George, that making the AS track /v2/… or /v3/… in
>>     RS paths is likely to be brittle — but tracking RS web origins is
>>     not too onerous.
>>
>>     PoP has some nice security advantages over bearer tokens or
>>     passwords. However, it should still be possible to use the latter
>>     fairly safely — but it does require the issuer of credentials to
>>     indicate where they can be used.
>>
>>     --
>>
>>     James Manger
>>
>>     *From:*OAuth [mailto:[email-masked]
>>     <mailto:[email-masked]>] *On Behalf Of *George Fletcher
>>     *To:* Vladimir Dzhuvinov <[email-masked]
>>     <mailto:[email-masked]>>; [email-masked]
>>     <mailto:[email-masked]>
>>
>>
>>     That said, I'm not against the AS informing the client that the
>>     token can be used at the MailResource, ContactResource and
>>     MessagingResource to help the client know not to send the token
>>     to a BlogResource. However, identifying the actual endpoint seems
>>     overly complex when what is really trying to be protected is a
>>     token from being used where it shouldn't be (which is solved by Pop)
>>
>>     Thanks,
>>     George
>>
>>         Interesting... this is not at all my current experience:) If
>>         a RS goes from v2 of it's API to v3 and that RS uses the
>>         current standard of putting a "v2" or"v3" in it's API path...
>>         then a token issued for v2 of the API can not be sent to v3
>>         of the API, because v3 wasn't wasn't registered/deployed when
>>         the token was issued.
>>
>>         The constant management of scopes to URI endpoints seems like
>>         a complexity that will quickly get out of hand.
>>
>>         Thanks,
>>         George
>>
>>             This will appear more consistent with the current
>>             experience, and OAuth does allow the token response JSON
>>             object to be extended with additional members (as it's
>>             done in OpenID Connect already).
>>
>>             Cheers,
>>             Vladimir
>>
>>
>>                 --
>>
>>                 James Manger
>>
>>                   
>>
>>                 To: Phil Hunt<[email-masked]> <mailto:[email-masked]>; Nat Sakimura<[email-masked]> <mailto:[email-masked]>
>>

---

From: Justin Richer <[email-masked]>
Date: Fri, 26 Feb 2016 21:42:28 -0500

— Justin

> On Feb 25, 2016, at 2:20 PM, George Fletcher <[email-masked]> wrote:
> 
>> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Vladimir Dzhuvinov

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 27 Feb 2016 14:02:46 +0100

+1

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

---

From: Samuel Erdtman <[email-masked]>
Date: Sat, 27 Feb 2016 15:46:48 +0100

//Samuel

On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones <[email-masked]>
wrote:

> Thanks for your thoughts, Vladimir.  I’m increasingly inclined to accept
> your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth
> 2.0 Authorization Server Discovery”.  While the abstract already makes it
> clear that the scope of the document is AS discovery, doing so in the title
> seems like it could help clarify things, given that a lot of the discussion
> seems to be about resource discovery, which is out of scope of the document.
>
>
>
> practice, including using the existing data format for describing OAuth
> implementations that aren’t being used with OpenID Connect, there’s no
> existing practice to standardize for resource discovery.  The time to
> create a standard for that seems to be after existing practice has
> emerged.  It **might** or might not use new metadata values in the AS
> discovery document, but that’s still to be determined.  The one reason to
> leave the title as-is is that resource discovery might end up involving
> extensions to this metadata format in some cases.
>
>
>
> document is about the AS.  We don’t yet have a specification or existing
> practice for RS discovery, which would be the 6750 analogy.
>
>
>
> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *Vladimir
> Dzhuvinov
> integrators. Developers also tend to find it a more accurate and complete
> description of how to set up a client for a particular deployment, compared
> to traditional online docs, which may be not be up to date, or even
> missing. Very much like auto-generated Swagger and JavaDocs.
>
> Now, does that dictate any particular app architecture? My reading of the
> spec is that it doesn't, and it shouldn't either. By staying neutral on the
> topics of RS discovery and registering RPs with RSs. And how one arrives at
> the ".well-known/...". I'm not even sure that resource discovery should be
> a topic of this WG. Perhaps to this end, and to prevent confusion that the
> spec is trying to do something more, a more specific title would suit it
> better. E.g. "AS Discovery".
>
> Cheers,
>
> Vladimir
>
>
>
> On Feb 24, 2016, at 16:04, Mike Jones <[email-masked]> <[email-masked]> wrote:
>
>
>
>  From: Phil Hunt (IDM) [mailto:[email-masked] <[email-masked]>]
>
> On Feb 24, 2016, at 15:28, Mike Jones <[email-masked]> <[email-masked]> wrote:
>
>
>
>  From: Phil Hunt (IDM) [mailto:[email-masked] <[email-masked]>]
>
> To: Mike Jones <[email-masked]> <[email-masked]>
>
> On Feb 24, 2016, at 14:05, Mike Jones <[email-masked]> <[email-masked]> wrote:
>
>
>
>  From: Phil Hunt (IDM) [mailto:[email-masked] <[email-masked]>]
>
> On Feb 24, 2016, at 13:09, Mike Jones <[email-masked]> <[email-masked]> wrote:
>
>
>
>  From: Phil Hunt (IDM) [mailto:[email-masked] <[email-masked]>]
>
> To: Anthony Nadalin <[email-masked]> <[email-masked]>
>
> Cc: Mike Jones <[email-masked]> <[email-masked]>; <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
>
> On Feb 24, 2016, at 10:25, Anthony Nadalin <[email-masked]> <[email-masked]> wrote:
>
>
>
> To: Anthony Nadalin <[email-masked]> <[email-masked]>
>
> To: Mike Jones <[email-masked]> <[email-masked]>; Phil Hunt (IDM) <[email-masked]> <[email-masked]>; Nat Sakimura <[email-masked]> <[email-masked]>
>
>  From: OAuth [mailto:[email-masked] <[email-masked]>] On Behalf Of Mike Jones
>
> To: Phil Hunt (IDM) <[email-masked]> <[email-masked]>; Nat Sakimura <[email-masked]> <[email-masked]>
>
>  From: OAuth [mailto:[email-masked] <[email-masked]>] On Behalf Of Phil Hunt (IDM)
>
> To: Nat Sakimura <[email-masked]> <[email-masked]>
>
> On Feb 24, 2016, at 08:12, Nat Sakimura <[email-masked]> <[email-masked]> wrote:
>
>
>
> Hi Phil,
>
>
>
>  2016年2月24日(水) 23:59 Phil Hunt <[email-masked]> <[email-masked]>:
>
> Nat,
>
>  On Feb 24, 2016, at 3:54 AM, Nat Sakimura <[email-masked]> <[email-masked]> wrote:
>
>
>
> Hi Thomas,
>
>
>
> inline:
>
>
>
> 2016年2月22日(月) 18:44 Thomas Broyer <[email-masked]> <[email-masked]>:
>
> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <[email-masked]> <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Sat, 27 Feb 2016 17:48:21 +0000

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

                                                          Thanks all,
                                                          -- Mike

From: Samuel Erdtman [mailto:[email-masked]]
Sent: Saturday, February 27, 2016 6:47 AM
To: Mike Jones <[email-masked]>
Cc: Vladimir Dzhuvinov <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

//Samuel

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

•       “OAuth 2.0 Discovery”

•       “OAuth 2.0 Authorization Server Discovery”

                                                          -- Mike

From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Vladimir Dzhuvinov
Sent: Thursday, February 25, 2016 12:59 AM
To: [email-masked]<mailto:[email-masked]>

Cheers,

Vladimir

Phil

                                                                -- Mike

To: Mike Jones

Mike

Phil

                                                                -- Mike

Phil

                                                                -- Mike

To: Mike Jones

Phil

                                                                -- Mike

Mike

Phil

From: Mike Jones

                                                          -- Mike

From: Anthony Nadalin

                                                          -- Mike

Phil

Hi Phil,

Nat

Nat,

Phil

@independentid

Hi Thomas,

inline:

Cheers,

Nat

 — Justin

OAuth mailing list

OAuth mailing list

OAuth mailing list

OAuth mailing list

OAuth mailing list

--

---

From: Phil Hunt <[email-masked]>
Date: Sat, 27 Feb 2016 10:10:19 -0800

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

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

Resource Discovery

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

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

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

Phil

@independentid

> On Feb 27, 2016, at 6:46 AM, Samuel Erdtman <[email-masked]> wrote:
> 
> On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> So if res.example.evil.com <http://res.example.evil.com/> is not a valid resource endpoint for as.example.com <http://as.example.com/> the authz discovery should fail in some way (eg return nothing). 
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 27 Feb 2016 20:32:36 +0200

> Secure discovery of resource endpoints is out-of-scope of this specification. This specification assumes that the client has already securely discovered the correct resource endpoint and that the c…

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

+1

> Once again, I strongly urge the WG to actually include a method for the client to discovery that the oauth cliet has correctly discovered an authorization server that is willing and able to issue a…

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

Vladimir

---

From: Mike Jones <[email-masked]>
Date: Sat, 27 Feb 2016 18:38:13 +0000

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

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

                                                         -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Vladimir Dzhuvinov
Sent: Saturday, February 27, 2016 10:33 AM
To: [email-masked]
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Resource Discovery

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

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

Vladimir

Phil

@independentid

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

On Feb 27, 2016, at 6:46 AM, Samuel Erdtman <[email-masked]><mailto:[email-masked]> wrote:

//Samuel

On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>> wrote:

·       “OAuth 2.0 Discovery”

                                                          -- Mike

  <>

From: OAuth [mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>] On Behalf Of Vladimir Dzhuvinov

To: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

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

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

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

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

Cheers,

Vladimir

Phil

On Feb 24, 2016, at 16:04, Mike Jones <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> wrote:

                                                                -- Mike

From: Phil Hunt (IDM) [mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>]

To: Mike Jones

Cc: <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

Mike

Phil

On Feb 24, 2016, at 15:28, Mike Jones <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> wrote:

                                                                -- Mike

From: Phil Hunt (IDM) [mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>]

To: Mike Jones <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

Cc: <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

Phil

On Feb 24, 2016, at 14:05, Mike Jones <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> wrote:

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

                                                                -- Mike

From: Phil Hunt (IDM) [mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>]

To: Mike Jones

Cc: <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

Phil

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

   "authorization_endpoint": "https://server.example.com/authorize"<https://server.example.com/authorize> <https://server.example.com/authorize><https://server.example.com/authorize>,

   "token_endpoint": "https://server.example.com/token"<https://server.example.com/token> <https://server.example.com/token><https://server.example.com/token>,

   "registration_endpoint": "https://server.example.com/register"<https://server.example.com/register> <https://server.example.com/register><https://server.example.com/register>,

   "service_documentation": "http://server.example.com/service_documentation.html"<http://server.example.com/service_documentation.html> <http://server.example.com/service_documentation.html><http://server.example.com/service_documentation.html>,

                                                                -- Mike

From: Phil Hunt (IDM) [mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>]

To: Anthony Nadalin <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

Cc: Mike Jones <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>; <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

Mike

Phil

On Feb 24, 2016, at 10:25, Anthony Nadalin <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> wrote:

From: Mike Jones

To: Anthony Nadalin <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

Cc: <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

                                                          -- Mike

From: Anthony Nadalin

To: Mike Jones <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>; Phil Hunt (IDM) <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>; Nat Sakimura <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

Cc: <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

From: OAuth [mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>] On Behalf Of Mike Jones

To: Phil Hunt (IDM) <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>; Nat Sakimura <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

Cc: <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

                                                          -- Mike

From: OAuth [mailto:[email-masked] <mailto:[email-masked]><mailto:[email-masked]>] On Behalf Of Phil Hunt (IDM)

To: Nat Sakimura <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

Cc: <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

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

Phil

On Feb 24, 2016, at 08:12, Nat Sakimura <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> wrote:

Hi Phil,

Nat

2016年2月24日(水) 23:59 Phil Hunt <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>:

Nat,

Phil

@independentid

www.independentid.com<http://www.independentid.com> <http://www.independentid.com/><http://www.independentid.com/>

[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

On Feb 24, 2016, at 3:54 AM, Nat Sakimura <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> wrote:

Hi Thomas,

inline:

2016年2月22日(月) 18:44 Thomas Broyer <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>:

Cheers,

Nat

On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <[email-masked]><mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> wrote:

 — Justin

OAuth mailing list

[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

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

OAuth mailing list

[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

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

OAuth mailing list

[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

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

OAuth mailing list

[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

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

OAuth mailing list

[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

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

--

Vladimir Dzhuvinov :: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

OAuth mailing list

[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

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

OAuth mailing list

OAuth mailing list

---

From: Phil Hunt <[email-masked]>
Date: Sat, 27 Feb 2016 10:57:19 -0800

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

What I am suggesting is much simpler.

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

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

Phil

@independentid

> On Feb 27, 2016, at 10:38 AM, Mike Jones <[email-masked]> wrote:
> 
> www.independentid.com <http://www.independentid.com/> <http://www.independentid.com/> <http://www.independentid.com/>[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>  
>  
>  
>  
>  
> On Feb 27, 2016, at 6:46 AM, Samuel Erdtman <[email-masked]> <mailto:[email-masked]> wrote:
>  
> On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
> From: OAuth [mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>] On Behalf Of Vladimir Dzhuvinov
> To: [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>  
> https://accounts.google.com/.well-known/openid-configuration <https://accounts.google.com/.well-known/openid-configuration> <https://accounts.google.com/.well-known/openid-configuration> <https://accounts.google.com/.well-known/openid-configuration>
>  
> https://www.paypalobjects.com/.well-known/openid-configuration <https://www.paypalobjects.com/.well-known/openid-configuration> <https://www.paypalobjects.com/.well-known/openid-configuration> <https://www.paypalobjects.com/.well-known/openid-configuration>
>  
> https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration <https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration> <https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration> <https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration>
>  
>  
> http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html <http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html> <http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html> <http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html>
>  
>  
> On Feb 24, 2016, at 16:04, Mike Jones <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> wrote:
>  
> From: Phil Hunt (IDM) [mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>] 
> Cc: <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> On Feb 24, 2016, at 15:28, Mike Jones <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> wrote:
>  
> From: Phil Hunt (IDM) [mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>] 
> To: Mike Jones <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> Cc: <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> On Feb 24, 2016, at 14:05, Mike Jones <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> wrote:
>  
> In OpenID Connect, there’s a resource server called the UserInfo Endpoint that returns claims about the authenticated user as a JSON data structure.  Its location is published in OpenID Connect discovery metadata as the “userinfo_endpoint” metadata value, which is defined at http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata <http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata> <http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata> <http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata>.
>  
> From: Phil Hunt (IDM) [mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>] 
> Cc: <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> On Feb 24, 2016, at 13:09, Mike Jones <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> wrote:
>  
>    "authorization_endpoint": "https://server.example.com/authorize" <https://server.example.com/authorize> <https://server.example.com/authorize> <https://server.example.com/authorize>,
>    "token_endpoint": "https://server.example.com/token" <https://server.example.com/token> <https://server.example.com/token> <https://server.example.com/token>,
>    "registration_endpoint": "https://server.example.com/register" <https://server.example.com/register> <https://server.example.com/register> <https://server.example.com/register>,
>    "service_documentation": "http://server.example.com/service_documentation.html" <http://server.example.com/service_documentation.html> <http://server.example.com/service_documentation.html> <http://server.example.com/service_documentation.html>,
>  
> From: Phil Hunt (IDM) [mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>] 
> To: Anthony Nadalin <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> Cc: Mike Jones <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>; <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> On Feb 24, 2016, at 10:25, Anthony Nadalin <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> wrote:
>  
> To: Anthony Nadalin <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> Cc: <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> To: Mike Jones <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>; Phil Hunt (IDM) <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>; Nat Sakimura <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> Cc: <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> From: OAuth [mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>] On Behalf Of Mike Jones
> To: Phil Hunt (IDM) <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>; Nat Sakimura <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> Cc: <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> From: OAuth [mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>] On Behalf Of Phil Hunt (IDM)
> To: Nat Sakimura <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> Cc: <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> So if res.example.evil.com <http://res.example.evil.com/> <http://res.example.evil.com/> is not a valid resource endpoint for as.example.com <http://as.example.com/> <http://as.example.com/> the authz discovery should fail in some way (eg return nothing). 
>  
> On Feb 24, 2016, at 08:12, Nat Sakimura <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> wrote:
>  
> Hi Phil, 
>  
> 2016年2月24日(水) 23:59 Phil Hunt <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>:
> Nat,
>  
> www.independentid.com <http://www.independentid.com/> <http://www.independentid.com/> <http://www.independentid.com/>
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
>  
>  
>  
>  
>  
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> wrote:
>  
>  
> Hi Thomas, 
>  
> inline: 
>  
> 2016年2月22日(月) 18:44 Thomas Broyer <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>:
> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> wrote:
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth>
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth>
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth>
>  
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth>
>  
>  
>  
>  
>  
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth>
>  
>  
> -- 
> Vladimir Dzhuvinov :: [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth>
>  
>

---

From: Mike Jones <[email-masked]>
Date: Sat, 27 Feb 2016 19:09:49 +0000

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

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

                                                          -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Saturday, February 27, 2016 10:57 AM
To: Mike Jones <[email-masked]>
Cc: Vladimir Dzhuvinov <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Phil

@independentid

On Feb 27, 2016, at 10:38 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                         -- Mike

Resource Discovery

Vladimir

Phil

@independentid

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

//Samuel

·       “OAuth 2.0 Discovery”

                                                          -- Mike

  <>

Cheers,

Vladimir

Phil

                                                                -- Mike

To: Mike Jones

Mike

Phil

                                                                -- Mike

Phil

                                                                -- Mike

To: Mike Jones

Phil

                                                                -- Mike

Mike

Phil

From: Mike Jones

                                                          -- Mike

From: Anthony Nadalin

                                                          -- Mike

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

Phil

Hi Phil,

Nat

Nat,

Phil

@independentid

www.independentid.com<http://www.independentid.com/> <http://www.independentid.com/><http://www.independentid.com/>

Hi Thomas,

inline:

Cheers,

Nat

 — Justin

OAuth mailing list

OAuth mailing list

OAuth mailing list

OAuth mailing list

OAuth mailing list

--

OAuth mailing list

OAuth mailing list

OAuth mailing list

---

From: Brian Campbell <[email-masked]>
Date: Mon, 29 Feb 2016 15:34:59 -0700

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

But what about "OAuth 2.0 Authorization Server Metadata”?

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

On Sat, Feb 27, 2016 at 10:48 AM, Mike Jones <[email-masked]>
wrote:

> It’s clear that people want us to move to the name “OAuth 2.0
> Authorization Server Discovery”.  The editors will plan to make that
> change in the draft addressing Working Group Last Call comments.
>
>
>
>                                                           Thanks all,
>
>                                                           -- Mike
>
>
>
> *From:* Samuel Erdtman [mailto:[email-masked]]
> *Sent:* Saturday, February 27, 2016 6:47 AM
> *To:* Mike Jones <[email-masked]>
> *Cc:* Vladimir Dzhuvinov <[email-masked]>; [email-masked]
>
>              <[email-masked]>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 29 Feb 2016 15:41:17 -0700

+1

On Fri, Feb 19, 2016 at 9:28 PM, Vladimir Dzhuvinov <[email-masked]

---

From: Roland Hedberg <[email-masked]>
Date: Mon, 29 Feb 2016 16:36:25 -0700

+1 

> 29 feb. 2016 kl. 15:41 skrev Brian Campbell <[email-masked]>:
> 
> +1 
> 
> On Fri, Feb 19, 2016 at 9:28 PM, Vladimir Dzhuvinov <[email-masked] <mailto:[email-masked]>> wrote:
> +1
>