[OAUTH-WG] OAuth 2.0 Discovery Location

[Samuel Erdtman]

Hi,

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

//Samuel


2. Authorization Server Metadata

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

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

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

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

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

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


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

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



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



5. Compatibility Notes
”http://openid.net/specs/connect/1.0/issuer" is only used in this section,
maybe it should be removed?

[Samuel Erdtman]

Hi,

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

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

//Samuel

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

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

[Thomas Broyer]

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

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

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

[Justin Richer]

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

-- Justin

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

[Nat Sakimura]

Hi Thomas,

inline:

2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com>:

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

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

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

[Phil Hunt]

Nat,

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

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

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

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

Phil

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





> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <***@gmail.com> wrote:
>
>
> Hi Thomas,
>
> inline:
>
> 2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com <mailto:***@gmail.com>>:
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed
>
> Yup. That's one of the requirements to be RESTful, is it not?
>
> In OAuth's case, the resource and 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 <***@mit.edu <mailto:***@mit.edu>> wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.
>
> I propose that we use “/.well-known/oauth-authorization-server” as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration” if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.
>
> — Justin
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

[Nat Sakimura]

Hi Phil,

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

The way oauth-meta works is that

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

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

Nat

2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com>:

> Nat,
>
> I’m not sure that having the resource server tell the client where its
> authorization server is secure by itself. The relationship between the
> Authorization Server and the Resource server need to be bound together in
> one of the discovery endpoints (the resource and/or the oauth service
> discovery).
>
> If a client discovers a fake resource server that is proxying for a real
> resource server the current discovery spec will not lead the client to
> understand it has the wrong resource server. Rather the fake resource
> service will just have a fake discovery service. The hacker can now
> intercept resource payload as well as tokens because they were able to
> convince the client to use the legit authorization service but use the
> token against the hackers proxy.
>
> The OAuth Discovery service needs to confirm to the client that the server
> is able to issue tokens for a stated resource endpoint.
>
> This not only works in normal OAuth but should add security even to UMA
> situations.
>
> Phil
>
> @independentid
> www.independentid.com
> ***@oracle.com
>
>
>
>
>
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <***@gmail.com> wrote:
>
>
> Hi Thomas,
>
> inline:
>
> 2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com>:
>
>> Couldn't the document only describe the metadata?
>> I quite like the idea of draft-sakimura-oauth-meta if you really want to
>> do discovery, and leave it open to implementers / to other specs to define
>> a .well-known URL for "auto-configuration".
>> The metadata described here would then either be used as-is, at any URL,
>> returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for
>> other metadata specs (like OpenID Connect).
>>
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of
>> WWW-Authenticate response header, you have everything you need to proceed
>>
>>
>
> Yup. That's one of the requirements to be RESTful, is it not?
>
> In OAuth's case, the resource and 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 <***@mit.edu> wrote:
>>
>>> The newly-trimmed OAuth Discovery document is helpful and moving in the
>>> right direction. It does, however, still have too many vestiges of its
>>> OpenID Connect origins. One issue in particular still really bothers me:
>>> the use of “/.well-known/openid-configuration” in the discovery portion. Is
>>> this an OAuth discovery document, or an OpenID Connect one? There is
>>> absolutely no compelling reason to tie the URL to the OIDC discovery
>>> mechanism.
>>>
>>> I propose that we use “/.well-known/oauth-authorization-server” as the
>>> default discovery location, and state that the document MAY also be
>>> reachable from “/.well-known/openid-configuration” if the server also
>>> provides OpenID Connect on the same domain. Other applications SHOULD use
>>> the same parameter names to describe OAuth endpoints and functions inside
>>> their service-specific discovery document.
>>>
>>> — Justin
>>> _______________________________________________
>>> OAuth mailing list
>>> ***@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

[Phil Hunt (IDM)]

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

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

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

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

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

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

Phil

> On Feb 24, 2016, at 08:12, Nat Sakimura <***@gmail.com> wrote:
>
> Hi Phil,
>
> Are you suggesting that the AS metadata should include the RS URIs? Currently, it does not, but it can be done, I guess.
>
> The way oauth-meta works is that
>
> 1. RS tells the client where the AS is.
> 2. AS tells the client which RS endpoints the token can be used.
>
> Even if there is a bad AS with a valid certs that proxies to the good RS, the client will not send the token there as the authz server will say that is not the place the client may want to send the token to.
>
> Nat
>
> 2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com>:
>> Nat,
>>
>> I’m not sure that having the resource server tell the client where its authorization server is secure by itself. The relationship between the Authorization Server and the Resource server need to be bound together in one of the discovery endpoints (the resource and/or the oauth service discovery).
>>
>> If a client discovers a fake resource server that is proxying for a real resource server the current discovery spec will not lead the client to understand it has the wrong resource server. Rather the fake resource service will just have a fake discovery service. The hacker can now intercept resource payload as well as tokens because they were able to convince the client to use the legit authorization service but use the token against the hackers proxy.
>>
>> The OAuth Discovery service needs to confirm to the client that the server is able to issue tokens for a stated resource endpoint.
>>
>> This not only works in normal OAuth but should add security even to UMA situations.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com
>> ***@oracle.com
>>
>>
>>
>>
>>
>>> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <***@gmail.com> wrote:
>>>
>>>
>>> Hi Thomas,
>>>
>>> inline:
>>>
>>> 2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com>:
>>>> Couldn't the document only describe the metadata?
>>>> I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".
>>>> The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).
>>>> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed
>>>
>>> Yup. That's one of the requirements to be RESTful, is it not?
>>>
>>> In OAuth's case, the resource and 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 <***@mit.edu> wrote:
>>>>> The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.
>>>>>
>>>>> I propose that we use “/.well-known/oauth-authorization-server” as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration” if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.
>>>>>
>>>>> — Justin
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> ***@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> ***@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> ***@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth

[Mike Jones]

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

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

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

-- Mike

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

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

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

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

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

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

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

Phil

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

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

The way oauth-meta works is that

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

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

Nat

2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com<mailto:***@oracle.com>>:
Nat,

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

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

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

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

Phil

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




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


Hi Thomas,

inline:

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

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

In OAuth's case, the resource and 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 <***@mit.edu<mailto:***@mit.edu>> wrote:
The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.

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

— Justin
_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

[Anthony Nadalin]

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

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

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

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

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

-- Mike

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

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

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

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

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

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

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

Phil

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

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

The way oauth-meta works is that

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

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

Nat

2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com<mailto:***@oracle.com>>:
Nat,

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

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

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

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

Phil

@independentid
www.independentid.com<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>
***@oracle.com<mailto:***@oracle.com>




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


Hi Thomas,

inline:

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

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

In OAuth's case, the resource and 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 <***@mit.edu<mailto:***@mit.edu>> wrote:
The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.

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

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

[Mike Jones]

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

-- Mike

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

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

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

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

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

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

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

-- Mike

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

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

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

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

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

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

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

Phil

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

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

The way oauth-meta works is that

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

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

Nat

2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com<mailto:***@oracle.com>>:
Nat,

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

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

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

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

Phil

@independentid
www.independentid.com<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>
***@oracle.com<mailto:***@oracle.com>




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


Hi Thomas,

inline:

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

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

In OAuth's case, the resource and 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 <***@mit.edu<mailto:***@mit.edu>> wrote:
The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.

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

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

[Anthony Nadalin]

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

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

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

-- Mike

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

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

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

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

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

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

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

-- Mike

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

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

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

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

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

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

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

Phil

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

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

The way oauth-meta works is that

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

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

Nat

2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com<mailto:***@oracle.com>>:
Nat,

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

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

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

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

Phil

@independentid
www.independentid.com<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>
***@oracle.com<mailto:***@oracle.com>




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


Hi Thomas,

inline:

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

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

In OAuth's case, the resource and 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 <***@mit.edu<mailto:***@mit.edu>> wrote:
The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.

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

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

[Mike Jones]

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

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

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

-- Mike

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

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

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

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

-- Mike

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

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

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

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

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

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

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

-- Mike

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

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

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

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

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

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

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

Phil

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

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

The way oauth-meta works is that

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

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

Nat

2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com<mailto:***@oracle.com>>:
Nat,

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

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

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

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

Phil

@independentid
www.independentid.com<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>
***@oracle.com<mailto:***@oracle.com>




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


Hi Thomas,

inline:

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

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

In OAuth's case, the resource and 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 <***@mit.edu<mailto:***@mit.edu>> wrote:
The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.

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

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

[Phil Hunt (IDM)]

Mike

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

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

Phil

> On Feb 24, 2016, at 10:25, Anthony Nadalin <***@microsoft.com> wrote:
>
> Sure there is, it is as you have now made it far easier and the security considerations does not even address this
>
> From: Mike Jones
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin <***@microsoft.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> As we’d discussed in person, there’s no effective security difference between discovery information being published in an ad-hoc fashion on developer pages and it being published in a standard format. “Security by obscurity” adds no real security at all.
>
> -- Mike
>
> From: Anthony Nadalin
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones <***@microsoft.com>; Phil Hunt (IDM) <***@oracle.com>; Nat Sakimura <***@gmail.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> > The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
> That may be widely deployed for OIDC but not widely deployed for OAuth. There are some authentication mechanism discovery for endpoint that really should not be in an OAuth standard since it’s really not dealt with. Now that all this information is available it makes poking around the endpoint more focused for people that want to disrupt your endpoints, that is really not addressed in the security considerations section at all
>
> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Mike Jones
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Phil Hunt (IDM) <***@oracle.com>; Nat Sakimura <***@gmail.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
> None of Nat or John or I are suggesting that additional related functionality won’t be created. I’m sure it will be. Some applications will use WebFinger to locate the discovery metadata. Some will possibly use link headers. Some will possibly use application-specific .well-known values. I’m sure there’s other things I haven’t even thought about. All of these depend upon having a discovery metadata document format and none of them change it – other than possibly to register additional discovery metadata values.
>
> So by all means, the working group should continue discussing inventing possible new related mechanisms that make sense in some contexts. At the same time, we can finish standardizing the already widely deployed core functionality that all of these mechanisms will need.
>
> -- Mike
>
> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Phil Hunt (IDM)
> Sent: Wednesday, February 24, 2016 8:39 AM
> To: Nat Sakimura <***@gmail.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> I am suggesting that part of the discovery solution has to be the client indicating what resource endpoint it wants the oauth configuration data for.
>
> So if res.example.evil.com 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 <***@gmail.com> wrote:
>
> Hi Phil,
>
> Are you suggesting that the AS metadata should include the RS URIs? Currently, it does not, but it can be done, I guess.
>
> The way oauth-meta works is that
>
> 1. RS tells the client where the AS is.
> 2. AS tells the client which RS endpoints the token can be used.
>
> Even if there is a bad AS with a valid certs that proxies to the good RS, the client will not send the token there as the authz server will say that is not the place the client may want to send the token to.
>
> Nat
>
> 2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com>:
> Nat,
>
> I’m not sure that having the resource server tell the client where its authorization server is secure by itself. The relationship between the Authorization Server and the Resource server need to be bound together in one of the discovery endpoints (the resource and/or the oauth service discovery).
>
> If a client discovers a fake resource server that is proxying for a real resource server the current discovery spec will not lead the client to understand it has the wrong resource server. Rather the fake resource service will just have a fake discovery service. The hacker can now intercept resource payload as well as tokens because they were able to convince the client to use the legit authorization service but use the token against the hackers proxy.
>
> The OAuth Discovery service needs to confirm to the client that the server is able to issue tokens for a stated resource endpoint.
>
> This not only works in normal OAuth but should add security even to UMA situations.
>
> Phil
>
> @independentid
> www.independentid.com
> ***@oracle.com
>
>
>
>
>
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <***@gmail.com> wrote:
>
>
> Hi Thomas,
>
> inline:
>
> 2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com>:
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed
>
> Yup. That's one of the requirements to be RESTful, is it not?
>
> In OAuth's case, the resource and 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 <***@mit.edu> wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.
>
> I propose that we use “/.well-known/oauth-authorization-server” as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration” if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.
>
> — Justin
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

[Mike Jones]

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

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

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

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

-- Mike

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

Mike

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

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

Phil

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

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

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

-- Mike

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

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

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

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

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

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

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

-- Mike

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

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

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

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

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

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

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

Phil

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

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

The way oauth-meta works is that

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

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

Nat

2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com<mailto:***@oracle.com>>:
Nat,

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

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

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

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

Phil

@independentid
www.independentid.com<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>
***@oracle.com<mailto:***@oracle.com>




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


Hi Thomas,

inline:

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

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

In OAuth's case, the resource and 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 <***@mit.edu<mailto:***@mit.edu>> wrote:
The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.

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

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

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

[Phil Hunt (IDM)]

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

Phil

> On Feb 24, 2016, at 13:09, Mike Jones <***@microsoft.com> wrote:
>
> To the extent that generic OAuth 2.0 needs to publish some of the same information as OpenID Connect – which is built on generic OAuth 2.0 – it makes sense to publish that information using exactly the same syntax, since that syntax is already in widespread use. That what this draft accomplishes.
>
> There’s nothing Connect-specific about using metadata response values like:
>
> "authorization_endpoint": "https://server.example.com/authorize",
> "token_endpoint": "https://server.example.com/token",
> "token_endpoint_auth_methods_supported": ["client_secret_basic", "private_key_jwt"],
> "registration_endpoint": "https://server.example.com/register",
> "response_types_supported": ["code", "token"],
> "service_documentation": "http://server.example.com/service_documentation.html",
>
> Is there a reason that you would like the syntax for any of these or the other generally applicable OAuth 2.0 metadata values to be different? I don’t see any good reason for unnecessary differences to be introduced.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com]
> Sent: Wednesday, February 24, 2016 12:45 PM
> To: Anthony Nadalin <***@microsoft.com>
> Cc: Mike Jones <***@microsoft.com>; <***@ietf.org> <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Mike
>
> Publishing on dev pages does not work for software (esp open source) that is deployed both in enterprises and on PaaS cloud providers.
>
> The current draft is may codify current OIDC practice and be appropriate for oidc but it is not ready for generic oauth. There is no generic oauth experience at this time.
>
> Phil
>
> On Feb 24, 2016, at 10:25, Anthony Nadalin <***@microsoft.com> wrote:
>
> Sure there is, it is as you have now made it far easier and the security considerations does not even address this
>
> From: Mike Jones
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin <***@microsoft.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> As we’d discussed in person, there’s no effective security difference between discovery information being published in an ad-hoc fashion on developer pages and it being published in a standard format. “Security by obscurity” adds no real security at all.
>
> -- Mike
>
> From: Anthony Nadalin
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones <***@microsoft.com>; Phil Hunt (IDM) <***@oracle.com>; Nat Sakimura <***@gmail.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> > The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
> That may be widely deployed for OIDC but not widely deployed for OAuth. There are some authentication mechanism discovery for endpoint that really should not be in an OAuth standard since it’s really not dealt with. Now that all this information is available it makes poking around the endpoint more focused for people that want to disrupt your endpoints, that is really not addressed in the security considerations section at all
>
> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Mike Jones
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Phil Hunt (IDM) <***@oracle.com>; Nat Sakimura <***@gmail.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
> None of Nat or John or I are suggesting that additional related functionality won’t be created. I’m sure it will be. Some applications will use WebFinger to locate the discovery metadata. Some will possibly use link headers. Some will possibly use application-specific .well-known values. I’m sure there’s other things I haven’t even thought about. All of these depend upon having a discovery metadata document format and none of them change it – other than possibly to register additional discovery metadata values.
>
> So by all means, the working group should continue discussing inventing possible new related mechanisms that make sense in some contexts. At the same time, we can finish standardizing the already widely deployed core functionality that all of these mechanisms will need.
>
> -- Mike
>
> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Phil Hunt (IDM)
> Sent: Wednesday, February 24, 2016 8:39 AM
> To: Nat Sakimura <***@gmail.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> I am suggesting that part of the discovery solution has to be the client indicating what resource endpoint it wants the oauth configuration data for.
>
> So if res.example.evil.com 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 <***@gmail.com> wrote:
>
> Hi Phil,
>
> Are you suggesting that the AS metadata should include the RS URIs? Currently, it does not, but it can be done, I guess.
>
> The way oauth-meta works is that
>
> 1. RS tells the client where the AS is.
> 2. AS tells the client which RS endpoints the token can be used.
>
> Even if there is a bad AS with a valid certs that proxies to the good RS, the client will not send the token there as the authz server will say that is not the place the client may want to send the token to.
>
> Nat
>
> 2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com>:
> Nat,
>
> I’m not sure that having the resource server tell the client where its authorization server is secure by itself. The relationship between the Authorization Server and the Resource server need to be bound together in one of the discovery endpoints (the resource and/or the oauth service discovery).
>
> If a client discovers a fake resource server that is proxying for a real resource server the current discovery spec will not lead the client to understand it has the wrong resource server. Rather the fake resource service will just have a fake discovery service. The hacker can now intercept resource payload as well as tokens because they were able to convince the client to use the legit authorization service but use the token against the hackers proxy.
>
> The OAuth Discovery service needs to confirm to the client that the server is able to issue tokens for a stated resource endpoint.
>
> This not only works in normal OAuth but should add security even to UMA situations.
>
> Phil
>
> @independentid
> www.independentid.com
> ***@oracle.com
>
>
>
>
>
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <***@gmail.com> wrote:
>
>
> Hi Thomas,
>
> inline:
>
> 2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com>:
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed
>
> Yup. That's one of the requirements to be RESTful, is it not?
>
> In OAuth's case, the resource and 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 <***@mit.edu> wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.
>
> I propose that we use “/.well-known/oauth-authorization-server” as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration” if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.
>
> — Justin
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

[Mike Jones]

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

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

Thanks for the good discussion, Phil.

-- Mike

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

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

Phil

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

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

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

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

-- Mike

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

Mike

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

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

Phil

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

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

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

-- Mike

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

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

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

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

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

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

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

-- Mike

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

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

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

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

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

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

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

Phil

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

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

The way oauth-meta works is that

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

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

Nat

2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com<mailto:***@oracle.com>>:
Nat,

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

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

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

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

Phil

@independentid
www.independentid.com<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>
***@oracle.com<mailto:***@oracle.com>




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


Hi Thomas,

inline:

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

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

In OAuth's case, the resource and 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 <***@mit.edu<mailto:***@mit.edu>> wrote:
The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.

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

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

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

[Phil Hunt (IDM)]

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

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

Phil

> On Feb 24, 2016, at 14:05, Mike Jones <***@microsoft.com> wrote:
>
> In OpenID Connect, there’s a resource server called the UserInfo Endpoint that returns claims about the authenticated user as a JSON data structure. Its location is published in OpenID Connect discovery metadata as the “userinfo_endpoint” metadata value, which is defined at http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.
>
> We didn’t include the UserInfo Endpoint in the generic OAuth discovery spec since in OAuth, there are lots of possible relationships between authorization servers and resource servers and they needn’t be one-to-one, as is being actively discussed by the working group. For instance, see George Fletcher’s recent contribution.
>
> Thanks for the good discussion, Phil.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com]
> Sent: Wednesday, February 24, 2016 1:25 PM
> To: Mike Jones
> Cc: <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Where is the profile endpoint (oidc's resource server) published? (For the non OIDC people on the list).
>
> Phil
>
> On Feb 24, 2016, at 13:09, Mike Jones <***@microsoft.com> wrote:
>
> To the extent that generic OAuth 2.0 needs to publish some of the same information as OpenID Connect – which is built on generic OAuth 2.0 – it makes sense to publish that information using exactly the same syntax, since that syntax is already in widespread use. That what this draft accomplishes.
>
> There’s nothing Connect-specific about using metadata response values like:
>
> "authorization_endpoint": "https://server.example.com/authorize",
> "token_endpoint": "https://server.example.com/token",
> "token_endpoint_auth_methods_supported": ["client_secret_basic", "private_key_jwt"],
> "registration_endpoint": "https://server.example.com/register",
> "response_types_supported": ["code", "token"],
> "service_documentation": "http://server.example.com/service_documentation.html",
>
> Is there a reason that you would like the syntax for any of these or the other generally applicable OAuth 2.0 metadata values to be different? I don’t see any good reason for unnecessary differences to be introduced.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com]
> Sent: Wednesday, February 24, 2016 12:45 PM
> To: Anthony Nadalin <***@microsoft.com>
> Cc: Mike Jones <***@microsoft.com>; <***@ietf.org> <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Mike
>
> Publishing on dev pages does not work for software (esp open source) that is deployed both in enterprises and on PaaS cloud providers.
>
> The current draft is may codify current OIDC practice and be appropriate for oidc but it is not ready for generic oauth. There is no generic oauth experience at this time.
>
> Phil
>
> On Feb 24, 2016, at 10:25, Anthony Nadalin <***@microsoft.com> wrote:
>
> Sure there is, it is as you have now made it far easier and the security considerations does not even address this
>
> From: Mike Jones
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin <***@microsoft.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> As we’d discussed in person, there’s no effective security difference between discovery information being published in an ad-hoc fashion on developer pages and it being published in a standard format. “Security by obscurity” adds no real security at all.
>
> -- Mike
>
> From: Anthony Nadalin
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones <***@microsoft.com>; Phil Hunt (IDM) <***@oracle.com>; Nat Sakimura <***@gmail.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> > The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
> That may be widely deployed for OIDC but not widely deployed for OAuth. There are some authentication mechanism discovery for endpoint that really should not be in an OAuth standard since it’s really not dealt with. Now that all this information is available it makes poking around the endpoint more focused for people that want to disrupt your endpoints, that is really not addressed in the security considerations section at all
>
> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Mike Jones
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Phil Hunt (IDM) <***@oracle.com>; Nat Sakimura <***@gmail.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
> None of Nat or John or I are suggesting that additional related functionality won’t be created. I’m sure it will be. Some applications will use WebFinger to locate the discovery metadata. Some will possibly use link headers. Some will possibly use application-specific .well-known values. I’m sure there’s other things I haven’t even thought about. All of these depend upon having a discovery metadata document format and none of them change it – other than possibly to register additional discovery metadata values.
>
> So by all means, the working group should continue discussing inventing possible new related mechanisms that make sense in some contexts. At the same time, we can finish standardizing the already widely deployed core functionality that all of these mechanisms will need.
>
> -- Mike
>
> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Phil Hunt (IDM)
> Sent: Wednesday, February 24, 2016 8:39 AM
> To: Nat Sakimura <***@gmail.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> I am suggesting that part of the discovery solution has to be the client indicating what resource endpoint it wants the oauth configuration data for.
>
> So if res.example.evil.com 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 <***@gmail.com> wrote:
>
> Hi Phil,
>
> Are you suggesting that the AS metadata should include the RS URIs? Currently, it does not, but it can be done, I guess.
>
> The way oauth-meta works is that
>
> 1. RS tells the client where the AS is.
> 2. AS tells the client which RS endpoints the token can be used.
>
> Even if there is a bad AS with a valid certs that proxies to the good RS, the client will not send the token there as the authz server will say that is not the place the client may want to send the token to.
>
> Nat
>
> 2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com>:
> Nat,
>
> I’m not sure that having the resource server tell the client where its authorization server is secure by itself. The relationship between the Authorization Server and the Resource server need to be bound together in one of the discovery endpoints (the resource and/or the oauth service discovery).
>
> If a client discovers a fake resource server that is proxying for a real resource server the current discovery spec will not lead the client to understand it has the wrong resource server. Rather the fake resource service will just have a fake discovery service. The hacker can now intercept resource payload as well as tokens because they were able to convince the client to use the legit authorization service but use the token against the hackers proxy.
>
> The OAuth Discovery service needs to confirm to the client that the server is able to issue tokens for a stated resource endpoint.
>
> This not only works in normal OAuth but should add security even to UMA situations.
>
> Phil
>
> @independentid
> www.independentid.com
> ***@oracle.com
>
>
>
>
>
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <***@gmail.com> wrote:
>
>
> Hi Thomas,
>
> inline:
>
> 2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com>:
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed
>
> Yup. That's one of the requirements to be RESTful, is it not?
>
> In OAuth's case, the resource and 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 <***@mit.edu> wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.
>
> I propose that we use “/.well-known/oauth-authorization-server” as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration” if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.
>
> — Justin
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

[Mike Jones]

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

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

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

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

-- Mike

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

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

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

Phil

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

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

Thanks for the good discussion, Phil.

-- Mike

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

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

Phil

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

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

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

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

-- Mike

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

Mike

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

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

Phil

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

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

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

-- Mike

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

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

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

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

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

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

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

-- Mike

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

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

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

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

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

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

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

Phil

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

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

The way oauth-meta works is that

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

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

Nat

2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com<mailto:***@oracle.com>>:
Nat,

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

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

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

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

Phil

@independentid
www.independentid.com<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>
***@oracle.com<mailto:***@oracle.com>




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


Hi Thomas,

inline:

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

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

In OAuth's case, the resource and 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 <***@mit.edu<mailto:***@mit.edu>> wrote:
The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.

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

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

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

[Phil Hunt (IDM)]

Mike

Take a look at the assumptions you are making.

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

Would ms azure allow custom arch?

Phil

> On Feb 24, 2016, at 15:28, Mike Jones <***@microsoft.com> wrote:
>
> The UserInfo Endpoint path isn’t fixed and so has to be discovered.
>
> I agree that for some OAuth profiles, one or more resource servers will have to be discovered starting from the authorization server. Working group members have also described wanting to discover authorization servers starting from resource servers. There isn’t a standard practice for any of this, which is why it’s intentionally left out of the current specification.
>
> Once the IANA OAuth Discovery Metadata Registry has been established, which will happen after the current specification has been approved, it will be easy for subsequent specifications to document existing practice for different OAuth profiles and register discovery metadata values supporting them. Some of those values will likely define ways to discover resource servers, when applicable.
>
> But first, we need to finish the existing spec, so that the registry enabling these extensions gets established in the first place.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com]
> Sent: Wednesday, February 24, 2016 2:13 PM
> To: Mike Jones <***@microsoft.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Yup. And because there many relations the client mist be able to discover it. The client does not know if the res server is legit.
>
> The userinfo is always fix and so u dont need discovery.
>
> Phil
>
> On Feb 24, 2016, at 14:05, Mike Jones <***@microsoft.com> wrote:
>
> In OpenID Connect, there’s a resource server called the UserInfo Endpoint that returns claims about the authenticated user as a JSON data structure. Its location is published in OpenID Connect discovery metadata as the “userinfo_endpoint” metadata value, which is defined at http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.
>
> We didn’t include the UserInfo Endpoint in the generic OAuth discovery spec since in OAuth, there are lots of possible relationships between authorization servers and resource servers and they needn’t be one-to-one, as is being actively discussed by the working group. For instance, see George Fletcher’s recent contribution.
>
> Thanks for the good discussion, Phil.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com]
> Sent: Wednesday, February 24, 2016 1:25 PM
> To: Mike Jones
> Cc: <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Where is the profile endpoint (oidc's resource server) published? (For the non OIDC people on the list).
>
> Phil
>
> On Feb 24, 2016, at 13:09, Mike Jones <***@microsoft.com> wrote:
>
> To the extent that generic OAuth 2.0 needs to publish some of the same information as OpenID Connect – which is built on generic OAuth 2.0 – it makes sense to publish that information using exactly the same syntax, since that syntax is already in widespread use. That what this draft accomplishes.
>
> There’s nothing Connect-specific about using metadata response values like:
>
> "authorization_endpoint": "https://server.example.com/authorize",
> "token_endpoint": "https://server.example.com/token",
> "token_endpoint_auth_methods_supported": ["client_secret_basic", "private_key_jwt"],
> "registration_endpoint": "https://server.example.com/register",
> "response_types_supported": ["code", "token"],
> "service_documentation": "http://server.example.com/service_documentation.html",
>
> Is there a reason that you would like the syntax for any of these or the other generally applicable OAuth 2.0 metadata values to be different? I don’t see any good reason for unnecessary differences to be introduced.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com]
> Sent: Wednesday, February 24, 2016 12:45 PM
> To: Anthony Nadalin <***@microsoft.com>
> Cc: Mike Jones <***@microsoft.com>; <***@ietf.org> <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Mike
>
> Publishing on dev pages does not work for software (esp open source) that is deployed both in enterprises and on PaaS cloud providers.
>
> The current draft is may codify current OIDC practice and be appropriate for oidc but it is not ready for generic oauth. There is no generic oauth experience at this time.
>
> Phil
>
> On Feb 24, 2016, at 10:25, Anthony Nadalin <***@microsoft.com> wrote:
>
> Sure there is, it is as you have now made it far easier and the security considerations does not even address this
>
> From: Mike Jones
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin <***@microsoft.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> As we’d discussed in person, there’s no effective security difference between discovery information being published in an ad-hoc fashion on developer pages and it being published in a standard format. “Security by obscurity” adds no real security at all.
>
> -- Mike
>
> From: Anthony Nadalin
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones <***@microsoft.com>; Phil Hunt (IDM) <***@oracle.com>; Nat Sakimura <***@gmail.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> > The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
> That may be widely deployed for OIDC but not widely deployed for OAuth. There are some authentication mechanism discovery for endpoint that really should not be in an OAuth standard since it’s really not dealt with. Now that all this information is available it makes poking around the endpoint more focused for people that want to disrupt your endpoints, that is really not addressed in the security considerations section at all
>
> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Mike Jones
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Phil Hunt (IDM) <***@oracle.com>; Nat Sakimura <***@gmail.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
> None of Nat or John or I are suggesting that additional related functionality won’t be created. I’m sure it will be. Some applications will use WebFinger to locate the discovery metadata. Some will possibly use link headers. Some will possibly use application-specific .well-known values. I’m sure there’s other things I haven’t even thought about. All of these depend upon having a discovery metadata document format and none of them change it – other than possibly to register additional discovery metadata values.
>
> So by all means, the working group should continue discussing inventing possible new related mechanisms that make sense in some contexts. At the same time, we can finish standardizing the already widely deployed core functionality that all of these mechanisms will need.
>
> -- Mike
>
> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Phil Hunt (IDM)
> Sent: Wednesday, February 24, 2016 8:39 AM
> To: Nat Sakimura <***@gmail.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> I am suggesting that part of the discovery solution has to be the client indicating what resource endpoint it wants the oauth configuration data for.
>
> So if res.example.evil.com 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 <***@gmail.com> wrote:
>
> Hi Phil,
>
> Are you suggesting that the AS metadata should include the RS URIs? Currently, it does not, but it can be done, I guess.
>
> The way oauth-meta works is that
>
> 1. RS tells the client where the AS is.
> 2. AS tells the client which RS endpoints the token can be used.
>
> Even if there is a bad AS with a valid certs that proxies to the good RS, the client will not send the token there as the authz server will say that is not the place the client may want to send the token to.
>
> Nat
>
> 2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com>:
> Nat,
>
> I’m not sure that having the resource server tell the client where its authorization server is secure by itself. The relationship between the Authorization Server and the Resource server need to be bound together in one of the discovery endpoints (the resource and/or the oauth service discovery).
>
> If a client discovers a fake resource server that is proxying for a real resource server the current discovery spec will not lead the client to understand it has the wrong resource server. Rather the fake resource service will just have a fake discovery service. The hacker can now intercept resource payload as well as tokens because they were able to convince the client to use the legit authorization service but use the token against the hackers proxy.
>
> The OAuth Discovery service needs to confirm to the client that the server is able to issue tokens for a stated resource endpoint.
>
> This not only works in normal OAuth but should add security even to UMA situations.
>
> Phil
>
> @independentid
> www.independentid.com
> ***@oracle.com
>
>
>
>
>
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <***@gmail.com> wrote:
>
>
> Hi Thomas,
>
> inline:
>
> 2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com>:
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed
>
> Yup. That's one of the requirements to be RESTful, is it not?
>
> In OAuth's case, the resource and 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 <***@mit.edu> wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.
>
> I propose that we use “/.well-known/oauth-authorization-server” as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration” if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.
>
> — Justin
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

[Mike Jones]

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

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

-- Mike

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

Mike

Take a look at the assumptions you are making.

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

Would ms azure allow custom arch?

Phil

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

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

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

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

-- Mike

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

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

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

Phil

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

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

Thanks for the good discussion, Phil.

-- Mike

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

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

Phil

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

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

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

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

-- Mike

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

Mike

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

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

Phil

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

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

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

-- Mike

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

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

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

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

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

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

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

-- Mike

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

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

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

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

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

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

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

Phil

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

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

The way oauth-meta works is that

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

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

Nat

2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com<mailto:***@oracle.com>>:
Nat,

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

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

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

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

Phil

@independentid
www.independentid.com<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>
***@oracle.com<mailto:***@oracle.com>




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


Hi Thomas,

inline:

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

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

In OAuth's case, the resource and 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 <***@mit.edu<mailto:***@mit.edu>> wrote:
The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.

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

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

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

[Phil Hunt (IDM)]

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

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

Phil

> On Feb 24, 2016, at 16:04, Mike Jones <***@microsoft.com> wrote:
>
> Azure defines ways for resource servers to be registered for use with a client and for clients to dynamically request an access token for use at a particular resource server. You can call that custom architecture if you want. It’s well-defined but it’s not currently in the standards realm. I know that Google has syntax for doing the same, as I’m sure do a lot of other cloud OAuth deployments, such as Oracle’s. For what it’s worth, the working group talked about possibly producing a standard version of syntax for making these kinds of requests during our discussions in Prague (during the Token Exchange discussion) but nobody has run with this yet.
>
> In this sense, yes, Azure is an application of the kind we’re talking about. Azure already does define specific new OAuth 2.0 discovery metadata values that are used in production. A registry just doesn’t yet exist in which it can register those that are of general applicability.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com]
> Sent: Wednesday, February 24, 2016 3:52 PM
> To: Mike Jones
> Cc: <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Mike
>
> Take a look at the assumptions you are making.
>
> You seem to be assuming application software dictates oauth infrastructure architecture by suggesting that apps register in iana.
>
> Would ms azure allow custom arch?
>
> Phil
>
> On Feb 24, 2016, at 15:28, Mike Jones <***@microsoft.com> wrote:
>
> The UserInfo Endpoint path isn’t fixed and so has to be discovered.
>
> I agree that for some OAuth profiles, one or more resource servers will have to be discovered starting from the authorization server. Working group members have also described wanting to discover authorization servers starting from resource servers. There isn’t a standard practice for any of this, which is why it’s intentionally left out of the current specification.
>
> Once the IANA OAuth Discovery Metadata Registry has been established, which will happen after the current specification has been approved, it will be easy for subsequent specifications to document existing practice for different OAuth profiles and register discovery metadata values supporting them. Some of those values will likely define ways to discover resource servers, when applicable.
>
> But first, we need to finish the existing spec, so that the registry enabling these extensions gets established in the first place.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com]
> Sent: Wednesday, February 24, 2016 2:13 PM
> To: Mike Jones <***@microsoft.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Yup. And because there many relations the client mist be able to discover it. The client does not know if the res server is legit.
>
> The userinfo is always fix and so u dont need discovery.
>
> Phil
>
> On Feb 24, 2016, at 14:05, Mike Jones <***@microsoft.com> wrote:
>
> In OpenID Connect, there’s a resource server called the UserInfo Endpoint that returns claims about the authenticated user as a JSON data structure. Its location is published in OpenID Connect discovery metadata as the “userinfo_endpoint” metadata value, which is defined at http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.
>
> We didn’t include the UserInfo Endpoint in the generic OAuth discovery spec since in OAuth, there are lots of possible relationships between authorization servers and resource servers and they needn’t be one-to-one, as is being actively discussed by the working group. For instance, see George Fletcher’s recent contribution.
>
> Thanks for the good discussion, Phil.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com]
> Sent: Wednesday, February 24, 2016 1:25 PM
> To: Mike Jones
> Cc: <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Where is the profile endpoint (oidc's resource server) published? (For the non OIDC people on the list).
>
> Phil
>
> On Feb 24, 2016, at 13:09, Mike Jones <***@microsoft.com> wrote:
>
> To the extent that generic OAuth 2.0 needs to publish some of the same information as OpenID Connect – which is built on generic OAuth 2.0 – it makes sense to publish that information using exactly the same syntax, since that syntax is already in widespread use. That what this draft accomplishes.
>
> There’s nothing Connect-specific about using metadata response values like:
>
> "authorization_endpoint": "https://server.example.com/authorize",
> "token_endpoint": "https://server.example.com/token",
> "token_endpoint_auth_methods_supported": ["client_secret_basic", "private_key_jwt"],
> "registration_endpoint": "https://server.example.com/register",
> "response_types_supported": ["code", "token"],
> "service_documentation": "http://server.example.com/service_documentation.html",
>
> Is there a reason that you would like the syntax for any of these or the other generally applicable OAuth 2.0 metadata values to be different? I don’t see any good reason for unnecessary differences to be introduced.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com]
> Sent: Wednesday, February 24, 2016 12:45 PM
> To: Anthony Nadalin <***@microsoft.com>
> Cc: Mike Jones <***@microsoft.com>; <***@ietf.org> <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Mike
>
> Publishing on dev pages does not work for software (esp open source) that is deployed both in enterprises and on PaaS cloud providers.
>
> The current draft is may codify current OIDC practice and be appropriate for oidc but it is not ready for generic oauth. There is no generic oauth experience at this time.
>
> Phil
>
> On Feb 24, 2016, at 10:25, Anthony Nadalin <***@microsoft.com> wrote:
>
> Sure there is, it is as you have now made it far easier and the security considerations does not even address this
>
> From: Mike Jones
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin <***@microsoft.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> As we’d discussed in person, there’s no effective security difference between discovery information being published in an ad-hoc fashion on developer pages and it being published in a standard format. “Security by obscurity” adds no real security at all.
>
> -- Mike
>
> From: Anthony Nadalin
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones <***@microsoft.com>; Phil Hunt (IDM) <***@oracle.com>; Nat Sakimura <***@gmail.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> > The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
> That may be widely deployed for OIDC but not widely deployed for OAuth. There are some authentication mechanism discovery for endpoint that really should not be in an OAuth standard since it’s really not dealt with. Now that all this information is available it makes poking around the endpoint more focused for people that want to disrupt your endpoints, that is really not addressed in the security considerations section at all
>
> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Mike Jones
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Phil Hunt (IDM) <***@oracle.com>; Nat Sakimura <***@gmail.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
> None of Nat or John or I are suggesting that additional related functionality won’t be created. I’m sure it will be. Some applications will use WebFinger to locate the discovery metadata. Some will possibly use link headers. Some will possibly use application-specific .well-known values. I’m sure there’s other things I haven’t even thought about. All of these depend upon having a discovery metadata document format and none of them change it – other than possibly to register additional discovery metadata values.
>
> So by all means, the working group should continue discussing inventing possible new related mechanisms that make sense in some contexts. At the same time, we can finish standardizing the already widely deployed core functionality that all of these mechanisms will need.
>
> -- Mike
>
> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Phil Hunt (IDM)
> Sent: Wednesday, February 24, 2016 8:39 AM
> To: Nat Sakimura <***@gmail.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> I am suggesting that part of the discovery solution has to be the client indicating what resource endpoint it wants the oauth configuration data for.
>
> So if res.example.evil.com 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 <***@gmail.com> wrote:
>
> Hi Phil,
>
> Are you suggesting that the AS metadata should include the RS URIs? Currently, it does not, but it can be done, I guess.
>
> The way oauth-meta works is that
>
> 1. RS tells the client where the AS is.
> 2. AS tells the client which RS endpoints the token can be used.
>
> Even if there is a bad AS with a valid certs that proxies to the good RS, the client will not send the token there as the authz server will say that is not the place the client may want to send the token to.
>
> Nat
>
> 2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com>:
> Nat,
>
> I’m not sure that having the resource server tell the client where its authorization server is secure by itself. The relationship between the Authorization Server and the Resource server need to be bound together in one of the discovery endpoints (the resource and/or the oauth service discovery).
>
> If a client discovers a fake resource server that is proxying for a real resource server the current discovery spec will not lead the client to understand it has the wrong resource server. Rather the fake resource service will just have a fake discovery service. The hacker can now intercept resource payload as well as tokens because they were able to convince the client to use the legit authorization service but use the token against the hackers proxy.
>
> The OAuth Discovery service needs to confirm to the client that the server is able to issue tokens for a stated resource endpoint.
>
> This not only works in normal OAuth but should add security even to UMA situations.
>
> Phil
>
> @independentid
> www.independentid.com
> ***@oracle.com
>
>
>
>
>
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <***@gmail.com> wrote:
>
>
> Hi Thomas,
>
> inline:
>
> 2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com>:
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed
>
> Yup. That's one of the requirements to be RESTful, is it not?
>
> In OAuth's case, the resource and 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 <***@mit.edu> wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.
>
> I propose that we use “/.well-known/oauth-authorization-server” as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration” if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.
>
> — Justin
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

[Vladimir Dzhuvinov]

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

Here are some example OIDC discovery docs:

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

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

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


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

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


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

Cheers,

Vladimir




On 25/02/16 02:25, Phil Hunt (IDM) wrote:
> And so does oracle and so does google. Each different.
>
> So how can an app dictate it then unless we all go to a common architecture?
>
> Phil
>
>> On Feb 24, 2016, at 16:04, Mike Jones <***@microsoft.com> wrote:
>>
>> Azure defines ways for resource servers to be registered for use with a client and for clients to dynamically request an access token for use at a particular resource server. You can call that custom architecture if you want. It’s well-defined but it’s not currently in the standards realm. I know that Google has syntax for doing the same, as I’m sure do a lot of other cloud OAuth deployments, such as Oracle’s. For what it’s worth, the working group talked about possibly producing a standard version of syntax for making these kinds of requests during our discussions in Prague (during the Token Exchange discussion) but nobody has run with this yet.
>>
>> In this sense, yes, Azure is an application of the kind we’re talking about. Azure already does define specific new OAuth 2.0 discovery metadata values that are used in production. A registry just doesn’t yet exist in which it can register those that are of general applicability.
>>
>> -- Mike
>>
>> From: Phil Hunt (IDM) [mailto:***@oracle.com]
>> Sent: Wednesday, February 24, 2016 3:52 PM
>> To: Mike Jones
>> Cc: <***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> Mike
>>
>> Take a look at the assumptions you are making.
>>
>> You seem to be assuming application software dictates oauth infrastructure architecture by suggesting that apps register in iana.
>>
>> Would ms azure allow custom arch?
>>
>> Phil
>>
>> On Feb 24, 2016, at 15:28, Mike Jones <***@microsoft.com> wrote:
>>
>> The UserInfo Endpoint path isn’t fixed and so has to be discovered.
>>
>> I agree that for some OAuth profiles, one or more resource servers will have to be discovered starting from the authorization server. Working group members have also described wanting to discover authorization servers starting from resource servers. There isn’t a standard practice for any of this, which is why it’s intentionally left out of the current specification.
>>
>> Once the IANA OAuth Discovery Metadata Registry has been established, which will happen after the current specification has been approved, it will be easy for subsequent specifications to document existing practice for different OAuth profiles and register discovery metadata values supporting them. Some of those values will likely define ways to discover resource servers, when applicable.
>>
>> But first, we need to finish the existing spec, so that the registry enabling these extensions gets established in the first place.
>>
>> -- Mike
>>
>> From: Phil Hunt (IDM) [mailto:***@oracle.com]
>> Sent: Wednesday, February 24, 2016 2:13 PM
>> To: Mike Jones <***@microsoft.com>
>> Cc: <***@ietf.org> <***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> Yup. And because there many relations the client mist be able to discover it. The client does not know if the res server is legit.
>>
>> The userinfo is always fix and so u dont need discovery.
>>
>> Phil
>>
>> On Feb 24, 2016, at 14:05, Mike Jones <***@microsoft.com> wrote:
>>
>> In OpenID Connect, there’s a resource server called the UserInfo Endpoint that returns claims about the authenticated user as a JSON data structure. Its location is published in OpenID Connect discovery metadata as the “userinfo_endpoint” metadata value, which is defined at http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.
>>
>> We didn’t include the UserInfo Endpoint in the generic OAuth discovery spec since in OAuth, there are lots of possible relationships between authorization servers and resource servers and they needn’t be one-to-one, as is being actively discussed by the working group. For instance, see George Fletcher’s recent contribution.
>>
>> Thanks for the good discussion, Phil.
>>
>> -- Mike
>>
>> From: Phil Hunt (IDM) [mailto:***@oracle.com]
>> Sent: Wednesday, February 24, 2016 1:25 PM
>> To: Mike Jones
>> Cc: <***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> Where is the profile endpoint (oidc's resource server) published? (For the non OIDC people on the list).
>>
>> Phil
>>
>> On Feb 24, 2016, at 13:09, Mike Jones <***@microsoft.com> wrote:
>>
>> To the extent that generic OAuth 2.0 needs to publish some of the same information as OpenID Connect – which is built on generic OAuth 2.0 – it makes sense to publish that information using exactly the same syntax, since that syntax is already in widespread use. That what this draft accomplishes.
>>
>> There’s nothing Connect-specific about using metadata response values like:
>>
>> "authorization_endpoint": "https://server.example.com/authorize",
>> "token_endpoint": "https://server.example.com/token",
>> "token_endpoint_auth_methods_supported": ["client_secret_basic", "private_key_jwt"],
>> "registration_endpoint": "https://server.example.com/register",
>> "response_types_supported": ["code", "token"],
>> "service_documentation": "http://server.example.com/service_documentation.html",
>>
>> Is there a reason that you would like the syntax for any of these or the other generally applicable OAuth 2.0 metadata values to be different? I don’t see any good reason for unnecessary differences to be introduced.
>>
>> -- Mike
>>
>> From: Phil Hunt (IDM) [mailto:***@oracle.com]
>> Sent: Wednesday, February 24, 2016 12:45 PM
>> To: Anthony Nadalin <***@microsoft.com>
>> Cc: Mike Jones <***@microsoft.com>; <***@ietf.org> <***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> Mike
>>
>> Publishing on dev pages does not work for software (esp open source) that is deployed both in enterprises and on PaaS cloud providers.
>>
>> The current draft is may codify current OIDC practice and be appropriate for oidc but it is not ready for generic oauth. There is no generic oauth experience at this time.
>>
>> Phil
>>
>> On Feb 24, 2016, at 10:25, Anthony Nadalin <***@microsoft.com> wrote:
>>
>> Sure there is, it is as you have now made it far easier and the security considerations does not even address this
>>
>> From: Mike Jones
>> Sent: Wednesday, February 24, 2016 10:22 AM
>> To: Anthony Nadalin <***@microsoft.com>
>> Cc: <***@ietf.org> <***@ietf.org>
>> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> As we’d discussed in person, there’s no effective security difference between discovery information being published in an ad-hoc fashion on developer pages and it being published in a standard format. “Security by obscurity” adds no real security at all.
>>
>> -- Mike
>>
>> From: Anthony Nadalin
>> Sent: Wednesday, February 24, 2016 10:01 AM
>> To: Mike Jones <***@microsoft.com>; Phil Hunt (IDM) <***@oracle.com>; Nat Sakimura <***@gmail.com>
>> Cc: <***@ietf.org> <***@ietf.org>
>> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>>> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>>
>> That may be widely deployed for OIDC but not widely deployed for OAuth. There are some authentication mechanism discovery for endpoint that really should not be in an OAuth standard since it’s really not dealt with. Now that all this information is available it makes poking around the endpoint more focused for people that want to disrupt your endpoints, that is really not addressed in the security considerations section at all
>>
>> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Mike Jones
>> Sent: Wednesday, February 24, 2016 9:54 AM
>> To: Phil Hunt (IDM) <***@oracle.com>; Nat Sakimura <***@gmail.com>
>> Cc: <***@ietf.org> <***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>>
>> None of Nat or John or I are suggesting that additional related functionality won’t be created. I’m sure it will be. Some applications will use WebFinger to locate the discovery metadata. Some will possibly use link headers. Some will possibly use application-specific .well-known values. I’m sure there’s other things I haven’t even thought about. All of these depend upon having a discovery metadata document format and none of them change it – other than possibly to register additional discovery metadata values.
>>
>> So by all means, the working group should continue discussing inventing possible new related mechanisms that make sense in some contexts. At the same time, we can finish standardizing the already widely deployed core functionality that all of these mechanisms will need.
>>
>> -- Mike
>>
>> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Phil Hunt (IDM)
>> Sent: Wednesday, February 24, 2016 8:39 AM
>> To: Nat Sakimura <***@gmail.com>
>> Cc: <***@ietf.org> <***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> I am suggesting that part of the discovery solution has to be the client indicating what resource endpoint it wants the oauth configuration data for.
>>
>> So if res.example.evil.com 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 <***@gmail.com> wrote:
>>
>> Hi Phil,
>>
>> Are you suggesting that the AS metadata should include the RS URIs? Currently, it does not, but it can be done, I guess.
>>
>> The way oauth-meta works is that
>>
>> 1. RS tells the client where the AS is.
>> 2. AS tells the client which RS endpoints the token can be used.
>>
>> Even if there is a bad AS with a valid certs that proxies to the good RS, the client will not send the token there as the authz server will say that is not the place the client may want to send the token to.
>>
>> Nat
>>
>> 2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com>:
>> Nat,
>>
>> I’m not sure that having the resource server tell the client where its authorization server is secure by itself. The relationship between the Authorization Server and the Resource server need to be bound together in one of the discovery endpoints (the resource and/or the oauth service discovery).
>>
>> If a client discovers a fake resource server that is proxying for a real resource server the current discovery spec will not lead the client to understand it has the wrong resource server. Rather the fake resource service will just have a fake discovery service. The hacker can now intercept resource payload as well as tokens because they were able to convince the client to use the legit authorization service but use the token against the hackers proxy.
>>
>> The OAuth Discovery service needs to confirm to the client that the server is able to issue tokens for a stated resource endpoint.
>>
>> This not only works in normal OAuth but should add security even to UMA situations.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com
>> ***@oracle.com
>>
>>
>>
>>
>>
>> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <***@gmail.com> wrote:
>>
>>
>> Hi Thomas,
>>
>> inline:
>>
>> 2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com>:
>> Couldn't the document only describe the metadata?
>> I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".
>> The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).
>> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed
>>
>> Yup. That's one of the requirements to be RESTful, is it not?
>>
>> In OAuth's case, the resource and 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 <***@mit.edu> wrote:
>> The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.
>>
>> I propose that we use “/.well-known/oauth-authorization-server” as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration” if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.
>>
>> — Justin
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--
Vladimir Dzhuvinov :: ***@connect2id.com

[Mike Jones]

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

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

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

In summary, which title do people prefer?

· “OAuth 2.0 Discovery”

· “OAuth 2.0 Authorization Server Discovery”

-- Mike

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

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

Here are some example OIDC discovery docs:

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

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

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


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

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


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

Cheers,

Vladimir



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

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



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



Phil



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



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



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



-- Mike



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

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

To: Mike Jones

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

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



Mike



Take a look at the assumptions you are making.



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



Would ms azure allow custom arch?



Phil



On Feb 24, 2016, at 15:28, Mike Jones <***@microsoft.com><mailto:***@microsoft.com> wrote:



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



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



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



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



-- Mike



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

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

To: Mike Jones <***@microsoft.com><mailto:***@microsoft.com>

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

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



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



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



Phil



On Feb 24, 2016, at 14:05, Mike Jones <***@microsoft.com><mailto:***@microsoft.com> wrote:



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



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



Thanks for the good discussion, Phil.



-- Mike



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

Sent: Wednesday, February 24, 2016 1:25 PM

To: Mike Jones

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

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



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



Phil



On Feb 24, 2016, at 13:09, Mike Jones <***@microsoft.com><mailto:***@microsoft.com> wrote:



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



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



"authorization_endpoint": "https://server.example.com/authorize"<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>,



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:***@oracle.com]

Sent: Wednesday, February 24, 2016 12:45 PM

To: Anthony Nadalin <***@microsoft.com><mailto:***@microsoft.com>

Cc: Mike Jones <***@microsoft.com><mailto:***@microsoft.com>; <***@ietf.org><mailto:***@ietf.org> <***@ietf.org><mailto:***@ietf.org>

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



Mike



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



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



Phil



On Feb 24, 2016, at 10:25, Anthony Nadalin <***@microsoft.com><mailto:***@microsoft.com> wrote:



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



From: Mike Jones

Sent: Wednesday, February 24, 2016 10:22 AM

To: Anthony Nadalin <***@microsoft.com><mailto:***@microsoft.com>

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

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



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



-- Mike



From: Anthony Nadalin

Sent: Wednesday, February 24, 2016 10:01 AM

To: Mike Jones <***@microsoft.com><mailto:***@microsoft.com>; Phil Hunt (IDM) <***@oracle.com><mailto:***@oracle.com>; Nat Sakimura <***@gmail.com><mailto:***@gmail.com>

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

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



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



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



From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Mike Jones

Sent: Wednesday, February 24, 2016 9:54 AM

To: Phil Hunt (IDM) <***@oracle.com><mailto:***@oracle.com>; Nat Sakimura <***@gmail.com><mailto:***@gmail.com>

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

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



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



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



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



-- Mike



From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Phil Hunt (IDM)

Sent: Wednesday, February 24, 2016 8:39 AM

To: Nat Sakimura <***@gmail.com><mailto:***@gmail.com>

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

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



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



So if res.example.evil.com 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 <***@gmail.com><mailto:***@gmail.com> wrote:



Hi Phil,



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



The way oauth-meta works is that



1. RS tells the client where the AS is.

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



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



Nat



2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com><mailto:***@oracle.com>:

Nat,



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



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



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



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



Phil



@independentid

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

***@oracle.com<mailto:***@oracle.com>











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





Hi Thomas,



inline:



2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com><mailto:***@gmail.com>:

Couldn't the document only describe the metadata?

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

The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).

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



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



In OAuth's case, the resource and 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 <***@mit.edu><mailto:***@mit.edu> wrote:

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



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



— Justin

_______________________________________________

OAuth mailing list

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

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

_______________________________________________

OAuth mailing list

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

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

_______________________________________________

OAuth mailing list

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

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



_______________________________________________

OAuth mailing list

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

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






_______________________________________________

OAuth mailing list

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

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



--

Vladimir Dzhuvinov :: ***@connect2id.com<mailto:***@connect2id.com>

[George Fletcher]

+1 for “OAuth 2.0 Authorization Server Discovery”

On 2/25/16 2:10 PM, Mike Jones wrote:
>
> Thanks for your thoughts, Vladimir. I’m increasingly inclined to
> accept your suggestion to change the title from “OAuth 2.0 Discovery”
> to “OAuth 2.0 Authorization Server Discovery”. While the abstract
> already makes it clear that the scope of the document is AS discovery,
> doing so in the title seems like it could help clarify things, given
> that a lot of the discussion seems to be about resource discovery,
> which is out of scope of the document.
>
> I’m not saying that resource discovery isn’t important – it is – but
> unlike authorization server discovery, where there’s lots of existing
> practice, including using the existing data format for describing
> OAuth implementations that aren’t being used with OpenID Connect,
> there’s no existing practice to standardize for resource discovery.
> The time to create a standard for that seems to be after existing
> practice has emerged. It **might** or might not use new metadata
> values in the AS discovery document, but that’s still to be
> determined. The one reason to leave the title as-is is that resource
> discovery might end up involving extensions to this metadata format in
> some cases.
>
> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750
> applies. 6749 is about the AS. 6750 is about the RS. The discovery
> document is about the AS. We don’t yet have a specification or
> existing practice for RS discovery, which would be the 6750 analogy.
>
> In summary, which title do people prefer?
>
> ·“OAuth 2.0 Discovery”
>
> ·“OAuth 2.0 Authorization Server Discovery”
>
> -- Mike
>
> *From:*OAuth [mailto:oauth-***@ietf.org] *On Behalf Of *Vladimir
> Dzhuvinov
> *Sent:* Thursday, February 25, 2016 12:59 AM
> *To:* ***@ietf.org
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> In OIDC the discovery doc is of great utility to developers and
> integrators. Developers also tend to find it a more accurate and
> complete description of how to set up a client for a particular
> deployment, compared to traditional online docs, which may be not be
> up to date, or even missing. Very much like auto-generated Swagger and
> JavaDocs.
>
> Here are some example OIDC discovery docs:
>
> https://accounts.google.com/.well-known/openid-configuration
>
> https://www.paypalobjects.com/.well-known/openid-configuration
>
> https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration
>
>
> With this discovery document in place setup of identity federation can
> then be easily scripted. For example:
>
> http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html
>
>
> Now, does that dictate any particular app architecture? My reading of
> the spec is that it doesn't, and it shouldn't either. By staying
> neutral on the topics of RS discovery and registering RPs with RSs.
> And how one arrives at the ".well-known/...". I'm not even sure that
> resource discovery should be a topic of this WG. Perhaps to this end,
> and to prevent confusion that the spec is trying to do something more,
> a more specific title would suit it better. E.g. "AS Discovery".
>
> Cheers,
>
> Vladimir
>
>
>
> On 25/02/16 02:25, Phil Hunt (IDM) wrote:
>
> And so does oracle and so does google. Each different.
>
> So how can an app dictate it then unless we all go to a common architecture?
>
> Phil
>
> On Feb 24, 2016, at 16:04, Mike Jones<***@microsoft.com> <mailto:***@microsoft.com> wrote:
>
> Azure defines ways for resource servers to be registered for use with a client and for clients to dynamically request an access token for use at a particular resource server. You can call that custom architecture if you want. It’s well-defined but it’s not currently in the standards realm. I know that Google has syntax for doing the same, as I’m sure do a lot of other cloud OAuth deployments, such as Oracle’s. For what it’s worth, the working group talked about possibly producing a standard version of syntax for making these kinds of requests during our discussions in Prague (during the Token Exchange discussion) but nobody has run with this yet.
>
>
>
> In this sense, yes, Azure is an application of the kind we’re talking about. Azure already does define specific new OAuth 2.0 discovery metadata values that are used in production. A registry just doesn’t yet exist in which it can register those that are of general applicability.
>
>
>
> -- Mike
>
>
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com]
>
> Sent: Wednesday, February 24, 2016 3:52 PM
>
> To: Mike Jones
>
> Cc:<***@ietf.org> <mailto:***@ietf.org>
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> Mike
>
>
>
> Take a look at the assumptions you are making.
>
>
>
> You seem to be assuming application software dictates oauth infrastructure architecture by suggesting that apps register in iana.
>
>
>
> Would ms azure allow custom arch?
>
> Phil
>
> On Feb 24, 2016, at 15:28, Mike Jones<***@microsoft.com> <mailto:***@microsoft.com> wrote:
>
> The UserInfo Endpoint path isn’t fixed and so has to be discovered.
>
>
>
> I agree that for some OAuth profiles, one or more resource servers will have to be discovered starting from the authorization server. Working group members have also described wanting to discover authorization servers starting from resource servers. There isn’t a standard practice for any of this, which is why it’s intentionally left out of the current specification.
>
>
>
> Once the IANA OAuth Discovery Metadata Registry has been established, which will happen after the current specification has been approved, it will be easy for subsequent specifications to document existing practice for different OAuth profiles and register discovery metadata values supporting them. Some of those values will likely define ways to discover resource servers, when applicable.
>
>
>
> But first, we need to finish the existing spec, so that the registry enabling these extensions gets established in the first place.
>
>
>
> -- Mike
>
>
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com]
>
> Sent: Wednesday, February 24, 2016 2:13 PM
>
> To: Mike Jones<***@microsoft.com> <mailto:***@microsoft.com>
>
> Cc:<***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> Yup. And because there many relations the client mist be able to discover it. The client does not know if the res server is legit.
>
>
>
> The userinfo is always fix and so u dont need discovery.
>
> Phil
>
> On Feb 24, 2016, at 14:05, Mike Jones<***@microsoft.com> <mailto:***@microsoft.com> wrote:
>
> In OpenID Connect, there’s a resource server called the UserInfo Endpoint that returns claims about the authenticated user as a JSON data structure. Its location is published in OpenID Connect discovery metadata as the “userinfo_endpoint” metadata value, which is defined athttp://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:***@oracle.com]
>
> Sent: Wednesday, February 24, 2016 1:25 PM
>
> To: Mike Jones
>
> Cc:<***@ietf.org> <mailto:***@ietf.org>
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> Where is the profile endpoint (oidc's resource server) published? (For the non OIDC people on the list).
>
> Phil
>
> On Feb 24, 2016, at 13:09, Mike Jones<***@microsoft.com> <mailto:***@microsoft.com> wrote:
>
> To the extent that generic OAuth 2.0 needs to publish some of the same information as OpenID Connect – which is built on generic OAuth 2.0 – it makes sense to publish that information using exactly the same syntax, since that syntax is already in widespread use. That what this draft accomplishes.
>
>
>
> There’s nothing Connect-specific about using metadata response values like:
>
>
>
> "authorization_endpoint":"https://server.example.com/authorize"
> <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>,
>
>
>
> 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:***@oracle.com]
>
> Sent: Wednesday, February 24, 2016 12:45 PM
>
> To: Anthony Nadalin<***@microsoft.com> <mailto:***@microsoft.com>
>
> Cc: Mike Jones<***@microsoft.com> <mailto:***@microsoft.com>;<***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> Mike
>
>
>
> Publishing on dev pages does not work for software (esp open source) that is deployed both in enterprises and on PaaS cloud providers.
>
>
>
> The current draft is may codify current OIDC practice and be appropriate for oidc but it is not ready for generic oauth. There is no generic oauth experience at this time.
>
> Phil
>
> On Feb 24, 2016, at 10:25, Anthony Nadalin<***@microsoft.com> <mailto:***@microsoft.com> wrote:
>
> Sure there is, it is as you have now made it far easier and the security considerations does not even address this
>
>
>
> From: Mike Jones
>
> Sent: Wednesday, February 24, 2016 10:22 AM
>
> To: Anthony Nadalin<***@microsoft.com> <mailto:***@microsoft.com>
>
> Cc:<***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> As we’d discussed in person, there’s no effective security difference between discovery information being published in an ad-hoc fashion on developer pages and it being published in a standard format. “Security by obscurity” adds no real security at all.
>
>
>
> -- Mike
>
>
>
> From: Anthony Nadalin
>
> Sent: Wednesday, February 24, 2016 10:01 AM
>
> To: Mike Jones<***@microsoft.com> <mailto:***@microsoft.com>; Phil Hunt (IDM)<***@oracle.com> <mailto:***@oracle.com>; Nat Sakimura<***@gmail.com> <mailto:***@gmail.com>
>
> Cc:<***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
>
>
> That may be widely deployed for OIDC but not widely deployed for OAuth. There are some authentication mechanism discovery for endpoint that really should not be in an OAuth standard since it’s really not dealt with. Now that all this information is available it makes poking around the endpoint more focused for people that want to disrupt your endpoints, that is really not addressed in the security considerations section at all
>
>
>
> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Mike Jones
>
> Sent: Wednesday, February 24, 2016 9:54 AM
>
> To: Phil Hunt (IDM)<***@oracle.com> <mailto:***@oracle.com>; Nat Sakimura<***@gmail.com> <mailto:***@gmail.com>
>
> Cc:<***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
>
>
> None of Nat or John or I are suggesting that additional related functionality won’t be created. I’m sure it will be. Some applications will use WebFinger to locate the discovery metadata. Some will possibly use link headers. Some will possibly use application-specific .well-known values. I’m sure there’s other things I haven’t even thought about. All of these depend upon having a discovery metadata document format and none of them change it – other than possibly to register additional discovery metadata values.
>
>
>
> So by all means, the working group should continue discussing inventing possible new related mechanisms that make sense in some contexts. At the same time, we can finish standardizing the already widely deployed core functionality that all of these mechanisms will need.
>
>
>
> -- Mike
>
>
>
> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Phil Hunt (IDM)
>
> Sent: Wednesday, February 24, 2016 8:39 AM
>
> To: Nat Sakimura<***@gmail.com> <mailto:***@gmail.com>
>
> Cc:<***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> I am suggesting that part of the discovery solution has to be the client indicating what resource endpoint it wants the oauth configuration data for.
>
>
>
> So if res.example.evil.com 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<***@gmail.com> <mailto:***@gmail.com> wrote:
>
> Hi Phil,
>
>
>
> Are you suggesting that the AS metadata should include the RS URIs? Currently, it does not, but it can be done, I guess.
>
>
>
> The way oauth-meta works is that
>
>
>
> 1. RS tells the client where the AS is.
>
> 2. AS tells the client which RS endpoints the token can be used.
>
>
>
> Even if there is a bad AS with a valid certs that proxies to the good RS, the client will not send the token there as the authz server will say that is not the place the client may want to send the token to.
>
> Nat
>
>
>
> 2016幎2月24日(æ°Ž) 23:59 Phil Hunt<***@oracle.com> <mailto:***@oracle.com>:
>
> Nat,
>
>
>
> I’m not sure that having the resource server tell the client where its authorization server is secure by itself. The relationship between the Authorization Server and the Resource server need to be bound together in one of the discovery endpoints (the resource and/or the oauth service discovery).
>
>
>
> If a client discovers a fake resource server that is proxying for a real resource server the current discovery spec will not lead the client to understand it has the wrong resource server. Rather the fake resource service will just have a fake discovery service. The hacker can now intercept resource payload as well as tokens because they were able to convince the client to use the legit authorization service but use the token against the hackers proxy.
>
>
>
> The OAuth Discovery service needs to confirm to the client that the server is able to issue tokens for a stated resource endpoint.
>
>
>
> This not only works in normal OAuth but should add security even to UMA situations.
>
>
>
> Phil
>
>
>
> @independentid
>
> www.independentid.com <http://www.independentid.com>
>
> ***@oracle.com <mailto:***@oracle.com>
>
>
>
>
>
>
>
>
>
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura<***@gmail.com> <mailto:***@gmail.com> wrote:
>
>
>
> Hi Thomas,
>
>
>
> inline:
>
>
>
> 2016幎2月22日(月) 18:44 Thomas Broyer<***@gmail.com> <mailto:***@gmail.com>:
>
> Couldn't the document only describe the metadata?
>
> I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".
>
> The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).
>
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed
>
>
>
> Yup. That's one of the requirements to be RESTful, is it not?
>
>
>
> In OAuth's case, the resource and 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<***@mit.edu> <mailto:***@mit.edu> wrote:
>
> The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.
>
> I propose that we use “/.well-known/oauth-authorization-server” as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration” if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.
>
> — Justin
>
> _______________________________________________
>
> OAuth mailing list
>
> ***@ietf.org <mailto:***@ietf.org>
>
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
>
> OAuth mailing list
>
> ***@ietf.org <mailto:***@ietf.org>
>
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
>
> OAuth mailing list
>
> ***@ietf.org <mailto:***@ietf.org>
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> ***@ietf.org <mailto:***@ietf.org>
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> ***@ietf.org <mailto:***@ietf.org>
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> --
> Vladimir Dzhuvinov ::***@connect2id.com <mailto:***@connect2id.com>
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

[Justin Richer]

+1 for “OAuth 2.0 Authorization Server Discovery”

— Justin

> On Feb 25, 2016, at 2:20 PM, George Fletcher <***@aol.com> wrote:
>
> +1 for “OAuth 2.0 Authorization Server Discovery”
>
> On 2/25/16 2:10 PM, Mike Jones wrote:
>> Thanks for your thoughts, Vladimir. I’m increasingly inclined to accept your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0 Authorization Server Discovery”. While the abstract already makes it clear that the scope of the document is AS discovery, doing so in the title seems like it could help clarify things, given that a lot of the discussion seems to be about resource discovery, which is out of scope of the document.
>>
>> I’m not saying that resource discovery isn’t important – it is – but unlike authorization server discovery, where there’s lots of existing practice, including using the existing data format for describing OAuth implementations that aren’t being used with OpenID Connect, there’s no existing practice to standardize for resource discovery. The time to create a standard for that seems to be after existing practice has emerged. It *might* or might not use new metadata values in the AS discovery document, but that’s still to be determined. The one reason to leave the title as-is is that resource discovery might end up involving extensions to this metadata format in some cases.
>>
>> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 applies. 6749 is about the AS. 6750 is about the RS. The discovery document is about the AS. We don’t yet have a specification or existing practice for RS discovery, which would be the 6750 analogy.
>>
>> In summary, which title do people prefer?
>> · “OAuth 2.0 Discovery”
>> · “OAuth 2.0 Authorization Server Discovery”
>>
>> -- Mike
>>   <>
>> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org>] On Behalf Of Vladimir Dzhuvinov
>> Sent: Thursday, February 25, 2016 12:59 AM
>> To: ***@ietf.org <mailto:***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> In OIDC the discovery doc is of great utility to developers and integrators. Developers also tend to find it a more accurate and complete description of how to set up a client for a particular deployment, compared to traditional online docs, which may be not be up to date, or even missing. Very much like auto-generated Swagger and JavaDocs.
>>
>> Here are some example OIDC discovery docs:
>>
>> https://accounts.google.com/.well-known/openid-configuration <https://accounts.google.com/.well-known/openid-configuration>
>>
>> https://www.paypalobjects.com/.well-known/openid-configuration <https://www.paypalobjects.com/.well-known/openid-configuration>
>>
>> https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration <https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration>
>>
>>
>> With this discovery document in place setup of identity federation can then be easily scripted. For example:
>>
>> http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html <http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html>
>>
>>
>> Now, does that dictate any particular app architecture? My reading of the spec is that it doesn't, and it shouldn't either. By staying neutral on the topics of RS discovery and registering RPs with RSs. And how one arrives at the ".well-known/...". I'm not even sure that resource discovery should be a topic of this WG. Perhaps to this end, and to prevent confusion that the spec is trying to do something more, a more specific title would suit it better. E.g. "AS Discovery".
>>
>> Cheers,
>>
>> Vladimir
>>
>>
>>
>>
>> On 25/02/16 02:25, Phil Hunt (IDM) wrote:
>> And so does oracle and so does google. Each different.
>>
>> So how can an app dictate it then unless we all go to a common architecture?
>>
>> Phil
>>
>> On Feb 24, 2016, at 16:04, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>>
>> Azure defines ways for resource servers to be registered for use with a client and for clients to dynamically request an access token for use at a particular resource server. You can call that custom architecture if you want. It’s well-defined but it’s not currently in the standards realm. I know that Google has syntax for doing the same, as I’m sure do a lot of other cloud OAuth deployments, such as Oracle’s. For what it’s worth, the working group talked about possibly producing a standard version of syntax for making these kinds of requests during our discussions in Prague (during the Token Exchange discussion) but nobody has run with this yet.
>>
>> In this sense, yes, Azure is an application of the kind we’re talking about. Azure already does define specific new OAuth 2.0 discovery metadata values that are used in production. A registry just doesn’t yet exist in which it can register those that are of general applicability.
>>
>> -- Mike
>>
>> From: Phil Hunt (IDM) [mailto:***@oracle.com <mailto:***@oracle.com>]
>> Sent: Wednesday, February 24, 2016 3:52 PM
>> To: Mike Jones
>> Cc: <***@ietf.org> <mailto:***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> Mike
>>
>> Take a look at the assumptions you are making.
>>
>> You seem to be assuming application software dictates oauth infrastructure architecture by suggesting that apps register in iana.
>>
>> Would ms azure allow custom arch?
>>
>> Phil
>>
>> On Feb 24, 2016, at 15:28, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>>
>> The UserInfo Endpoint path isn’t fixed and so has to be discovered.
>>
>> I agree that for some OAuth profiles, one or more resource servers will have to be discovered starting from the authorization server. Working group members have also described wanting to discover authorization servers starting from resource servers. There isn’t a standard practice for any of this, which is why it’s intentionally left out of the current specification.
>>
>> Once the IANA OAuth Discovery Metadata Registry has been established, which will happen after the current specification has been approved, it will be easy for subsequent specifications to document existing practice for different OAuth profiles and register discovery metadata values supporting them. Some of those values will likely define ways to discover resource servers, when applicable.
>>
>> But first, we need to finish the existing spec, so that the registry enabling these extensions gets established in the first place.
>>
>> -- Mike
>>
>> From: Phil Hunt (IDM) [mailto:***@oracle.com <mailto:***@oracle.com>]
>> Sent: Wednesday, February 24, 2016 2:13 PM
>> To: Mike Jones <***@microsoft.com> <mailto:***@microsoft.com>
>> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> Yup. And because there many relations the client mist be able to discover it. The client does not know if the res server is legit.
>>
>> The userinfo is always fix and so u dont need discovery.
>>
>> Phil
>>
>> On Feb 24, 2016, at 14:05, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>>
>> In OpenID Connect, there’s a resource server called the UserInfo Endpoint that returns claims about the authenticated user as a JSON data structure. Its location is published in OpenID Connect discovery metadata as the “userinfo_endpoint” metadata value, which is defined at http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata <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:***@oracle.com <mailto:***@oracle.com>]
>> Sent: Wednesday, February 24, 2016 1:25 PM
>> To: Mike Jones
>> Cc: <***@ietf.org> <mailto:***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> Where is the profile endpoint (oidc's resource server) published? (For the non OIDC people on the list).
>>
>> Phil
>>
>> On Feb 24, 2016, at 13:09, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>>
>> To the extent that generic OAuth 2.0 needs to publish some of the same information as OpenID Connect – which is built on generic OAuth 2.0 – it makes sense to publish that information using exactly the same syntax, since that syntax is already in widespread use. That what this draft accomplishes.
>>
>> There’s nothing Connect-specific about using metadata response values like:
>>
>> "authorization_endpoint": "https://server.example.com/authorize" <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>,
>>
>> 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:***@oracle.com <mailto:***@oracle.com>]
>> Sent: Wednesday, February 24, 2016 12:45 PM
>> To: Anthony Nadalin <***@microsoft.com> <mailto:***@microsoft.com>
>> Cc: Mike Jones <***@microsoft.com> <mailto:***@microsoft.com>; <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> Mike
>>
>> Publishing on dev pages does not work for software (esp open source) that is deployed both in enterprises and on PaaS cloud providers.
>>
>> The current draft is may codify current OIDC practice and be appropriate for oidc but it is not ready for generic oauth. There is no generic oauth experience at this time.
>>
>> Phil
>>
>> On Feb 24, 2016, at 10:25, Anthony Nadalin <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>>
>> Sure there is, it is as you have now made it far easier and the security considerations does not even address this
>>
>> From: Mike Jones
>> Sent: Wednesday, February 24, 2016 10:22 AM
>> To: Anthony Nadalin <***@microsoft.com> <mailto:***@microsoft.com>
>> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> As we’d discussed in person, there’s no effective security difference between discovery information being published in an ad-hoc fashion on developer pages and it being published in a standard format. “Security by obscurity” adds no real security at all.
>>
>> -- Mike
>>
>> From: Anthony Nadalin
>> Sent: Wednesday, February 24, 2016 10:01 AM
>> To: Mike Jones <***@microsoft.com> <mailto:***@microsoft.com>; Phil Hunt (IDM) <***@oracle.com> <mailto:***@oracle.com>; Nat Sakimura <***@gmail.com> <mailto:***@gmail.com>
>> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>>
>> That may be widely deployed for OIDC but not widely deployed for OAuth. There are some authentication mechanism discovery for endpoint that really should not be in an OAuth standard since it’s really not dealt with. Now that all this information is available it makes poking around the endpoint more focused for people that want to disrupt your endpoints, that is really not addressed in the security considerations section at all
>>
>> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org>] On Behalf Of Mike Jones
>> Sent: Wednesday, February 24, 2016 9:54 AM
>> To: Phil Hunt (IDM) <***@oracle.com> <mailto:***@oracle.com>; Nat Sakimura <***@gmail.com> <mailto:***@gmail.com>
>> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>>
>> None of Nat or John or I are suggesting that additional related functionality won’t be created. I’m sure it will be. Some applications will use WebFinger to locate the discovery metadata. Some will possibly use link headers. Some will possibly use application-specific .well-known values. I’m sure there’s other things I haven’t even thought about. All of these depend upon having a discovery metadata document format and none of them change it – other than possibly to register additional discovery metadata values.
>>
>> So by all means, the working group should continue discussing inventing possible new related mechanisms that make sense in some contexts. At the same time, we can finish standardizing the already widely deployed core functionality that all of these mechanisms will need.
>>
>> -- Mike
>>
>> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org>] On Behalf Of Phil Hunt (IDM)
>> Sent: Wednesday, February 24, 2016 8:39 AM
>> To: Nat Sakimura <***@gmail.com> <mailto:***@gmail.com>
>> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> I am suggesting that part of the discovery solution has to be the client indicating what resource endpoint it wants the oauth configuration data for.
>>
>> So if res.example.evil.com 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 <***@gmail.com> <mailto:***@gmail.com> wrote:
>>
>> Hi Phil,
>>
>> Are you suggesting that the AS metadata should include the RS URIs? Currently, it does not, but it can be done, I guess.
>>
>> The way oauth-meta works is that
>>
>> 1. RS tells the client where the AS is.
>> 2. AS tells the client which RS endpoints the token can be used.
>>
>> Even if there is a bad AS with a valid certs that proxies to the good RS, the client will not send the token there as the authz server will say that is not the place the client may want to send the token to.
>>
>> Nat
>>
>> 2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com> <mailto:***@oracle.com>:
>> Nat,
>>
>> I’m not sure that having the resource server tell the client where its authorization server is secure by itself. The relationship between the Authorization Server and the Resource server need to be bound together in one of the discovery endpoints (the resource and/or the oauth service discovery).
>>
>> If a client discovers a fake resource server that is proxying for a real resource server the current discovery spec will not lead the client to understand it has the wrong resource server. Rather the fake resource service will just have a fake discovery service. The hacker can now intercept resource payload as well as tokens because they were able to convince the client to use the legit authorization service but use the token against the hackers proxy.
>>
>> The OAuth Discovery service needs to confirm to the client that the server is able to issue tokens for a stated resource endpoint.
>>
>> This not only works in normal OAuth but should add security even to UMA situations.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com <http://www.independentid.com/>
>> ***@oracle.com <mailto:***@oracle.com>
>>
>>
>>
>>
>>
>> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <***@gmail.com> <mailto:***@gmail.com> wrote:
>>
>>
>> Hi Thomas,
>>
>> inline:
>>
>> 2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com> <mailto:***@gmail.com>:
>> Couldn't the document only describe the metadata?
>> I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".
>> The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).
>> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed
>>
>> Yup. That's one of the requirements to be RESTful, is it not?
>>
>> In OAuth's case, the resource and 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 <***@mit.edu> <mailto:***@mit.edu> wrote:
>> The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.
>>
>> I propose that we use “/.well-known/oauth-authorization-server” as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration” if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.
>>
>> — Justin
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>
>> --
>> Vladimir Dzhuvinov :: ***@connect2id.com <mailto:***@connect2id.com>
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

[t***@lodderstedt.net]

+1

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

-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
Von: Justin Richer <***@mit.edu>
An: George Fletcher <***@aol.com>
Cc: "<***@ietf.org>" <***@ietf.org>

>+1 for “OAuth 2.0 Authorization Server Discovery”
>
> — Justin
>
>> On Feb 25, 2016, at 2:20 PM, George Fletcher <***@aol.com> wrote:
>>
>> +1 for “OAuth 2.0 Authorization Server Discovery”
>>
>> On 2/25/16 2:10 PM, Mike Jones wrote:
>>> Thanks for your thoughts, Vladimir. I’m increasingly inclined to accept your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0 Authorization Server Discovery”. While the abstract already makes it clear that the scope of the document is AS discovery, doing so in the title seems like it could help clarify things, given that a lot of the discussion seems to be about resource discovery, which is out of scope of the document.
>>>
>>> I’m not saying that resource discovery isn’t important – it is – but unlike authorization server discovery, where there’s lots of existing practice, including using the existing data format for describing OAuth implementations that aren’t being used with OpenID Connect, there’s no existing practice to standardize for resource discovery. The time to create a standard for that seems to be after existing practice has emerged. It *might* or might not use new metadata values in the AS discovery document, but that’s still to be determined. The one reason to leave the title as-is is that resource discovery might end up involving extensions to this metadata format in some cases.
>>>
>>> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 applies. 6749 is about the AS. 6750 is about the RS. The discovery document is about the AS. We don’t yet have a specification or existing practice for RS discovery, which would be the 6750 analogy.
>>>
>>> In summary, which title do people prefer?
>>> · “OAuth 2.0 Discovery”
>>> · “OAuth 2.0 Authorization Server Discovery”
>>>
>>> -- Mike
>>>   <>
>>> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org>] On Behalf Of Vladimir Dzhuvinov
>>> Sent: Thursday, February 25, 2016 12:59 AM
>>> To: ***@ietf.org <mailto:***@ietf.org>
>>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>>
>>> In OIDC the discovery doc is of great utility to developers and integrators. Developers also tend to find it a more accurate and complete description of how to set up a client for a particular deployment, compared to traditional online docs, which may be not be up to date, or even missing. Very much like auto-generated Swagger and JavaDocs.
>>>
>>> Here are some example OIDC discovery docs:
>>>
>>> https://accounts.google.com/.well-known/openid-configuration <https://accounts.google.com/.well-known/openid-configuration>
>>>
>>> https://www.paypalobjects.com/.well-known/openid-configuration <https://www.paypalobjects.com/.well-known/openid-configuration>
>>>
>>> https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration <https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration>
>>>
>>>
>>> With this discovery document in place setup of identity federation can then be easily scripted. For example:
>>>
>>> http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html <http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html>
>>>
>>>
>>> Now, does that dictate any particular app architecture? My reading of the spec is that it doesn't, and it shouldn't either. By staying neutral on the topics of RS discovery and registering RPs with RSs. And how one arrives at the ".well-known/...". I'm not even sure that resource discovery should be a topic of this WG. Perhaps to this end, and to prevent confusion that the spec is trying to do something more, a more specific title would suit it better. E.g. "AS Discovery".
>>>
>>> Cheers,
>>>
>>> Vladimir
>>>
>>>
>>>
>>>
>>> On 25/02/16 02:25, Phil Hunt (IDM) wrote:
>>> And so does oracle and so does google. Each different.
>>>
>>> So how can an app dictate it then unless we all go to a common architecture?
>>>
>>> Phil
>>>
>>> On Feb 24, 2016, at 16:04, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>>>
>>> Azure defines ways for resource servers to be registered for use with a client and for clients to dynamically request an access token for use at a particular resource server. You can call that custom architecture if you want. It’s well-defined but it’s not currently in the standards realm. I know that Google has syntax for doing the same, as I’m sure do a lot of other cloud OAuth deployments, such as Oracle’s. For what it’s worth, the working group talked about possibly producing a standard version of syntax for making these kinds of requests during our discussions in Prague (during the Token Exchange discussion) but nobody has run with this yet.
>>>
>>> In this sense, yes, Azure is an application of the kind we’re talking about. Azure already does define specific new OAuth 2.0 discovery metadata values that are used in production. A registry just doesn’t yet exist in which it can register those that are of general applicability.
>>>
>>> -- Mike
>>>
>>> From: Phil Hunt (IDM) [mailto:***@oracle.com <mailto:***@oracle.com>]
>>> Sent: Wednesday, February 24, 2016 3:52 PM
>>> To: Mike Jones
>>> Cc: <***@ietf.org> <mailto:***@ietf.org>
>>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>>
>>> Mike
>>>
>>> Take a look at the assumptions you are making.
>>>
>>> You seem to be assuming application software dictates oauth infrastructure architecture by suggesting that apps register in iana.
>>>
>>> Would ms azure allow custom arch?
>>>
>>> Phil
>>>
>>> On Feb 24, 2016, at 15:28, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>>>
>>> The UserInfo Endpoint path isn’t fixed and so has to be discovered.
>>>
>>> I agree that for some OAuth profiles, one or more resource servers will have to be discovered starting from the authorization server. Working group members have also described wanting to discover authorization servers starting from resource servers. There isn’t a standard practice for any of this, which is why it’s intentionally left out of the current specification.
>>>
>>> Once the IANA OAuth Discovery Metadata Registry has been established, which will happen after the current specification has been approved, it will be easy for subsequent specifications to document existing practice for different OAuth profiles and register discovery metadata values supporting them. Some of those values will likely define ways to discover resource servers, when applicable.
>>>
>>> But first, we need to finish the existing spec, so that the registry enabling these extensions gets established in the first place.
>>>
>>> -- Mike
>>>
>>> From: Phil Hunt (IDM) [mailto:***@oracle.com <mailto:***@oracle.com>]
>>> Sent: Wednesday, February 24, 2016 2:13 PM
>>> To: Mike Jones <***@microsoft.com> <mailto:***@microsoft.com>
>>> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>>
>>> Yup. And because there many relations the client mist be able to discover it. The client does not know if the res server is legit.
>>>
>>> The userinfo is always fix and so u dont need discovery.
>>>
>>> Phil
>>>
>>> On Feb 24, 2016, at 14:05, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>>>
>>> In OpenID Connect, there’s a resource server called the UserInfo Endpoint that returns claims about the authenticated user as a JSON data structure. Its location is published in OpenID Connect discovery metadata as the “userinfo_endpoint” metadata value, which is defined at http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata <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:***@oracle.com <mailto:***@oracle.com>]
>>> Sent: Wednesday, February 24, 2016 1:25 PM
>>> To: Mike Jones
>>> Cc: <***@ietf.org> <mailto:***@ietf.org>
>>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>>
>>> Where is the profile endpoint (oidc's resource server) published? (For the non OIDC people on the list).
>>>
>>> Phil
>>>
>>> On Feb 24, 2016, at 13:09, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>>>
>>> To the extent that generic OAuth 2.0 needs to publish some of the same information as OpenID Connect – which is built on generic OAuth 2.0 – it makes sense to publish that information using exactly the same syntax, since that syntax is already in widespread use. That what this draft accomplishes.
>>>
>>> There’s nothing Connect-specific about using metadata response values like:
>>>
>>> "authorization_endpoint": "https://server.example.com/authorize" <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>,
>>>
>>> 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:***@oracle.com <mailto:***@oracle.com>]
>>> Sent: Wednesday, February 24, 2016 12:45 PM
>>> To: Anthony Nadalin <***@microsoft.com> <mailto:***@microsoft.com>
>>> Cc: Mike Jones <***@microsoft.com> <mailto:***@microsoft.com>; <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>>
>>> Mike
>>>
>>> Publishing on dev pages does not work for software (esp open source) that is deployed both in enterprises and on PaaS cloud providers.
>>>
>>> The current draft is may codify current OIDC practice and be appropriate for oidc but it is not ready for generic oauth. There is no generic oauth experience at this time.
>>>
>>> Phil
>>>
>>> On Feb 24, 2016, at 10:25, Anthony Nadalin <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>>>
>>> Sure there is, it is as you have now made it far easier and the security considerations does not even address this
>>>
>>> From: Mike Jones
>>> Sent: Wednesday, February 24, 2016 10:22 AM
>>> To: Anthony Nadalin <***@microsoft.com> <mailto:***@microsoft.com>
>>> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>>> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>>>
>>> As we’d discussed in person, there’s no effective security difference between discovery information being published in an ad-hoc fashion on developer pages and it being published in a standard format. “Security by obscurity” adds no real security at all.
>>>
>>> -- Mike
>>>
>>> From: Anthony Nadalin
>>> Sent: Wednesday, February 24, 2016 10:01 AM
>>> To: Mike Jones <***@microsoft.com> <mailto:***@microsoft.com>; Phil Hunt (IDM) <***@oracle.com> <mailto:***@oracle.com>; Nat Sakimura <***@gmail.com> <mailto:***@gmail.com>
>>> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>>> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>>>
>>> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>>>
>>> That may be widely deployed for OIDC but not widely deployed for OAuth. There are some authentication mechanism discovery for endpoint that really should not be in an OAuth standard since it’s really not dealt with. Now that all this information is available it makes poking around the endpoint more focused for people that want to disrupt your endpoints, that is really not addressed in the security considerations section at all
>>>
>>> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org>] On Behalf Of Mike Jones
>>> Sent: Wednesday, February 24, 2016 9:54 AM
>>> To: Phil Hunt (IDM) <***@oracle.com> <mailto:***@oracle.com>; Nat Sakimura <***@gmail.com> <mailto:***@gmail.com>
>>> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>>
>>> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>>>
>>> None of Nat or John or I are suggesting that additional related functionality won’t be created. I’m sure it will be. Some applications will use WebFinger to locate the discovery metadata. Some will possibly use link headers. Some will possibly use application-specific .well-known values. I’m sure there’s other things I haven’t even thought about. All of these depend upon having a discovery metadata document format and none of them change it – other than possibly to register additional discovery metadata values.
>>>
>>> So by all means, the working group should continue discussing inventing possible new related mechanisms that make sense in some contexts. At the same time, we can finish standardizing the already widely deployed core functionality that all of these mechanisms will need.
>>>
>>> -- Mike
>>>
>>> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org>] On Behalf Of Phil Hunt (IDM)
>>> Sent: Wednesday, February 24, 2016 8:39 AM
>>> To: Nat Sakimura <***@gmail.com> <mailto:***@gmail.com>
>>> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>>
>>> I am suggesting that part of the discovery solution has to be the client indicating what resource endpoint it wants the oauth configuration data for.
>>>
>>> So if res.example.evil.com 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 <***@gmail.com> <mailto:***@gmail.com> wrote:
>>>
>>> Hi Phil,
>>>
>>> Are you suggesting that the AS metadata should include the RS URIs? Currently, it does not, but it can be done, I guess.
>>>
>>> The way oauth-meta works is that
>>>
>>> 1. RS tells the client where the AS is.
>>> 2. AS tells the client which RS endpoints the token can be used.
>>>
>>> Even if there is a bad AS with a valid certs that proxies to the good RS, the client will not send the token there as the authz server will say that is not the place the client may want to send the token to.
>>>
>>> Nat
>>>
>>> 2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com> <mailto:***@oracle.com>:
>>> Nat,
>>>
>>> I’m not sure that having the resource server tell the client where its authorization server is secure by itself. The relationship between the Authorization Server and the Resource server need to be bound together in one of the discovery endpoints (the resource and/or the oauth service discovery).
>>>
>>> If a client discovers a fake resource server that is proxying for a real resource server the current discovery spec will not lead the client to understand it has the wrong resource server. Rather the fake resource service will just have a fake discovery service. The hacker can now intercept resource payload as well as tokens because they were able to convince the client to use the legit authorization service but use the token against the hackers proxy.
>>>
>>> The OAuth Discovery service needs to confirm to the client that the server is able to issue tokens for a stated resource endpoint.
>>>
>>> This not only works in normal OAuth but should add security even to UMA situations.
>>>
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com <http://www.independentid.com/>
>>> ***@oracle.com <mailto:***@oracle.com>
>>>
>>>
>>>
>>>
>>>
>>> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <***@gmail.com> <mailto:***@gmail.com> wrote:
>>>
>>>
>>> Hi Thomas,
>>>
>>> inline:
>>>
>>> 2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com> <mailto:***@gmail.com>:
>>> Couldn't the document only describe the metadata?
>>> I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".
>>> The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).
>>> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed
>>>
>>> Yup. That's one of the requirements to be RESTful, is it not?
>>>
>>> In OAuth's case, the resource and 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 <***@mit.edu> <mailto:***@mit.edu> wrote:
>>> The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.
>>>
>>> I propose that we use “/.well-known/oauth-authorization-server” as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration” if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.
>>>
>>> — Justin
>>> _______________________________________________
>>> OAuth mailing list
>>> ***@ietf.org <mailto:***@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>> _______________________________________________
>>> OAuth mailing list
>>> ***@ietf.org <mailto:***@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>> _______________________________________________
>>> OAuth mailing list
>>> ***@ietf.org <mailto:***@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> ***@ietf.org <mailto:***@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> ***@ietf.org <mailto:***@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>
>>>
>>> --
>>> Vladimir Dzhuvinov :: ***@connect2id.com <mailto:***@connect2id.com>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> ***@ietf.org <mailto:***@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>_______________________________________________
>OAuth mailing list
>***@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth

[John Bradley]

Authorization server discovery.

> On Feb 25, 2016, at 8:10 PM, Mike Jones <***@microsoft.com> wrote:
>
> Thanks for your thoughts, Vladimir. I’m increasingly inclined to accept your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0 Authorization Server Discovery”. While the abstract already makes it clear that the scope of the document is AS discovery, doing so in the title seems like it could help clarify things, given that a lot of the discussion seems to be about resource discovery, which is out of scope of the document.
>
> I’m not saying that resource discovery isn’t important – it is – but unlike authorization server discovery, where there’s lots of existing practice, including using the existing data format for describing OAuth implementations that aren’t being used with OpenID Connect, there’s no existing practice to standardize for resource discovery. The time to create a standard for that seems to be after existing practice has emerged. It *might* or might not use new metadata values in the AS discovery document, but that’s still to be determined. The one reason to leave the title as-is is that resource discovery might end up involving extensions to this metadata format in some cases.
>
> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 applies. 6749 is about the AS. 6750 is about the RS. The discovery document is about the AS. We don’t yet have a specification or existing practice for RS discovery, which would be the 6750 analogy.
>
> In summary, which title do people prefer?
> · “OAuth 2.0 Discovery”
> · “OAuth 2.0 Authorization Server Discovery”
>
> -- Mike
>   <>
> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Vladimir Dzhuvinov
> Sent: Thursday, February 25, 2016 12:59 AM
> To: ***@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> In OIDC the discovery doc is of great utility to developers and integrators. Developers also tend to find it a more accurate and complete description of how to set up a client for a particular deployment, compared to traditional online docs, which may be not be up to date, or even missing. Very much like auto-generated Swagger and JavaDocs.
>
> Here are some example OIDC discovery docs:
>
> https://accounts.google.com/.well-known/openid-configuration <https://accounts.google.com/.well-known/openid-configuration>
>
> https://www.paypalobjects.com/.well-known/openid-configuration <https://www.paypalobjects.com/.well-known/openid-configuration>
>
> https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration <https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration>
>
>
> With this discovery document in place setup of identity federation can then be easily scripted. For example:
>
> http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html <http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html>
>
>
> Now, does that dictate any particular app architecture? My reading of the spec is that it doesn't, and it shouldn't either. By staying neutral on the topics of RS discovery and registering RPs with RSs. And how one arrives at the ".well-known/...". I'm not even sure that resource discovery should be a topic of this WG. Perhaps to this end, and to prevent confusion that the spec is trying to do something more, a more specific title would suit it better. E.g. "AS Discovery".
>
> Cheers,
>
> Vladimir
>
>
>
>
> On 25/02/16 02:25, Phil Hunt (IDM) wrote:
> And so does oracle and so does google. Each different.
>
> So how can an app dictate it then unless we all go to a common architecture?
>
> Phil
>
> On Feb 24, 2016, at 16:04, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>
> Azure defines ways for resource servers to be registered for use with a client and for clients to dynamically request an access token for use at a particular resource server. You can call that custom architecture if you want. It’s well-defined but it’s not currently in the standards realm. I know that Google has syntax for doing the same, as I’m sure do a lot of other cloud OAuth deployments, such as Oracle’s. For what it’s worth, the working group talked about possibly producing a standard version of syntax for making these kinds of requests during our discussions in Prague (during the Token Exchange discussion) but nobody has run with this yet.
>
> In this sense, yes, Azure is an application of the kind we’re talking about. Azure already does define specific new OAuth 2.0 discovery metadata values that are used in production. A registry just doesn’t yet exist in which it can register those that are of general applicability.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com <mailto:***@oracle.com>]
> Sent: Wednesday, February 24, 2016 3:52 PM
> To: Mike Jones
> Cc: <***@ietf.org> <mailto:***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Mike
>
> Take a look at the assumptions you are making.
>
> You seem to be assuming application software dictates oauth infrastructure architecture by suggesting that apps register in iana.
>
> Would ms azure allow custom arch?
>
> Phil
>
> On Feb 24, 2016, at 15:28, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>
> The UserInfo Endpoint path isn’t fixed and so has to be discovered.
>
> I agree that for some OAuth profiles, one or more resource servers will have to be discovered starting from the authorization server. Working group members have also described wanting to discover authorization servers starting from resource servers. There isn’t a standard practice for any of this, which is why it’s intentionally left out of the current specification.
>
> Once the IANA OAuth Discovery Metadata Registry has been established, which will happen after the current specification has been approved, it will be easy for subsequent specifications to document existing practice for different OAuth profiles and register discovery metadata values supporting them. Some of those values will likely define ways to discover resource servers, when applicable.
>
> But first, we need to finish the existing spec, so that the registry enabling these extensions gets established in the first place.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com <mailto:***@oracle.com>]
> Sent: Wednesday, February 24, 2016 2:13 PM
> To: Mike Jones <***@microsoft.com> <mailto:***@microsoft.com>
> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Yup. And because there many relations the client mist be able to discover it. The client does not know if the res server is legit.
>
> The userinfo is always fix and so u dont need discovery.
>
> Phil
>
> On Feb 24, 2016, at 14:05, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>
> In OpenID Connect, there’s a resource server called the UserInfo Endpoint that returns claims about the authenticated user as a JSON data structure. Its location is published in OpenID Connect discovery metadata as the “userinfo_endpoint” metadata value, which is defined at http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata <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:***@oracle.com <mailto:***@oracle.com>]
> Sent: Wednesday, February 24, 2016 1:25 PM
> To: Mike Jones
> Cc: <***@ietf.org> <mailto:***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Where is the profile endpoint (oidc's resource server) published? (For the non OIDC people on the list).
>
> Phil
>
> On Feb 24, 2016, at 13:09, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>
> To the extent that generic OAuth 2.0 needs to publish some of the same information as OpenID Connect – which is built on generic OAuth 2.0 – it makes sense to publish that information using exactly the same syntax, since that syntax is already in widespread use. That what this draft accomplishes.
>
> There’s nothing Connect-specific about using metadata response values like:
>
> "authorization_endpoint": "https://server.example.com/authorize" <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>,
>
> 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:***@oracle.com <mailto:***@oracle.com>]
> Sent: Wednesday, February 24, 2016 12:45 PM
> To: Anthony Nadalin <***@microsoft.com> <mailto:***@microsoft.com>
> Cc: Mike Jones <***@microsoft.com> <mailto:***@microsoft.com>; <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Mike
>
> Publishing on dev pages does not work for software (esp open source) that is deployed both in enterprises and on PaaS cloud providers.
>
> The current draft is may codify current OIDC practice and be appropriate for oidc but it is not ready for generic oauth. There is no generic oauth experience at this time.
>
> Phil
>
> On Feb 24, 2016, at 10:25, Anthony Nadalin <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>
> Sure there is, it is as you have now made it far easier and the security considerations does not even address this
>
> From: Mike Jones
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin <***@microsoft.com> <mailto:***@microsoft.com>
> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> As we’d discussed in person, there’s no effective security difference between discovery information being published in an ad-hoc fashion on developer pages and it being published in a standard format. “Security by obscurity” adds no real security at all.
>
> -- Mike
>
> From: Anthony Nadalin
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones <***@microsoft.com> <mailto:***@microsoft.com>; Phil Hunt (IDM) <***@oracle.com> <mailto:***@oracle.com>; Nat Sakimura <***@gmail.com> <mailto:***@gmail.com>
> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
> That may be widely deployed for OIDC but not widely deployed for OAuth. There are some authentication mechanism discovery for endpoint that really should not be in an OAuth standard since it’s really not dealt with. Now that all this information is available it makes poking around the endpoint more focused for people that want to disrupt your endpoints, that is really not addressed in the security considerations section at all
>
> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org>] On Behalf Of Mike Jones
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Phil Hunt (IDM) <***@oracle.com> <mailto:***@oracle.com>; Nat Sakimura <***@gmail.com> <mailto:***@gmail.com>
> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
> None of Nat or John or I are suggesting that additional related functionality won’t be created. I’m sure it will be. Some applications will use WebFinger to locate the discovery metadata. Some will possibly use link headers. Some will possibly use application-specific .well-known values. I’m sure there’s other things I haven’t even thought about. All of these depend upon having a discovery metadata document format and none of them change it – other than possibly to register additional discovery metadata values.
>
> So by all means, the working group should continue discussing inventing possible new related mechanisms that make sense in some contexts. At the same time, we can finish standardizing the already widely deployed core functionality that all of these mechanisms will need.
>
> -- Mike
>
> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org>] On Behalf Of Phil Hunt (IDM)
> Sent: Wednesday, February 24, 2016 8:39 AM
> To: Nat Sakimura <***@gmail.com> <mailto:***@gmail.com>
> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> I am suggesting that part of the discovery solution has to be the client indicating what resource endpoint it wants the oauth configuration data for.
>
> So if res.example.evil.com 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 <***@gmail.com> <mailto:***@gmail.com> wrote:
>
> Hi Phil,
>
> Are you suggesting that the AS metadata should include the RS URIs? Currently, it does not, but it can be done, I guess.
>
> The way oauth-meta works is that
>
> 1. RS tells the client where the AS is.
> 2. AS tells the client which RS endpoints the token can be used.
>
> Even if there is a bad AS with a valid certs that proxies to the good RS, the client will not send the token there as the authz server will say that is not the place the client may want to send the token to.
>
> Nat
>
> 2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com> <mailto:***@oracle.com>:
> Nat,
>
> I’m not sure that having the resource server tell the client where its authorization server is secure by itself. The relationship between the Authorization Server and the Resource server need to be bound together in one of the discovery endpoints (the resource and/or the oauth service discovery).
>
> If a client discovers a fake resource server that is proxying for a real resource server the current discovery spec will not lead the client to understand it has the wrong resource server. Rather the fake resource service will just have a fake discovery service. The hacker can now intercept resource payload as well as tokens because they were able to convince the client to use the legit authorization service but use the token against the hackers proxy.
>
> The OAuth Discovery service needs to confirm to the client that the server is able to issue tokens for a stated resource endpoint.
>
> This not only works in normal OAuth but should add security even to UMA situations.
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com/>
> ***@oracle.com <mailto:***@oracle.com>
>
>
>
>
>
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <***@gmail.com> <mailto:***@gmail.com> wrote:
>
>
> Hi Thomas,
>
> inline:
>
> 2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com> <mailto:***@gmail.com>:
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed
>
> Yup. That's one of the requirements to be RESTful, is it not?
>
> In OAuth's case, the resource and 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 <***@mit.edu> <mailto:***@mit.edu> wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.
>
> I propose that we use “/.well-known/oauth-authorization-server” as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration” if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.
>
> — Justin
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>
>
> --
> Vladimir Dzhuvinov :: ***@connect2id.com <mailto:***@connect2id.com>_______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

[Samuel Erdtman]

+1 for “OAuth 2.0 Authorization Server Discovery”

//Samuel

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

> Thanks for your thoughts, Vladimir. I’m increasingly inclined to accept
> your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth
> 2.0 Authorization Server Discovery”. While the abstract already makes it
> clear that the scope of the document is AS discovery, doing so in the title
> seems like it could help clarify things, given that a lot of the discussion
> seems to be about resource discovery, which is out of scope of the document.
>
>
>
> I’m not saying that resource discovery isn’t important – it is – but
> unlike authorization server discovery, where there’s lots of existing
> practice, including using the existing data format for describing OAuth
> implementations that aren’t being used with OpenID Connect, there’s no
> existing practice to standardize for resource discovery. The time to
> create a standard for that seems to be after existing practice has
> emerged. It **might** or might not use new metadata values in the AS
> discovery document, but that’s still to be determined. The one reason to
> leave the title as-is is that resource discovery might end up involving
> extensions to this metadata format in some cases.
>
>
>
> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750
> applies. 6749 is about the AS. 6750 is about the RS. The discovery
> document is about the AS. We don’t yet have a specification or existing
> practice for RS discovery, which would be the 6750 analogy.
>
>
>
> In summary, which title do people prefer?
>
> · “OAuth 2.0 Discovery”
>
> · “OAuth 2.0 Authorization Server Discovery”
>
>
>
> -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-***@ietf.org] *On Behalf Of *Vladimir
> Dzhuvinov
> *Sent:* Thursday, February 25, 2016 12:59 AM
> *To:* ***@ietf.org
>
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> In OIDC the discovery doc is of great utility to developers and
> integrators. Developers also tend to find it a more accurate and complete
> description of how to set up a client for a particular deployment, compared
> to traditional online docs, which may be not be up to date, or even
> missing. Very much like auto-generated Swagger and JavaDocs.
>
> Here are some example OIDC discovery docs:
>
> https://accounts.google.com/.well-known/openid-configuration
>
> https://www.paypalobjects.com/.well-known/openid-configuration
>
>
> https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration
>
>
> With this discovery document in place setup of identity federation can
> then be easily scripted. For example:
>
>
> http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html
>
>
> Now, does that dictate any particular app architecture? My reading of the
> spec is that it doesn't, and it shouldn't either. By staying neutral on the
> topics of RS discovery and registering RPs with RSs. And how one arrives at
> the ".well-known/...". I'm not even sure that resource discovery should be
> a topic of this WG. Perhaps to this end, and to prevent confusion that the
> spec is trying to do something more, a more specific title would suit it
> better. E.g. "AS Discovery".
>
> Cheers,
>
> Vladimir
>
>
>
> On 25/02/16 02:25, Phil Hunt (IDM) wrote:
>
> And so does oracle and so does google. Each different.
>
>
>
> So how can an app dictate it then unless we all go to a common architecture?
>
>
>
> Phil
>
>
>
> On Feb 24, 2016, at 16:04, Mike Jones <***@microsoft.com> <***@microsoft.com> wrote:
>
>
>
> Azure defines ways for resource servers to be registered for use with a client and for clients to dynamically request an access token for use at a particular resource server. You can call that custom architecture if you want. It’s well-defined but it’s not currently in the standards realm. I know that Google has syntax for doing the same, as I’m sure do a lot of other cloud OAuth deployments, such as Oracle’s. For what it’s worth, the working group talked about possibly producing a standard version of syntax for making these kinds of requests during our discussions in Prague (during the Token Exchange discussion) but nobody has run with this yet.
>
> In this sense, yes, Azure is an application of the kind we’re talking about. Azure already does define specific new OAuth 2.0 discovery metadata values that are used in production. A registry just doesn’t yet exist in which it can register those that are of general applicability.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com <***@oracle.com>]
>
> Sent: Wednesday, February 24, 2016 3:52 PM
>
> To: Mike Jones
>
> Cc: <***@ietf.org> <***@ietf.org>
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Mike
>
> Take a look at the assumptions you are making.
>
>
>
> You seem to be assuming application software dictates oauth infrastructure architecture by suggesting that apps register in iana.
>
>
>
> Would ms azure allow custom arch?
>
>
>
> Phil
>
>
>
> On Feb 24, 2016, at 15:28, Mike Jones <***@microsoft.com> <***@microsoft.com> wrote:
>
>
>
> The UserInfo Endpoint path isn’t fixed and so has to be discovered.
>
> I agree that for some OAuth profiles, one or more resource servers will have to be discovered starting from the authorization server. Working group members have also described wanting to discover authorization servers starting from resource servers. There isn’t a standard practice for any of this, which is why it’s intentionally left out of the current specification.
>
> Once the IANA OAuth Discovery Metadata Registry has been established, which will happen after the current specification has been approved, it will be easy for subsequent specifications to document existing practice for different OAuth profiles and register discovery metadata values supporting them. Some of those values will likely define ways to discover resource servers, when applicable.
>
> But first, we need to finish the existing spec, so that the registry enabling these extensions gets established in the first place.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com <***@oracle.com>]
>
> Sent: Wednesday, February 24, 2016 2:13 PM
>
> To: Mike Jones <***@microsoft.com> <***@microsoft.com>
>
> Cc: <***@ietf.org> <***@ietf.org> <***@ietf.org> <***@ietf.org>
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Yup. And because there many relations the client mist be able to discover it. The client does not know if the res server is legit.
>
>
>
> The userinfo is always fix and so u dont need discovery.
>
>
>
> Phil
>
>
>
> On Feb 24, 2016, at 14:05, Mike Jones <***@microsoft.com> <***@microsoft.com> wrote:
>
>
>
> In OpenID Connect, there’s a resource server called the UserInfo Endpoint that returns claims about the authenticated user as a JSON data structure. Its location is published in OpenID Connect discovery metadata as the “userinfo_endpoint” metadata value, which is defined at http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.
>
> We didn’t include the UserInfo Endpoint in the generic OAuth discovery spec since in OAuth, there are lots of possible relationships between authorization servers and resource servers and they needn’t be one-to-one, as is being actively discussed by the working group. For instance, see George Fletcher’s recent contribution.
>
> Thanks for the good discussion, Phil.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com <***@oracle.com>]
>
> Sent: Wednesday, February 24, 2016 1:25 PM
>
> To: Mike Jones
>
> Cc: <***@ietf.org> <***@ietf.org>
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Where is the profile endpoint (oidc's resource server) published? (For the non OIDC people on the list).
>
>
>
> Phil
>
>
>
> On Feb 24, 2016, at 13:09, Mike Jones <***@microsoft.com> <***@microsoft.com> wrote:
>
>
>
> To the extent that generic OAuth 2.0 needs to publish some of the same information as OpenID Connect – which is built on generic OAuth 2.0 – it makes sense to publish that information using exactly the same syntax, since that syntax is already in widespread use. That what this draft accomplishes.
>
> There’s nothing Connect-specific about using metadata response values like:
>
> "authorization_endpoint": "https://server.example.com/authorize" <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>,
>
> 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:***@oracle.com <***@oracle.com>]
>
> Sent: Wednesday, February 24, 2016 12:45 PM
>
> To: Anthony Nadalin <***@microsoft.com> <***@microsoft.com>
>
> Cc: Mike Jones <***@microsoft.com> <***@microsoft.com>; <***@ietf.org> <***@ietf.org> <***@ietf.org> <***@ietf.org>
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Mike
>
> Publishing on dev pages does not work for software (esp open source) that is deployed both in enterprises and on PaaS cloud providers.
>
>
>
> The current draft is may codify current OIDC practice and be appropriate for oidc but it is not ready for generic oauth. There is no generic oauth experience at this time.
>
>
>
> Phil
>
>
>
> On Feb 24, 2016, at 10:25, Anthony Nadalin <***@microsoft.com> <***@microsoft.com> wrote:
>
>
>
> Sure there is, it is as you have now made it far easier and the security considerations does not even address this
>
> From: Mike Jones
>
> Sent: Wednesday, February 24, 2016 10:22 AM
>
> To: Anthony Nadalin <***@microsoft.com> <***@microsoft.com>
>
> Cc: <***@ietf.org> <***@ietf.org> <***@ietf.org> <***@ietf.org>
>
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> As we’d discussed in person, there’s no effective security difference between discovery information being published in an ad-hoc fashion on developer pages and it being published in a standard format. “Security by obscurity” adds no real security at all.
>
> -- Mike
>
> From: Anthony Nadalin
>
> Sent: Wednesday, February 24, 2016 10:01 AM
>
> To: Mike Jones <***@microsoft.com> <***@microsoft.com>; Phil Hunt (IDM) <***@oracle.com> <***@oracle.com>; Nat Sakimura <***@gmail.com> <***@gmail.com>
>
> Cc: <***@ietf.org> <***@ietf.org> <***@ietf.org> <***@ietf.org>
>
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
> That may be widely deployed for OIDC but not widely deployed for OAuth. There are some authentication mechanism discovery for endpoint that really should not be in an OAuth standard since it’s really not dealt with. Now that all this information is available it makes poking around the endpoint more focused for people that want to disrupt your endpoints, that is really not addressed in the security considerations section at all
>
> From: OAuth [mailto:oauth-***@ietf.org <oauth-***@ietf.org>] On Behalf Of Mike Jones
>
> Sent: Wednesday, February 24, 2016 9:54 AM
>
> To: Phil Hunt (IDM) <***@oracle.com> <***@oracle.com>; Nat Sakimura <***@gmail.com> <***@gmail.com>
>
> Cc: <***@ietf.org> <***@ietf.org> <***@ietf.org> <***@ietf.org>
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
> None of Nat or John or I are suggesting that additional related functionality won’t be created. I’m sure it will be. Some applications will use WebFinger to locate the discovery metadata. Some will possibly use link headers. Some will possibly use application-specific .well-known values. I’m sure there’s other things I haven’t even thought about. All of these depend upon having a discovery metadata document format and none of them change it – other than possibly to register additional discovery metadata values.
>
> So by all means, the working group should continue discussing inventing possible new related mechanisms that make sense in some contexts. At the same time, we can finish standardizing the already widely deployed core functionality that all of these mechanisms will need.
>
> -- Mike
>
> From: OAuth [mailto:oauth-***@ietf.org <oauth-***@ietf.org>] On Behalf Of Phil Hunt (IDM)
>
> Sent: Wednesday, February 24, 2016 8:39 AM
>
> To: Nat Sakimura <***@gmail.com> <***@gmail.com>
>
> Cc: <***@ietf.org> <***@ietf.org> <***@ietf.org> <***@ietf.org>
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> I am suggesting that part of the discovery solution has to be the client indicating what resource endpoint it wants the oauth configuration data for.
>
>
>
> So if res.example.evil.com 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 <***@gmail.com> <***@gmail.com> wrote:
>
>
>
> Hi Phil,
>
>
>
> Are you suggesting that the AS metadata should include the RS URIs? Currently, it does not, but it can be done, I guess.
>
>
>
> The way oauth-meta works is that
>
>
>
> 1. RS tells the client where the AS is.
>
> 2. AS tells the client which RS endpoints the token can be used.
>
>
>
> Even if there is a bad AS with a valid certs that proxies to the good RS, the client will not send the token there as the authz server will say that is not the place the client may want to send the token to.
>
>
>
> Nat
>
> 2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com> <***@oracle.com>:
>
> Nat,
>
> I’m not sure that having the resource server tell the client where its authorization server is secure by itself. The relationship between the Authorization Server and the Resource server need to be bound together in one of the discovery endpoints (the resource and/or the oauth service discovery).
>
> If a client discovers a fake resource server that is proxying for a real resource server the current discovery spec will not lead the client to understand it has the wrong resource server. Rather the fake resource service will just have a fake discovery service. The hacker can now intercept resource payload as well as tokens because they were able to convince the client to use the legit authorization service but use the token against the hackers proxy.
>
> The OAuth Discovery service needs to confirm to the client that the server is able to issue tokens for a stated resource endpoint.
>
> This not only works in normal OAuth but should add security even to UMA situations.
>
> Phil
>
> @independentid
>
> www.independentid.com
>
> ***@oracle.com
>
>
>
>
>
>
>
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <***@gmail.com> <***@gmail.com> wrote:
>
>
>
> Hi Thomas,
>
>
>
> inline:
>
>
>
> 2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com> <***@gmail.com>:
>
> Couldn't the document only describe the metadata?
>
> I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".
>
> The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).
>
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed
>
>
>
> Yup. That's one of the requirements to be RESTful, is it not?
>
>
>
> In OAuth's case, the resource and 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 <***@mit.edu> <***@mit.edu> wrote:
>
> The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.
>
>
>
> I propose that we use “/.well-known/oauth-authorization-server” as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration” if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.
>
>
>
> — Justin
>
> _______________________________________________
>
> OAuth mailing list
>
> ***@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
>
> OAuth mailing list
>
> ***@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
>
> OAuth mailing list
>
> ***@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
>
> OAuth mailing list
>
> ***@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> ***@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> --
>
> Vladimir Dzhuvinov :: ***@connect2id.com
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

[Mike Jones]

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

Thanks all,
-- Mike

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

+1 for “OAuth 2.0 Authorization Server Discovery”

//Samuel

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

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

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

In summary, which title do people prefer?

• “OAuth 2.0 Discovery”

• “OAuth 2.0 Authorization Server Discovery”

-- Mike

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

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

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

Here are some example OIDC discovery docs:

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

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

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


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

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


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

Cheers,

Vladimir


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

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



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



Phil



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



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



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



-- Mike



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

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

To: Mike Jones

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

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



Mike



Take a look at the assumptions you are making.



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



Would ms azure allow custom arch?



Phil



On Feb 24, 2016, at 15:28, Mike Jones <***@microsoft.com><mailto:***@microsoft.com> wrote:



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



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



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



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



-- Mike



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

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

To: Mike Jones <***@microsoft.com><mailto:***@microsoft.com>

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

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



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



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



Phil



On Feb 24, 2016, at 14:05, Mike Jones <***@microsoft.com><mailto:***@microsoft.com> wrote:



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



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



Thanks for the good discussion, Phil.



-- Mike



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

Sent: Wednesday, February 24, 2016 1:25 PM

To: Mike Jones

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

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



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



Phil



On Feb 24, 2016, at 13:09, Mike Jones <***@microsoft.com><mailto:***@microsoft.com> wrote:



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



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



"authorization_endpoint": "https://server.example.com/authorize"<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>,



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:***@oracle.com]

Sent: Wednesday, February 24, 2016 12:45 PM

To: Anthony Nadalin <***@microsoft.com><mailto:***@microsoft.com>

Cc: Mike Jones <***@microsoft.com><mailto:***@microsoft.com>; <***@ietf.org><mailto:***@ietf.org> <***@ietf.org><mailto:***@ietf.org>

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



Mike



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



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



Phil



On Feb 24, 2016, at 10:25, Anthony Nadalin <***@microsoft.com><mailto:***@microsoft.com> wrote:



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



From: Mike Jones

Sent: Wednesday, February 24, 2016 10:22 AM

To: Anthony Nadalin <***@microsoft.com><mailto:***@microsoft.com>

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

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



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



-- Mike



From: Anthony Nadalin

Sent: Wednesday, February 24, 2016 10:01 AM

To: Mike Jones <***@microsoft.com><mailto:***@microsoft.com>; Phil Hunt (IDM) <***@oracle.com><mailto:***@oracle.com>; Nat Sakimura <***@gmail.com><mailto:***@gmail.com>

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

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



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



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



From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Mike Jones

Sent: Wednesday, February 24, 2016 9:54 AM

To: Phil Hunt (IDM) <***@oracle.com><mailto:***@oracle.com>; Nat Sakimura <***@gmail.com><mailto:***@gmail.com>

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

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



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



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



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



-- Mike



From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Phil Hunt (IDM)

Sent: Wednesday, February 24, 2016 8:39 AM

To: Nat Sakimura <***@gmail.com><mailto:***@gmail.com>

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

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



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



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



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



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



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



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



Phil



On Feb 24, 2016, at 08:12, Nat Sakimura <***@gmail.com><mailto:***@gmail.com> wrote:



Hi Phil,



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



The way oauth-meta works is that



1. RS tells the client where the AS is.

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



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



Nat



2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com><mailto:***@oracle.com>:

Nat,



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



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



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



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



Phil



@independentid

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

***@oracle.com<mailto:***@oracle.com>











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





Hi Thomas,



inline:



2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com><mailto:***@gmail.com>:

Couldn't the document only describe the metadata?

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

The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).

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



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



In OAuth's case, the resource and 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 <***@mit.edu><mailto:***@mit.edu> wrote:

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



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



— Justin

_______________________________________________

OAuth mailing list

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

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

_______________________________________________

OAuth mailing list

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

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

_______________________________________________

OAuth mailing list

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

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



_______________________________________________

OAuth mailing list

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

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





_______________________________________________

OAuth mailing list

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

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


--

Vladimir Dzhuvinov :: ***@connect2id.com<mailto:***@connect2id.com>

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

[Brian Campbell]

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

But what about "OAuth 2.0 Authorization Server Metadata”?

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



On Sat, Feb 27, 2016 at 10:48 AM, Mike Jones <***@microsoft.com>
wrote:

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

[Vladimir Dzhuvinov]

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

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

Because if we take the OIDC definition of discovery, then

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

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

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

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

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


Cheers,

Vladimir


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

[Thomas Broyer]

On Mon, Feb 29, 2016 at 11:35 PM Brian Campbell <***@pingidentity.com>
wrote:

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

+1

(in case that wasn't obvious already by my previous mails)

[George Fletcher]

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

Thanks,
George

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

[Phil Hunt]

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

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

Resource Discovery

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

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

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

Phil

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





> On Feb 27, 2016, at 6:46 AM, Samuel Erdtman <***@erdtman.se> wrote:
>
> +1 for “OAuth 2.0 Authorization Server Discovery”
>
> //Samuel
>
> On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones <***@microsoft.com <mailto:***@microsoft.com>> wrote:
> Thanks for your thoughts, Vladimir. I’m increasingly inclined to accept your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0 Authorization Server Discovery”. While the abstract already makes it clear that the scope of the document is AS discovery, doing so in the title seems like it could help clarify things, given that a lot of the discussion seems to be about resource discovery, which is out of scope of the document.
>
>
>
> I’m not saying that resource discovery isn’t important – it is – but unlike authorization server discovery, where there’s lots of existing practice, including using the existing data format for describing OAuth implementations that aren’t being used with OpenID Connect, there’s no existing practice to standardize for resource discovery. The time to create a standard for that seems to be after existing practice has emerged. It *might* or might not use new metadata values in the AS discovery document, but that’s still to be determined. The one reason to leave the title as-is is that resource discovery might end up involving extensions to this metadata format in some cases.
>
>
>
> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 applies. 6749 is about the AS. 6750 is about the RS. The discovery document is about the AS. We don’t yet have a specification or existing practice for RS discovery, which would be the 6750 analogy.
>
>
>
> In summary, which title do people prefer?
>
> · “OAuth 2.0 Discovery”
>
> · “OAuth 2.0 Authorization Server Discovery”
>
>
>
> -- Mike
>
>   <>
> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org>] On Behalf Of Vladimir Dzhuvinov
> Sent: Thursday, February 25, 2016 12:59 AM
> To: ***@ietf.org <mailto:***@ietf.org>
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> In OIDC the discovery doc is of great utility to developers and integrators. Developers also tend to find it a more accurate and complete description of how to set up a client for a particular deployment, compared to traditional online docs, which may be not be up to date, or even missing. Very much like auto-generated Swagger and JavaDocs.
>
> Here are some example OIDC discovery docs:
>
> https://accounts.google.com/.well-known/openid-configuration <https://accounts.google.com/.well-known/openid-configuration>
>
> https://www.paypalobjects.com/.well-known/openid-configuration <https://www.paypalobjects.com/.well-known/openid-configuration>
>
> https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration <https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration>
>
>
> With this discovery document in place setup of identity federation can then be easily scripted. For example:
>
> http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html <http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html>
>
>
> Now, does that dictate any particular app architecture? My reading of the spec is that it doesn't, and it shouldn't either. By staying neutral on the topics of RS discovery and registering RPs with RSs. And how one arrives at the ".well-known/...". I'm not even sure that resource discovery should be a topic of this WG. Perhaps to this end, and to prevent confusion that the spec is trying to do something more, a more specific title would suit it better. E.g. "AS Discovery".
>
> Cheers,
>
> Vladimir
>
>
>
>
> On 25/02/16 02:25, Phil Hunt (IDM) wrote:
>
> And so does oracle and so does google. Each different.
>
> So how can an app dictate it then unless we all go to a common architecture?
>
> Phil
>
> On Feb 24, 2016, at 16:04, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>
> Azure defines ways for resource servers to be registered for use with a client and for clients to dynamically request an access token for use at a particular resource server. You can call that custom architecture if you want. It’s well-defined but it’s not currently in the standards realm. I know that Google has syntax for doing the same, as I’m sure do a lot of other cloud OAuth deployments, such as Oracle’s. For what it’s worth, the working group talked about possibly producing a standard version of syntax for making these kinds of requests during our discussions in Prague (during the Token Exchange discussion) but nobody has run with this yet.
>
> In this sense, yes, Azure is an application of the kind we’re talking about. Azure already does define specific new OAuth 2.0 discovery metadata values that are used in production. A registry just doesn’t yet exist in which it can register those that are of general applicability.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com <mailto:***@oracle.com>]
> Sent: Wednesday, February 24, 2016 3:52 PM
> To: Mike Jones
> Cc: <***@ietf.org> <mailto:***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Mike
>
> Take a look at the assumptions you are making.
>
> You seem to be assuming application software dictates oauth infrastructure architecture by suggesting that apps register in iana.
>
> Would ms azure allow custom arch?
>
> Phil
>
> On Feb 24, 2016, at 15:28, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>
> The UserInfo Endpoint path isn’t fixed and so has to be discovered.
>
> I agree that for some OAuth profiles, one or more resource servers will have to be discovered starting from the authorization server. Working group members have also described wanting to discover authorization servers starting from resource servers. There isn’t a standard practice for any of this, which is why it’s intentionally left out of the current specification.
>
> Once the IANA OAuth Discovery Metadata Registry has been established, which will happen after the current specification has been approved, it will be easy for subsequent specifications to document existing practice for different OAuth profiles and register discovery metadata values supporting them. Some of those values will likely define ways to discover resource servers, when applicable.
>
> But first, we need to finish the existing spec, so that the registry enabling these extensions gets established in the first place.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com <mailto:***@oracle.com>]
> Sent: Wednesday, February 24, 2016 2:13 PM
> To: Mike Jones <***@microsoft.com> <mailto:***@microsoft.com>
> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Yup. And because there many relations the client mist be able to discover it. The client does not know if the res server is legit.
>
> The userinfo is always fix and so u dont need discovery.
>
> Phil
>
> On Feb 24, 2016, at 14:05, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>
> In OpenID Connect, there’s a resource server called the UserInfo Endpoint that returns claims about the authenticated user as a JSON data structure. Its location is published in OpenID Connect discovery metadata as the “userinfo_endpoint” metadata value, which is defined at http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata <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:***@oracle.com <mailto:***@oracle.com>]
> Sent: Wednesday, February 24, 2016 1:25 PM
> To: Mike Jones
> Cc: <***@ietf.org> <mailto:***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Where is the profile endpoint (oidc's resource server) published? (For the non OIDC people on the list).
>
> Phil
>
> On Feb 24, 2016, at 13:09, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>
> To the extent that generic OAuth 2.0 needs to publish some of the same information as OpenID Connect – which is built on generic OAuth 2.0 – it makes sense to publish that information using exactly the same syntax, since that syntax is already in widespread use. That what this draft accomplishes.
>
> There’s nothing Connect-specific about using metadata response values like:
>
> "authorization_endpoint": "https://server.example.com/authorize" <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>,
>
> 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:***@oracle.com <mailto:***@oracle.com>]
> Sent: Wednesday, February 24, 2016 12:45 PM
> To: Anthony Nadalin <***@microsoft.com> <mailto:***@microsoft.com>
> Cc: Mike Jones <***@microsoft.com> <mailto:***@microsoft.com>; <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Mike
>
> Publishing on dev pages does not work for software (esp open source) that is deployed both in enterprises and on PaaS cloud providers.
>
> The current draft is may codify current OIDC practice and be appropriate for oidc but it is not ready for generic oauth. There is no generic oauth experience at this time.
>
> Phil
>
> On Feb 24, 2016, at 10:25, Anthony Nadalin <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>
> Sure there is, it is as you have now made it far easier and the security considerations does not even address this
>
> From: Mike Jones
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin <***@microsoft.com> <mailto:***@microsoft.com>
> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> As we’d discussed in person, there’s no effective security difference between discovery information being published in an ad-hoc fashion on developer pages and it being published in a standard format. “Security by obscurity” adds no real security at all.
>
> -- Mike
>
> From: Anthony Nadalin
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones <***@microsoft.com> <mailto:***@microsoft.com>; Phil Hunt (IDM) <***@oracle.com> <mailto:***@oracle.com>; Nat Sakimura <***@gmail.com> <mailto:***@gmail.com>
> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
> That may be widely deployed for OIDC but not widely deployed for OAuth. There are some authentication mechanism discovery for endpoint that really should not be in an OAuth standard since it’s really not dealt with. Now that all this information is available it makes poking around the endpoint more focused for people that want to disrupt your endpoints, that is really not addressed in the security considerations section at all
>
> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org>] On Behalf Of Mike Jones
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Phil Hunt (IDM) <***@oracle.com> <mailto:***@oracle.com>; Nat Sakimura <***@gmail.com> <mailto:***@gmail.com>
> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
> None of Nat or John or I are suggesting that additional related functionality won’t be created. I’m sure it will be. Some applications will use WebFinger to locate the discovery metadata. Some will possibly use link headers. Some will possibly use application-specific .well-known values. I’m sure there’s other things I haven’t even thought about. All of these depend upon having a discovery metadata document format and none of them change it – other than possibly to register additional discovery metadata values.
>
> So by all means, the working group should continue discussing inventing possible new related mechanisms that make sense in some contexts. At the same time, we can finish standardizing the already widely deployed core functionality that all of these mechanisms will need.
>
> -- Mike
>
> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org>] On Behalf Of Phil Hunt (IDM)
> Sent: Wednesday, February 24, 2016 8:39 AM
> To: Nat Sakimura <***@gmail.com> <mailto:***@gmail.com>
> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> I am suggesting that part of the discovery solution has to be the client indicating what resource endpoint it wants the oauth configuration data for.
>
> So if res.example.evil.com <http://res.example.evil.com/> is not a valid resource endpoint for as.example.com <http://as.example.com/> the authz discovery should fail in some way (eg return nothing).
>
> There may be better ways to do this. Eg combine discovery. Or change the order of discovery.
>
> One of OAuth's strength's and weaknesses is that the target of authorization (the resource) is never specified. It is often bound up in the client registration and an often implied 1:1 relationship between resource and as. Given that in discovery phase registration has not yet occurred it seems important that the client know it has a valid combination of endpoints etc.
>
> This is why I was disappointed about wglc on discovery. We had a starting point for group adoption but we haven't really defined the full requirements IMO.
>
> I am on vacation or I would put some thought into some draft changes or a new draft. I apologize I can't do it now.
>
> Phil
>
> On Feb 24, 2016, at 08:12, Nat Sakimura <***@gmail.com> <mailto:***@gmail.com> wrote:
>
> Hi Phil,
>
> Are you suggesting that the AS metadata should include the RS URIs? Currently, it does not, but it can be done, I guess.
>
> The way oauth-meta works is that
>
> 1. RS tells the client where the AS is.
> 2. AS tells the client which RS endpoints the token can be used.
>
> Even if there is a bad AS with a valid certs that proxies to the good RS, the client will not send the token there as the authz server will say that is not the place the client may want to send the token to.
>
> Nat
>
> 2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com> <mailto:***@oracle.com>:
> Nat,
>
> I’m not sure that having the resource server tell the client where its authorization server is secure by itself. The relationship between the Authorization Server and the Resource server need to be bound together in one of the discovery endpoints (the resource and/or the oauth service discovery).
>
> If a client discovers a fake resource server that is proxying for a real resource server the current discovery spec will not lead the client to understand it has the wrong resource server. Rather the fake resource service will just have a fake discovery service. The hacker can now intercept resource payload as well as tokens because they were able to convince the client to use the legit authorization service but use the token against the hackers proxy.
>
> The OAuth Discovery service needs to confirm to the client that the server is able to issue tokens for a stated resource endpoint.
>
> This not only works in normal OAuth but should add security even to UMA situations.
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com/>
> ***@oracle.com <mailto:***@oracle.com>
>
>
>
>
>
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <***@gmail.com> <mailto:***@gmail.com> wrote:
>
>
> Hi Thomas,
>
> inline:
>
> 2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com> <mailto:***@gmail.com>:
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed
>
> Yup. That's one of the requirements to be RESTful, is it not?
>
> In OAuth's case, the resource and 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 <***@mit.edu> <mailto:***@mit.edu> wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.
>
> I propose that we use “/.well-known/oauth-authorization-server” as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration” if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.
>
> — Justin
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>
>
> --
> Vladimir Dzhuvinov :: ***@connect2id.com <mailto:***@connect2id.com>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

[Vladimir Dzhuvinov]

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

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



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

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

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

Vladimir


>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com/>***@oracle.com <mailto:***@oracle.com>
>
>
>
>
>
>> On Feb 27, 2016, at 6:46 AM, Samuel Erdtman <***@erdtman.se> wrote:
>>
>> +1 for “OAuth 2.0 Authorization Server Discovery”
>>
>> //Samuel
>>
>> On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones <***@microsoft.com <mailto:***@microsoft.com>> wrote:
>> Thanks for your thoughts, Vladimir. I’m increasingly inclined to accept your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0 Authorization Server Discovery”. While the abstract already makes it clear that the scope of the document is AS discovery, doing so in the title seems like it could help clarify things, given that a lot of the discussion seems to be about resource discovery, which is out of scope of the document.
>>
>>
>>
>> I’m not saying that resource discovery isn’t important – it is – but unlike authorization server discovery, where there’s lots of existing practice, including using the existing data format for describing OAuth implementations that aren’t being used with OpenID Connect, there’s no existing practice to standardize for resource discovery. The time to create a standard for that seems to be after existing practice has emerged. It *might* or might not use new metadata values in the AS discovery document, but that’s still to be determined. The one reason to leave the title as-is is that resource discovery might end up involving extensions to this metadata format in some cases.
>>
>>
>>
>> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 applies. 6749 is about the AS. 6750 is about the RS. The discovery document is about the AS. We don’t yet have a specification or existing practice for RS discovery, which would be the 6750 analogy.
>>
>>
>>
>> In summary, which title do people prefer?
>>
>> · “OAuth 2.0 Discovery”
>>
>> · “OAuth 2.0 Authorization Server Discovery”
>>
>>
>>
>> -- Mike
>>
>> <>
>> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org>] On Behalf Of Vladimir Dzhuvinov
>> Sent: Thursday, February 25, 2016 12:59 AM
>> To: ***@ietf.org <mailto:***@ietf.org>
>>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>>
>>
>> In OIDC the discovery doc is of great utility to developers and integrators. Developers also tend to find it a more accurate and complete description of how to set up a client for a particular deployment, compared to traditional online docs, which may be not be up to date, or even missing. Very much like auto-generated Swagger and JavaDocs.
>>
>> Here are some example OIDC discovery docs:
>>
>> https://accounts.google.com/.well-known/openid-configuration <https://accounts.google.com/.well-known/openid-configuration>
>>
>> https://www.paypalobjects.com/.well-known/openid-configuration <https://www.paypalobjects.com/.well-known/openid-configuration>
>>
>> https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration <https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration>
>>
>>
>> With this discovery document in place setup of identity federation can then be easily scripted. For example:
>>
>> http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html <http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html>
>>
>>
>> Now, does that dictate any particular app architecture? My reading of the spec is that it doesn't, and it shouldn't either. By staying neutral on the topics of RS discovery and registering RPs with RSs. And how one arrives at the ".well-known/...". I'm not even sure that resource discovery should be a topic of this WG. Perhaps to this end, and to prevent confusion that the spec is trying to do something more, a more specific title would suit it better. E.g. "AS Discovery".
>>
>> Cheers,
>>
>> Vladimir
>>
>>
>>
>>
>> On 25/02/16 02:25, Phil Hunt (IDM) wrote:
>>
>> And so does oracle and so does google. Each different.
>>
>> So how can an app dictate it then unless we all go to a common architecture?
>>
>> Phil
>>
>> On Feb 24, 2016, at 16:04, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>>
>> Azure defines ways for resource servers to be registered for use with a client and for clients to dynamically request an access token for use at a particular resource server. You can call that custom architecture if you want. It’s well-defined but it’s not currently in the standards realm. I know that Google has syntax for doing the same, as I’m sure do a lot of other cloud OAuth deployments, such as Oracle’s. For what it’s worth, the working group talked about possibly producing a standard version of syntax for making these kinds of requests during our discussions in Prague (during the Token Exchange discussion) but nobody has run with this yet.
>>
>> In this sense, yes, Azure is an application of the kind we’re talking about. Azure already does define specific new OAuth 2.0 discovery metadata values that are used in production. A registry just doesn’t yet exist in which it can register those that are of general applicability.
>>
>> -- Mike
>>
>> From: Phil Hunt (IDM) [mailto:***@oracle.com <mailto:***@oracle.com>]
>> Sent: Wednesday, February 24, 2016 3:52 PM
>> To: Mike Jones
>> Cc: <***@ietf.org> <mailto:***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> Mike
>>
>> Take a look at the assumptions you are making.
>>
>> You seem to be assuming application software dictates oauth infrastructure architecture by suggesting that apps register in iana.
>>
>> Would ms azure allow custom arch?
>>
>> Phil
>>
>> On Feb 24, 2016, at 15:28, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>>
>> The UserInfo Endpoint path isn’t fixed and so has to be discovered.
>>
>> I agree that for some OAuth profiles, one or more resource servers will have to be discovered starting from the authorization server. Working group members have also described wanting to discover authorization servers starting from resource servers. There isn’t a standard practice for any of this, which is why it’s intentionally left out of the current specification.
>>
>> Once the IANA OAuth Discovery Metadata Registry has been established, which will happen after the current specification has been approved, it will be easy for subsequent specifications to document existing practice for different OAuth profiles and register discovery metadata values supporting them. Some of those values will likely define ways to discover resource servers, when applicable.
>>
>> But first, we need to finish the existing spec, so that the registry enabling these extensions gets established in the first place.
>>
>> -- Mike
>>
>> From: Phil Hunt (IDM) [mailto:***@oracle.com <mailto:***@oracle.com>]
>> Sent: Wednesday, February 24, 2016 2:13 PM
>> To: Mike Jones <***@microsoft.com> <mailto:***@microsoft.com>
>> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> Yup. And because there many relations the client mist be able to discover it. The client does not know if the res server is legit.
>>
>> The userinfo is always fix and so u dont need discovery.
>>
>> Phil
>>
>> On Feb 24, 2016, at 14:05, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>>
>> In OpenID Connect, there’s a resource server called the UserInfo Endpoint that returns claims about the authenticated user as a JSON data structure. Its location is published in OpenID Connect discovery metadata as the “userinfo_endpoint” metadata value, which is defined at http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata <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:***@oracle.com <mailto:***@oracle.com>]
>> Sent: Wednesday, February 24, 2016 1:25 PM
>> To: Mike Jones
>> Cc: <***@ietf.org> <mailto:***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> Where is the profile endpoint (oidc's resource server) published? (For the non OIDC people on the list).
>>
>> Phil
>>
>> On Feb 24, 2016, at 13:09, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>>
>> To the extent that generic OAuth 2.0 needs to publish some of the same information as OpenID Connect – which is built on generic OAuth 2.0 – it makes sense to publish that information using exactly the same syntax, since that syntax is already in widespread use. That what this draft accomplishes.
>>
>> There’s nothing Connect-specific about using metadata response values like:
>>
>> "authorization_endpoint": "https://server.example.com/authorize" <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>,
>>
>> 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:***@oracle.com <mailto:***@oracle.com>]
>> Sent: Wednesday, February 24, 2016 12:45 PM
>> To: Anthony Nadalin <***@microsoft.com> <mailto:***@microsoft.com>
>> Cc: Mike Jones <***@microsoft.com> <mailto:***@microsoft.com>; <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> Mike
>>
>> Publishing on dev pages does not work for software (esp open source) that is deployed both in enterprises and on PaaS cloud providers.
>>
>> The current draft is may codify current OIDC practice and be appropriate for oidc but it is not ready for generic oauth. There is no generic oauth experience at this time.
>>
>> Phil
>>
>> On Feb 24, 2016, at 10:25, Anthony Nadalin <***@microsoft.com> <mailto:***@microsoft.com> wrote:
>>
>> Sure there is, it is as you have now made it far easier and the security considerations does not even address this
>>
>> From: Mike Jones
>> Sent: Wednesday, February 24, 2016 10:22 AM
>> To: Anthony Nadalin <***@microsoft.com> <mailto:***@microsoft.com>
>> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> As we’d discussed in person, there’s no effective security difference between discovery information being published in an ad-hoc fashion on developer pages and it being published in a standard format. “Security by obscurity” adds no real security at all.
>>
>> -- Mike
>>
>> From: Anthony Nadalin
>> Sent: Wednesday, February 24, 2016 10:01 AM
>> To: Mike Jones <***@microsoft.com> <mailto:***@microsoft.com>; Phil Hunt (IDM) <***@oracle.com> <mailto:***@oracle.com>; Nat Sakimura <***@gmail.com> <mailto:***@gmail.com>
>> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>>
>> That may be widely deployed for OIDC but not widely deployed for OAuth. There are some authentication mechanism discovery for endpoint that really should not be in an OAuth standard since it’s really not dealt with. Now that all this information is available it makes poking around the endpoint more focused for people that want to disrupt your endpoints, that is really not addressed in the security considerations section at all
>>
>> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org>] On Behalf Of Mike Jones
>> Sent: Wednesday, February 24, 2016 9:54 AM
>> To: Phil Hunt (IDM) <***@oracle.com> <mailto:***@oracle.com>; Nat Sakimura <***@gmail.com> <mailto:***@gmail.com>
>> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>>
>> None of Nat or John or I are suggesting that additional related functionality won’t be created. I’m sure it will be. Some applications will use WebFinger to locate the discovery metadata. Some will possibly use link headers. Some will possibly use application-specific .well-known values. I’m sure there’s other things I haven’t even thought about. All of these depend upon having a discovery metadata document format and none of them change it – other than possibly to register additional discovery metadata values.
>>
>> So by all means, the working group should continue discussing inventing possible new related mechanisms that make sense in some contexts. At the same time, we can finish standardizing the already widely deployed core functionality that all of these mechanisms will need.
>>
>> -- Mike
>>
>> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org>] On Behalf Of Phil Hunt (IDM)
>> Sent: Wednesday, February 24, 2016 8:39 AM
>> To: Nat Sakimura <***@gmail.com> <mailto:***@gmail.com>
>> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> I am suggesting that part of the discovery solution has to be the client indicating what resource endpoint it wants the oauth configuration data for.
>>
>> So if res.example.evil.com <http://res.example.evil.com/> is not a valid resource endpoint for as.example.com <http://as.example.com/> the authz discovery should fail in some way (eg return nothing).
>>
>> There may be better ways to do this. Eg combine discovery. Or change the order of discovery.
>>
>> One of OAuth's strength's and weaknesses is that the target of authorization (the resource) is never specified. It is often bound up in the client registration and an often implied 1:1 relationship between resource and as. Given that in discovery phase registration has not yet occurred it seems important that the client know it has a valid combination of endpoints etc.
>>
>> This is why I was disappointed about wglc on discovery. We had a starting point for group adoption but we haven't really defined the full requirements IMO.
>>
>> I am on vacation or I would put some thought into some draft changes or a new draft. I apologize I can't do it now.
>>
>> Phil
>>
>> On Feb 24, 2016, at 08:12, Nat Sakimura <***@gmail.com> <mailto:***@gmail.com> wrote:
>>
>> Hi Phil,
>>
>> Are you suggesting that the AS metadata should include the RS URIs? Currently, it does not, but it can be done, I guess.
>>
>> The way oauth-meta works is that
>>
>> 1. RS tells the client where the AS is.
>> 2. AS tells the client which RS endpoints the token can be used.
>>
>> Even if there is a bad AS with a valid certs that proxies to the good RS, the client will not send the token there as the authz server will say that is not the place the client may want to send the token to.
>>
>> Nat
>>
>> 2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com> <mailto:***@oracle.com>:
>> Nat,
>>
>> I’m not sure that having the resource server tell the client where its authorization server is secure by itself. The relationship between the Authorization Server and the Resource server need to be bound together in one of the discovery endpoints (the resource and/or the oauth service discovery).
>>
>> If a client discovers a fake resource server that is proxying for a real resource server the current discovery spec will not lead the client to understand it has the wrong resource server. Rather the fake resource service will just have a fake discovery service. The hacker can now intercept resource payload as well as tokens because they were able to convince the client to use the legit authorization service but use the token against the hackers proxy.
>>
>> The OAuth Discovery service needs to confirm to the client that the server is able to issue tokens for a stated resource endpoint.
>>
>> This not only works in normal OAuth but should add security even to UMA situations.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com <http://www.independentid.com/>
>> ***@oracle.com <mailto:***@oracle.com>
>>
>>
>>
>>
>>
>> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <***@gmail.com> <mailto:***@gmail.com> wrote:
>>
>>
>> Hi Thomas,
>>
>> inline:
>>
>> 2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com> <mailto:***@gmail.com>:
>> Couldn't the document only describe the metadata?
>> I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".
>> The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).
>> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed
>>
>> Yup. That's one of the requirements to be RESTful, is it not?
>>
>> In OAuth's case, the resource and 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 <***@mit.edu> <mailto:***@mit.edu> wrote:
>> The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.
>>
>> I propose that we use “/.well-known/oauth-authorization-server” as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration” if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.
>>
>> — Justin
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>
>> --
>> Vladimir Dzhuvinov :: ***@connect2id.com <mailto:***@connect2id.com>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

[Mike Jones]

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

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

-- Mike

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


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

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



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



Resource Discovery



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

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







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







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

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

Vladimir








Phil



@independentid

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











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



+1 for “OAuth 2.0 Authorization Server Discovery”



//Samuel



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

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







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







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







In summary, which title do people prefer?



· “OAuth 2.0 Discovery”



· “OAuth 2.0 Authorization Server Discovery”







-- Mike



<>

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

Sent: Thursday, February 25, 2016 12:59 AM

To: ***@ietf.org<mailto:***@ietf.org> <mailto:***@ietf.org><mailto:***@ietf.org>



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







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



Here are some example OIDC discovery docs:



https://accounts.google.com/.well-known/openid-configuration <https://accounts.google.com/.well-known/openid-configuration><https://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>





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



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





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



Cheers,



Vladimir









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



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



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



Phil



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



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



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



-- Mike



From: Phil Hunt (IDM) [mailto:***@oracle.com <mailto:***@oracle.com><mailto:***@oracle.com>]

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

To: Mike Jones

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

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



Mike



Take a look at the assumptions you are making.



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



Would ms azure allow custom arch?



Phil



On Feb 24, 2016, at 15:28, Mike Jones <***@microsoft.com><mailto:***@microsoft.com> <mailto:***@microsoft.com><mailto:***@microsoft.com> wrote:



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



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



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



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



-- Mike



From: Phil Hunt (IDM) [mailto:***@oracle.com <mailto:***@oracle.com><mailto:***@oracle.com>]

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

To: Mike Jones <***@microsoft.com><mailto:***@microsoft.com> <mailto:***@microsoft.com><mailto:***@microsoft.com>

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

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



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



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



Phil



On Feb 24, 2016, at 14:05, Mike Jones <***@microsoft.com><mailto:***@microsoft.com> <mailto:***@microsoft.com><mailto:***@microsoft.com> wrote:



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

Sent: Wednesday, February 24, 2016 1:25 PM

To: Mike Jones

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

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



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



Phil



On Feb 24, 2016, at 13:09, Mike Jones <***@microsoft.com><mailto:***@microsoft.com> <mailto:***@microsoft.com><mailto:***@microsoft.com> wrote:



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



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



"authorization_endpoint": "https://server.example.com/authorize"<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>,

"token_endpoint_auth_methods_supported": ["client_secret_basic", "private_key_jwt"],

"registration_endpoint": "https://server.example.com/register"<https://server.example.com/register> <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> <http://server.example.com/service_documentation.html><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:***@oracle.com <mailto:***@oracle.com><mailto:***@oracle.com>]

Sent: Wednesday, February 24, 2016 12:45 PM

To: Anthony Nadalin <***@microsoft.com><mailto:***@microsoft.com> <mailto:***@microsoft.com><mailto:***@microsoft.com>

Cc: Mike Jones <***@microsoft.com><mailto:***@microsoft.com> <mailto:***@microsoft.com><mailto:***@microsoft.com>; <***@ietf.org><mailto:***@ietf.org> <mailto:***@ietf.org><mailto:***@ietf.org> <***@ietf.org><mailto:***@ietf.org> <mailto:***@ietf.org><mailto:***@ietf.org>

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



Mike



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



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



Phil



On Feb 24, 2016, at 10:25, Anthony Nadalin <***@microsoft.com><mailto:***@microsoft.com> <mailto:***@microsoft.com><mailto:***@microsoft.com> wrote:



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



From: Mike Jones

Sent: Wednesday, February 24, 2016 10:22 AM

To: Anthony Nadalin <***@microsoft.com><mailto:***@microsoft.com> <mailto:***@microsoft.com><mailto:***@microsoft.com>

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

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



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



-- Mike



From: Anthony Nadalin

Sent: Wednesday, February 24, 2016 10:01 AM

To: Mike Jones <***@microsoft.com><mailto:***@microsoft.com> <mailto:***@microsoft.com><mailto:***@microsoft.com>; Phil Hunt (IDM) <***@oracle.com><mailto:***@oracle.com> <mailto:***@oracle.com><mailto:***@oracle.com>; Nat Sakimura <***@gmail.com><mailto:***@gmail.com> <mailto:***@gmail.com><mailto:***@gmail.com>

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

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



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



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



From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org><mailto:oauth-***@ietf.org>] On Behalf Of Mike Jones

Sent: Wednesday, February 24, 2016 9:54 AM

To: Phil Hunt (IDM) <***@oracle.com><mailto:***@oracle.com> <mailto:***@oracle.com><mailto:***@oracle.com>; Nat Sakimura <***@gmail.com><mailto:***@gmail.com> <mailto:***@gmail.com><mailto:***@gmail.com>

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

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



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



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



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



-- Mike



From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org><mailto:oauth-***@ietf.org>] On Behalf Of Phil Hunt (IDM)

Sent: Wednesday, February 24, 2016 8:39 AM

To: Nat Sakimura <***@gmail.com><mailto:***@gmail.com> <mailto:***@gmail.com><mailto:***@gmail.com>

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

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



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



So if res.example.evil.com <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).



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 <***@gmail.com><mailto:***@gmail.com> <mailto:***@gmail.com><mailto:***@gmail.com> wrote:



Hi Phil,



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



The way oauth-meta works is that



1. RS tells the client where the AS is.

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



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



Nat



2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com><mailto:***@oracle.com> <mailto:***@oracle.com><mailto:***@oracle.com>:

Nat,



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



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



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



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



Phil



@independentid

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

***@oracle.com<mailto:***@oracle.com> <mailto:***@oracle.com><mailto:***@oracle.com>











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





Hi Thomas,



inline:



2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com><mailto:***@gmail.com> <mailto:***@gmail.com><mailto:***@gmail.com>:

Couldn't the document only describe the metadata?

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

The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).

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



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



In OAuth's case, the resource and 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 <***@mit.edu><mailto:***@mit.edu> <mailto:***@mit.edu><mailto:***@mit.edu> wrote:

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



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



— Justin

_______________________________________________

OAuth mailing list

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

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

_______________________________________________

OAuth mailing list

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

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

_______________________________________________

OAuth mailing list

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

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



_______________________________________________

OAuth mailing list

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

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











_______________________________________________

OAuth mailing list

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

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





--

Vladimir Dzhuvinov :: ***@connect2id.com<mailto:***@connect2id.com> <mailto:***@connect2id.com><mailto:***@connect2id.com>

_______________________________________________

OAuth mailing list

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

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





_______________________________________________

OAuth mailing list

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

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








_______________________________________________

OAuth mailing list

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

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

[Phil Hunt]

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

What I am suggesting is much simpler.

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

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

Phil

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





> On Feb 27, 2016, at 10:38 AM, Mike Jones <***@microsoft.com> wrote:
>
> Thanks for taking the time to propose specific text, Phil. That’s really helpful. I’ll plan to incorporate a version of this in the draft addressing WGLC comments.
>
> I agree with Vladimir’s observation that it’s difficult to come up with a general-purpose resource discovery mechanism. That in part, is because, as Brian points out, there’s often not a 1:1 relationship between authorization servers and resource servers. As I’ve written before, I do encourage the working group to work on creating solutions to resource discovery that will work for some common use cases. But the good news is that while resource discovery requires new invention, authorization server discovery does not.
>
> -- Mike
>   <>
> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Vladimir Dzhuvinov
> Sent: Saturday, February 27, 2016 10:33 AM
> To: ***@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> On 27/02/16 20:10, Phil Hunt wrote:
> The name change seems appropriate given that the WG members have decided not to address the issue of resource discovery as part of this specification.
>
> If the consensus is to limit the scope of the specification, then I suggest the following security considerations text.
>
> Resource Discovery
>
> Secure discovery of resource endpoints is out-of-scope of this specification. This specification assumes that the client has already securely discovered the correct resource endpoint and that the client has correctly selected the correct corresponding discovery for OAuth Authorization server. Implementers MUST consider that if an incorrect resource endpoint was discovered by the client that an attacker will be able to set up a man-in-the-middle proxy to a real resource server without detection by the authorization server or the client.
>
> I support that. This was the primary concern of everyone who felt uncomfortable with the original draft with WebFinger-based discovery in it, so it should be included.
>
>
>
>
>
> It may be more appropriate to even include this text in the introduction as a cautionary "red flag" to implementers.
> +1
>
>
>
>
> Once again, I strongly urge the WG to actually include a method for the client to discovery that the oauth cliet has correctly discovered an authorization server that is willing and able to issue access tokens for a given resource endpoint. I believe this relationship is critical to security of OAuth in cases where resource endpoints are discovered dynamically. Of course willing and able means that the AS believes that the endpoint is legitimate.
>
> The more I think about this topic, the more pessimistic I get that there is a good solution to this :)
>
> Vladimir
>
>
>
>
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com/> <http://www.independentid.com/> <http://www.independentid.com/>***@oracle.com <mailto:***@oracle.com> <mailto:***@oracle.com> <mailto:***@oracle.com>
>
>
>
>
>
> On Feb 27, 2016, at 6:46 AM, Samuel Erdtman <***@erdtman.se> <mailto:***@erdtman.se> wrote:
>
> +1 for “OAuth 2.0 Authorization Server Discovery”
>
> //Samuel
>
> On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones <***@microsoft.com <mailto:***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com>> wrote:
> Thanks for your thoughts, Vladimir. I’m increasingly inclined to accept your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0 Authorization Server Discovery”. While the abstract already makes it clear that the scope of the document is AS discovery, doing so in the title seems like it could help clarify things, given that a lot of the discussion seems to be about resource discovery, which is out of scope of the document.
>
>
>
> I’m not saying that resource discovery isn’t important – it is – but unlike authorization server discovery, where there’s lots of existing practice, including using the existing data format for describing OAuth implementations that aren’t being used with OpenID Connect, there’s no existing practice to standardize for resource discovery. The time to create a standard for that seems to be after existing practice has emerged. It *might* or might not use new metadata values in the AS discovery document, but that’s still to be determined. The one reason to leave the title as-is is that resource discovery might end up involving extensions to this metadata format in some cases.
>
>
>
> I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 applies. 6749 is about the AS. 6750 is about the RS. The discovery document is about the AS. We don’t yet have a specification or existing practice for RS discovery, which would be the 6750 analogy.
>
>
>
> In summary, which title do people prefer?
>
> · “OAuth 2.0 Discovery”
>
> · “OAuth 2.0 Authorization Server Discovery”
>
>
>
> -- Mike
>
> <>
> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org> <mailto:oauth-***@ietf.org> <mailto:oauth-***@ietf.org>] On Behalf Of Vladimir Dzhuvinov
> Sent: Thursday, February 25, 2016 12:59 AM
> To: ***@ietf.org <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org>
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> In OIDC the discovery doc is of great utility to developers and integrators. Developers also tend to find it a more accurate and complete description of how to set up a client for a particular deployment, compared to traditional online docs, which may be not be up to date, or even missing. Very much like auto-generated Swagger and JavaDocs.
>
> Here are some example OIDC discovery docs:
>
> https://accounts.google.com/.well-known/openid-configuration <https://accounts.google.com/.well-known/openid-configuration> <https://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>
>
>
> With this discovery document in place setup of identity federation can then be easily scripted. For example:
>
> http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html <http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html> <http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html> <http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html>
>
>
> Now, does that dictate any particular app architecture? My reading of the spec is that it doesn't, and it shouldn't either. By staying neutral on the topics of RS discovery and registering RPs with RSs. And how one arrives at the ".well-known/...". I'm not even sure that resource discovery should be a topic of this WG. Perhaps to this end, and to prevent confusion that the spec is trying to do something more, a more specific title would suit it better. E.g. "AS Discovery".
>
> Cheers,
>
> Vladimir
>
>
>
>
> On 25/02/16 02:25, Phil Hunt (IDM) wrote:
>
> And so does oracle and so does google. Each different.
>
> So how can an app dictate it then unless we all go to a common architecture?
>
> Phil
>
> On Feb 24, 2016, at 16:04, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com> wrote:
>
> Azure defines ways for resource servers to be registered for use with a client and for clients to dynamically request an access token for use at a particular resource server. You can call that custom architecture if you want. It’s well-defined but it’s not currently in the standards realm. I know that Google has syntax for doing the same, as I’m sure do a lot of other cloud OAuth deployments, such as Oracle’s. For what it’s worth, the working group talked about possibly producing a standard version of syntax for making these kinds of requests during our discussions in Prague (during the Token Exchange discussion) but nobody has run with this yet.
>
> In this sense, yes, Azure is an application of the kind we’re talking about. Azure already does define specific new OAuth 2.0 discovery metadata values that are used in production. A registry just doesn’t yet exist in which it can register those that are of general applicability.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com <mailto:***@oracle.com> <mailto:***@oracle.com> <mailto:***@oracle.com>]
> Sent: Wednesday, February 24, 2016 3:52 PM
> To: Mike Jones
> Cc: <***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Mike
>
> Take a look at the assumptions you are making.
>
> You seem to be assuming application software dictates oauth infrastructure architecture by suggesting that apps register in iana.
>
> Would ms azure allow custom arch?
>
> Phil
>
> On Feb 24, 2016, at 15:28, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com> wrote:
>
> The UserInfo Endpoint path isn’t fixed and so has to be discovered.
>
> I agree that for some OAuth profiles, one or more resource servers will have to be discovered starting from the authorization server. Working group members have also described wanting to discover authorization servers starting from resource servers. There isn’t a standard practice for any of this, which is why it’s intentionally left out of the current specification.
>
> Once the IANA OAuth Discovery Metadata Registry has been established, which will happen after the current specification has been approved, it will be easy for subsequent specifications to document existing practice for different OAuth profiles and register discovery metadata values supporting them. Some of those values will likely define ways to discover resource servers, when applicable.
>
> But first, we need to finish the existing spec, so that the registry enabling these extensions gets established in the first place.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:***@oracle.com <mailto:***@oracle.com> <mailto:***@oracle.com> <mailto:***@oracle.com>]
> Sent: Wednesday, February 24, 2016 2:13 PM
> To: Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com>
> Cc: <***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Yup. And because there many relations the client mist be able to discover it. The client does not know if the res server is legit.
>
> The userinfo is always fix and so u dont need discovery.
>
> Phil
>
> On Feb 24, 2016, at 14:05, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com> wrote:
>
> In OpenID Connect, there’s a resource server called the UserInfo Endpoint that returns claims about the authenticated user as a JSON data structure. Its location is published in OpenID Connect discovery metadata as the “userinfo_endpoint” metadata value, which is defined at http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata <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>.
>
> 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:***@oracle.com <mailto:***@oracle.com> <mailto:***@oracle.com> <mailto:***@oracle.com>]
> Sent: Wednesday, February 24, 2016 1:25 PM
> To: Mike Jones
> Cc: <***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Where is the profile endpoint (oidc's resource server) published? (For the non OIDC people on the list).
>
> Phil
>
> On Feb 24, 2016, at 13:09, Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com> wrote:
>
> To the extent that generic OAuth 2.0 needs to publish some of the same information as OpenID Connect – which is built on generic OAuth 2.0 – it makes sense to publish that information using exactly the same syntax, since that syntax is already in widespread use. That what this draft accomplishes.
>
> There’s nothing Connect-specific about using metadata response values like:
>
> "authorization_endpoint": "https://server.example.com/authorize" <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>,
> "token_endpoint_auth_methods_supported": ["client_secret_basic", "private_key_jwt"],
> "registration_endpoint": "https://server.example.com/register" <https://server.example.com/register> <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> <http://server.example.com/service_documentation.html> <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:***@oracle.com <mailto:***@oracle.com> <mailto:***@oracle.com> <mailto:***@oracle.com>]
> Sent: Wednesday, February 24, 2016 12:45 PM
> To: Anthony Nadalin <***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com>
> Cc: Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com>; <***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> Mike
>
> Publishing on dev pages does not work for software (esp open source) that is deployed both in enterprises and on PaaS cloud providers.
>
> The current draft is may codify current OIDC practice and be appropriate for oidc but it is not ready for generic oauth. There is no generic oauth experience at this time.
>
> Phil
>
> On Feb 24, 2016, at 10:25, Anthony Nadalin <***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com> wrote:
>
> Sure there is, it is as you have now made it far easier and the security considerations does not even address this
>
> From: Mike Jones
> Sent: Wednesday, February 24, 2016 10:22 AM
> To: Anthony Nadalin <***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com>
> Cc: <***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org>
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> As we’d discussed in person, there’s no effective security difference between discovery information being published in an ad-hoc fashion on developer pages and it being published in a standard format. “Security by obscurity” adds no real security at all.
>
> -- Mike
>
> From: Anthony Nadalin
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones <***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com> <mailto:***@microsoft.com>; Phil Hunt (IDM) <***@oracle.com> <mailto:***@oracle.com> <mailto:***@oracle.com> <mailto:***@oracle.com>; Nat Sakimura <***@gmail.com> <mailto:***@gmail.com> <mailto:***@gmail.com> <mailto:***@gmail.com>
> Cc: <***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org>
> Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
> That may be widely deployed for OIDC but not widely deployed for OAuth. There are some authentication mechanism discovery for endpoint that really should not be in an OAuth standard since it’s really not dealt with. Now that all this information is available it makes poking around the endpoint more focused for people that want to disrupt your endpoints, that is really not addressed in the security considerations section at all
>
> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org> <mailto:oauth-***@ietf.org> <mailto:oauth-***@ietf.org>] On Behalf Of Mike Jones
> Sent: Wednesday, February 24, 2016 9:54 AM
> To: Phil Hunt (IDM) <***@oracle.com> <mailto:***@oracle.com> <mailto:***@oracle.com> <mailto:***@oracle.com>; Nat Sakimura <***@gmail.com> <mailto:***@gmail.com> <mailto:***@gmail.com> <mailto:***@gmail.com>
> Cc: <***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.
>
> None of Nat or John or I are suggesting that additional related functionality won’t be created. I’m sure it will be. Some applications will use WebFinger to locate the discovery metadata. Some will possibly use link headers. Some will possibly use application-specific .well-known values. I’m sure there’s other things I haven’t even thought about. All of these depend upon having a discovery metadata document format and none of them change it – other than possibly to register additional discovery metadata values.
>
> So by all means, the working group should continue discussing inventing possible new related mechanisms that make sense in some contexts. At the same time, we can finish standardizing the already widely deployed core functionality that all of these mechanisms will need.
>
> -- Mike
>
> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org> <mailto:oauth-***@ietf.org> <mailto:oauth-***@ietf.org>] On Behalf Of Phil Hunt (IDM)
> Sent: Wednesday, February 24, 2016 8:39 AM
> To: Nat Sakimura <***@gmail.com> <mailto:***@gmail.com> <mailto:***@gmail.com> <mailto:***@gmail.com>
> Cc: <***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> I am suggesting that part of the discovery solution has to be the client indicating what resource endpoint it wants the oauth configuration data for.
>
> So if res.example.evil.com <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).
>
> 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 <***@gmail.com> <mailto:***@gmail.com> <mailto:***@gmail.com> <mailto:***@gmail.com> wrote:
>
> Hi Phil,
>
> Are you suggesting that the AS metadata should include the RS URIs? Currently, it does not, but it can be done, I guess.
>
> The way oauth-meta works is that
>
> 1. RS tells the client where the AS is.
> 2. AS tells the client which RS endpoints the token can be used.
>
> Even if there is a bad AS with a valid certs that proxies to the good RS, the client will not send the token there as the authz server will say that is not the place the client may want to send the token to.
>
> Nat
>
> 2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com> <mailto:***@oracle.com> <mailto:***@oracle.com> <mailto:***@oracle.com>:
> Nat,
>
> I’m not sure that having the resource server tell the client where its authorization server is secure by itself. The relationship between the Authorization Server and the Resource server need to be bound together in one of the discovery endpoints (the resource and/or the oauth service discovery).
>
> If a client discovers a fake resource server that is proxying for a real resource server the current discovery spec will not lead the client to understand it has the wrong resource server. Rather the fake resource service will just have a fake discovery service. The hacker can now intercept resource payload as well as tokens because they were able to convince the client to use the legit authorization service but use the token against the hackers proxy.
>
> The OAuth Discovery service needs to confirm to the client that the server is able to issue tokens for a stated resource endpoint.
>
> This not only works in normal OAuth but should add security even to UMA situations.
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com/> <http://www.independentid.com/> <http://www.independentid.com/>
> ***@oracle.com <mailto:***@oracle.com> <mailto:***@oracle.com> <mailto:***@oracle.com>
>
>
>
>
>
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <***@gmail.com> <mailto:***@gmail.com> <mailto:***@gmail.com> <mailto:***@gmail.com> wrote:
>
>
> Hi Thomas,
>
> inline:
>
> 2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com> <mailto:***@gmail.com> <mailto:***@gmail.com> <mailto:***@gmail.com>:
> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed
>
> Yup. That's one of the requirements to be RESTful, is it not?
>
> In OAuth's case, the resource and 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 <***@mit.edu> <mailto:***@mit.edu> <mailto:***@mit.edu> <mailto:***@mit.edu> wrote:
> The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.
>
> I propose that we use “/.well-known/oauth-authorization-server” as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration” if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.
>
> — Justin
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org>
> 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>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org>
> 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>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org>
> 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>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org>
> 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>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org>
> 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 :: ***@connect2id.com <mailto:***@connect2id.com> <mailto:***@connect2id.com> <mailto:***@connect2id.com>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org> <mailto:***@ietf.org> <mailto:***@ietf.org>
> 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>
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

[Mike Jones]

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

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

-- Mike

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

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

What I am suggesting is much simpler.

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

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

Phil

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




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

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

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

-- Mike

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


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

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



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



Resource Discovery



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

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








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








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

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

Vladimir









Phil



@independentid

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











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



+1 for “OAuth 2.0 Authorization Server Discovery”



//Samuel



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

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







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







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







In summary, which title do people prefer?



· “OAuth 2.0 Discovery”



· “OAuth 2.0 Authorization Server Discovery”







-- Mike



<>

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

Sent: Thursday, February 25, 2016 12:59 AM

To: ***@ietf.org<mailto:***@ietf.org> <mailto:***@ietf.org><mailto:***@ietf.org>



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







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



Here are some example OIDC discovery docs:



https://accounts.google.com/.well-known/openid-configuration <https://accounts.google.com/.well-known/openid-configuration><https://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>





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



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





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



Cheers,



Vladimir









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



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



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



Phil



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



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



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



-- Mike



From: Phil Hunt (IDM) [mailto:***@oracle.com <mailto:***@oracle.com><mailto:***@oracle.com>]

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

To: Mike Jones

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

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



Mike



Take a look at the assumptions you are making.



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



Would ms azure allow custom arch?



Phil



On Feb 24, 2016, at 15:28, Mike Jones <***@microsoft.com><mailto:***@microsoft.com> <mailto:***@microsoft.com><mailto:***@microsoft.com> wrote:



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



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



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



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



-- Mike



From: Phil Hunt (IDM) [mailto:***@oracle.com <mailto:***@oracle.com><mailto:***@oracle.com>]

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

To: Mike Jones <***@microsoft.com><mailto:***@microsoft.com> <mailto:***@microsoft.com><mailto:***@microsoft.com>

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

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



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



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



Phil



On Feb 24, 2016, at 14:05, Mike Jones <***@microsoft.com><mailto:***@microsoft.com> <mailto:***@microsoft.com><mailto:***@microsoft.com> wrote:



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

Sent: Wednesday, February 24, 2016 1:25 PM

To: Mike Jones

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

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



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



Phil



On Feb 24, 2016, at 13:09, Mike Jones <***@microsoft.com><mailto:***@microsoft.com> <mailto:***@microsoft.com><mailto:***@microsoft.com> wrote:



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



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



"authorization_endpoint": "https://server.example.com/authorize"<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>,

"token_endpoint_auth_methods_supported": ["client_secret_basic", "private_key_jwt"],

"registration_endpoint": "https://server.example.com/register"<https://server.example.com/register> <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> <http://server.example.com/service_documentation.html><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:***@oracle.com <mailto:***@oracle.com><mailto:***@oracle.com>]

Sent: Wednesday, February 24, 2016 12:45 PM

To: Anthony Nadalin <***@microsoft.com><mailto:***@microsoft.com> <mailto:***@microsoft.com><mailto:***@microsoft.com>

Cc: Mike Jones <***@microsoft.com><mailto:***@microsoft.com> <mailto:***@microsoft.com><mailto:***@microsoft.com>; <***@ietf.org><mailto:***@ietf.org> <mailto:***@ietf.org><mailto:***@ietf.org> <***@ietf.org><mailto:***@ietf.org> <mailto:***@ietf.org><mailto:***@ietf.org>

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



Mike



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



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



Phil



On Feb 24, 2016, at 10:25, Anthony Nadalin <***@microsoft.com><mailto:***@microsoft.com> <mailto:***@microsoft.com><mailto:***@microsoft.com> wrote:



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



From: Mike Jones

Sent: Wednesday, February 24, 2016 10:22 AM

To: Anthony Nadalin <***@microsoft.com><mailto:***@microsoft.com> <mailto:***@microsoft.com><mailto:***@microsoft.com>

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

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



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



-- Mike



From: Anthony Nadalin

Sent: Wednesday, February 24, 2016 10:01 AM

To: Mike Jones <***@microsoft.com><mailto:***@microsoft.com> <mailto:***@microsoft.com><mailto:***@microsoft.com>; Phil Hunt (IDM) <***@oracle.com><mailto:***@oracle.com> <mailto:***@oracle.com><mailto:***@oracle.com>; Nat Sakimura <***@gmail.com><mailto:***@gmail.com> <mailto:***@gmail.com><mailto:***@gmail.com>

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

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



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



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



From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org><mailto:oauth-***@ietf.org>] On Behalf Of Mike Jones

Sent: Wednesday, February 24, 2016 9:54 AM

To: Phil Hunt (IDM) <***@oracle.com><mailto:***@oracle.com> <mailto:***@oracle.com><mailto:***@oracle.com>; Nat Sakimura <***@gmail.com><mailto:***@gmail.com> <mailto:***@gmail.com><mailto:***@gmail.com>

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

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



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



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



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



-- Mike



From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org><mailto:oauth-***@ietf.org>] On Behalf Of Phil Hunt (IDM)

Sent: Wednesday, February 24, 2016 8:39 AM

To: Nat Sakimura <***@gmail.com><mailto:***@gmail.com> <mailto:***@gmail.com><mailto:***@gmail.com>

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

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



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



So if res.example.evil.com<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).



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 <***@gmail.com><mailto:***@gmail.com> <mailto:***@gmail.com><mailto:***@gmail.com> wrote:



Hi Phil,



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



The way oauth-meta works is that



1. RS tells the client where the AS is.

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



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



Nat



2016幎2月24日(æ°Ž) 23:59 Phil Hunt <***@oracle.com><mailto:***@oracle.com> <mailto:***@oracle.com><mailto:***@oracle.com>:

Nat,



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



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



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



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



Phil



@independentid

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

***@oracle.com<mailto:***@oracle.com> <mailto:***@oracle.com><mailto:***@oracle.com>











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





Hi Thomas,



inline:



2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com><mailto:***@gmail.com> <mailto:***@gmail.com><mailto:***@gmail.com>:

Couldn't the document only describe the metadata?

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

The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).

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



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



In OAuth's case, the resource and 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 <***@mit.edu><mailto:***@mit.edu> <mailto:***@mit.edu><mailto:***@mit.edu> wrote:

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



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



— Justin

_______________________________________________

OAuth mailing list

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

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

_______________________________________________

OAuth mailing list

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

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

_______________________________________________

OAuth mailing list

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

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



_______________________________________________

OAuth mailing list

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

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











_______________________________________________

OAuth mailing list

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

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





--

Vladimir Dzhuvinov :: ***@connect2id.com<mailto:***@connect2id.com> <mailto:***@connect2id.com><mailto:***@connect2id.com>

_______________________________________________

OAuth mailing list

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

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





_______________________________________________

OAuth mailing list

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

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









_______________________________________________

OAuth mailing list

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

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

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

[Donald F. Coffin]

+1 for “OAuth 2.0 Authorization Server Discovery”



Best regards,

Don

Donald F. Coffin

Founder/CTO



REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221



Phone: [phone]

Email: <mailto:***@reminetworks.com> ***@reminetworks.com



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



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



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



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



In summary, which title do people prefer?

* “OAuth 2.0 Discovery”

* “OAuth 2.0 Authorization Server Discovery”



-- Mike



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



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

Here are some example OIDC discovery docs:

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

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

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


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

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


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

Cheers,

Vladimir




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

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

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

Phil


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

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

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

-- Mike

From: Phil Hunt (IDM) [mailto:***@oracle.com]
Sent: Wednesday, February 24, 2016 3:52 PM
To: Mike Jones
Cc: <mailto:***@ietf.org> <***@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Mike

Take a look at the assumptions you are making.

You seem to be assuming application software dictates oauth infrastructure architecture by suggesting that apps register in iana.

Would ms azure allow custom arch?

Phil

On Feb 24, 2016, at 15:28, Mike Jones <mailto:***@microsoft.com> <***@microsoft.com> wrote:

The UserInfo Endpoint path isn’t fixed and so has to be discovered.

I agree that for some OAuth profiles, one or more resource servers will have to be discovered starting from the authorization server. Working group members have also described wanting to discover authorization servers starting from resource servers. There isn’t a standard practice for any of this, which is why it’s intentionally left out of the current specification.

Once the IANA OAuth Discovery Metadata Registry has been established, which will happen after the current specification has been approved, it will be easy for subsequent specifications to document existing practice for different OAuth profiles and register discovery metadata values supporting them. Some of those values will likely define ways to discover resource servers, when applicable.

But first, we need to finish the existing spec, so that the registry enabling these extensions gets established in the first place.

-- Mike

From: Phil Hunt (IDM) [mailto:***@oracle.com]
Sent: Wednesday, February 24, 2016 2:13 PM
To: Mike Jones <mailto:***@microsoft.com> <***@microsoft.com>
Cc: <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Yup. And because there many relations the client mist be able to discover it. The client does not know if the res server is legit.

The userinfo is always fix and so u dont need discovery.

Phil

On Feb 24, 2016, at 14:05, Mike Jones <mailto:***@microsoft.com> <***@microsoft.com> wrote:

In OpenID Connect, there’s a resource server called the UserInfo Endpoint that returns claims about the authenticated user as a JSON data structure. Its location is published in OpenID Connect discovery metadata as the “userinfo_endpoint” metadata value, which is defined at http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.

We didn’t include the UserInfo Endpoint in the generic OAuth discovery spec since in OAuth, there are lots of possible relationships between authorization servers and resource servers and they needn’t be one-to-one, as is being actively discussed by the working group. For instance, see George Fletcher’s recent contribution.

Thanks for the good discussion, Phil.

-- Mike

From: Phil Hunt (IDM) [mailto:***@oracle.com]
Sent: Wednesday, February 24, 2016 1:25 PM
To: Mike Jones
Cc: <mailto:***@ietf.org> <***@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Where is the profile endpoint (oidc's resource server) published? (For the non OIDC people on the list).

Phil

On Feb 24, 2016, at 13:09, Mike Jones <mailto:***@microsoft.com> <***@microsoft.com> wrote:

To the extent that generic OAuth 2.0 needs to publish some of the same information as OpenID Connect – which is built on generic OAuth 2.0 – it makes sense to publish that information using exactly the same syntax, since that syntax is already in widespread use. That what this draft accomplishes.

There’s nothing Connect-specific about using metadata response values like:

"authorization_endpoint": <https://server.example.com/authorize> "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",

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:***@oracle.com]
Sent: Wednesday, February 24, 2016 12:45 PM
To: Anthony Nadalin <mailto:***@microsoft.com> <***@microsoft.com>
Cc: Mike Jones <mailto:***@microsoft.com> <***@microsoft.com>; <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Mike

Publishing on dev pages does not work for software (esp open source) that is deployed both in enterprises and on PaaS cloud providers.

The current draft is may codify current OIDC practice and be appropriate for oidc but it is not ready for generic oauth. There is no generic oauth experience at this time.

Phil

On Feb 24, 2016, at 10:25, Anthony Nadalin <mailto:***@microsoft.com> <***@microsoft.com> wrote:

Sure there is, it is as you have now made it far easier and the security considerations does not even address this

From: Mike Jones
Sent: Wednesday, February 24, 2016 10:22 AM
To: Anthony Nadalin <mailto:***@microsoft.com> <***@microsoft.com>
Cc: <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location

As we’d discussed in person, there’s no effective security difference between discovery information being published in an ad-hoc fashion on developer pages and it being published in a standard format. “Security by obscurity” adds no real security at all.

-- Mike

From: Anthony Nadalin
Sent: Wednesday, February 24, 2016 10:01 AM
To: Mike Jones <mailto:***@microsoft.com> <***@microsoft.com>; Phil Hunt (IDM) <mailto:***@oracle.com> <***@oracle.com>; Nat Sakimura <mailto:***@gmail.com> <***@gmail.com>
Cc: <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location


The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.


That may be widely deployed for OIDC but not widely deployed for OAuth. There are some authentication mechanism discovery for endpoint that really should not be in an OAuth standard since it’s really not dealt with. Now that all this information is available it makes poking around the endpoint more focused for people that want to disrupt your endpoints, that is really not addressed in the security considerations section at all

From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, February 24, 2016 9:54 AM
To: Phil Hunt (IDM) <mailto:***@oracle.com> <***@oracle.com>; Nat Sakimura <mailto:***@gmail.com> <***@gmail.com>
Cc: <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.

None of Nat or John or I are suggesting that additional related functionality won’t be created. I’m sure it will be. Some applications will use WebFinger to locate the discovery metadata. Some will possibly use link headers. Some will possibly use application-specific .well-known values. I’m sure there’s other things I haven’t even thought about. All of these depend upon having a discovery metadata document format and none of them change it – other than possibly to register additional discovery metadata values.

So by all means, the working group should continue discussing inventing possible new related mechanisms that make sense in some contexts. At the same time, we can finish standardizing the already widely deployed core functionality that all of these mechanisms will need.

-- Mike

From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Wednesday, February 24, 2016 8:39 AM
To: Nat Sakimura <mailto:***@gmail.com> <***@gmail.com>
Cc: <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I am suggesting that part of the discovery solution has to be the client indicating what resource endpoint it wants the oauth configuration data for.

So if res.example.evil.com 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 <mailto:***@gmail.com> <***@gmail.com> wrote:

Hi Phil,

Are you suggesting that the AS metadata should include the RS URIs? Currently, it does not, but it can be done, I guess.

The way oauth-meta works is that

1. RS tells the client where the AS is.
2. AS tells the client which RS endpoints the token can be used.

Even if there is a bad AS with a valid certs that proxies to the good RS, the client will not send the token there as the authz server will say that is not the place the client may want to send the token to.

Nat

2016幎2月24日(æ°Ž) 23:59 Phil Hunt <mailto:***@oracle.com> <***@oracle.com>:
Nat,

I’m not sure that having the resource server tell the client where its authorization server is secure by itself. The relationship between the Authorization Server and the Resource server need to be bound together in one of the discovery endpoints (the resource and/or the oauth service discovery).

If a client discovers a fake resource server that is proxying for a real resource server the current discovery spec will not lead the client to understand it has the wrong resource server. Rather the fake resource service will just have a fake discovery service. The hacker can now intercept resource payload as well as tokens because they were able to convince the client to use the legit authorization service but use the token against the hackers proxy.

The OAuth Discovery service needs to confirm to the client that the server is able to issue tokens for a stated resource endpoint.

This not only works in normal OAuth but should add security even to UMA situations.

Phil

@independentid
www.independentid.com <http://www.independentid.com>
***@oracle.com <mailto:***@oracle.com>





On Feb 24, 2016, at 3:54 AM, Nat Sakimura <mailto:***@gmail.com> <***@gmail.com> wrote:


Hi Thomas,

inline:

2016幎2月22日(月) 18:44 Thomas Broyer <mailto:***@gmail.com> <***@gmail.com>:
Couldn't the document only describe the metadata?
I quite like the idea of draft-sakimura-oauth-meta if you really want to do discovery, and leave it open to implementers / to other specs to define a .well-known URL for "auto-configuration".
The metadata described here would then either be used as-is, at any URL, returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for other metadata specs (like OpenID Connect).
With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of WWW-Authenticate response header, you have everything you need to proceed

Yup. That's one of the requirements to be RESTful, is it not?

In OAuth's case, the resource and the authorization server are usually tightly coupled. (Otherwise, you need another specs like UMA.)
So, the resource server should be able to tell either the location of the authz endpoint. In some trusted environment, the resource may as well return the location of the authz server configuration data. In these cases, you do not have to decide on what .well-known uri as you say. This frees up developers from configuration file location collisions etc. We should strive not to pollute the uri space as much as possible.

(well, except if there are several ASs each with different scopes; sounds like an edge-case to me though; maybe RFC6750 should instead be updated with such a parameter such that an RS could return several WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)

Yeah, I guess it is an edge case. I would rather like to see these authz servers to develop a trust framework under which they can agree on a single set of common scope parameter values.

Cheers,

Nat



On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <mailto:***@mit.edu> <***@mit.edu> wrote:
The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.

I propose that we use “/.well-known/oauth-authorization-server” as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration” if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.

— Justin
_______________________________________________
OAuth mailing list
***@ietf.org <mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
***@ietf.org <mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
***@ietf.org <mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
***@ietf.org <mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth







_______________________________________________
OAuth mailing list
***@ietf.org <mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth



--
Vladimir Dzhuvinov :: ***@connect2id.com <mailto:***@connect2id.com>

[George Fletcher]

I'm concerned that forcing the AS to know about all RS's endpoints that
will accept it's tokens creates a very brittle deployment architecture.
What if a RS moves to a new endpoint? All clients would be required to
get new tokens (if I understand correctly). And the RS move would have
to coordinate with the AS to make sure all the timing is perfect in the
switch over of endpoints.

I suspect a common deployment architecture today is that each RS
requires one or more scopes to access it's resources. The client then
asks the user to authorize a token with a requested list of scopes. The
client can then send the token to the appropriate RS endpoint. The RS
will not authorize access unless the token has the required scopes.

If the concern is that the client may accidentally send the token to a
"bad" RS which will then replay the token, then I'd rather use a PoP
mechanism because the point is that you want to ensure the correct
client is presenting the token. Trying to ensure the client doesn't send
the token to the wrong endpoint seems fraught with problems.

Thanks,
George

On 2/24/16 9:59 AM, Phil Hunt wrote:
> Nat,
>
> I’m not sure that having the resource server tell the client where its
> authorization server is secure by itself. The relationship between the
> Authorization Server and the Resource server need to be bound together
> in one of the discovery endpoints (the resource and/or the oauth
> service discovery).
>
> If a client discovers a fake resource server that is proxying for a
> real resource server the current discovery spec will not lead the
> client to understand it has the wrong resource server. Rather the fake
> resource service will just have a fake discovery service. The hacker
> can now intercept resource payload as well as tokens because they were
> able to convince the client to use the legit authorization service but
> use the token against the hackers proxy.
>
> The OAuth Discovery service needs to confirm to the client that the
> server is able to issue tokens for a stated resource endpoint.
>
> This not only works in normal OAuth but should add security even to
> UMA situations.
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> ***@oracle.com <mailto:***@oracle.com>
>
>
>
>
>
>> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <***@gmail.com
>> <mailto:***@gmail.com>> wrote:
>>
>>
>> Hi Thomas,
>>
>> inline:
>>
>> 2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com
>> <mailto:***@gmail.com>>:
>>
>> Couldn't the document only describe the metadata?
>> I quite like the idea of draft-sakimura-oauth-meta if you really
>> want to do discovery, and leave it open to implementers / to
>> other specs to define a .well-known URL for "auto-configuration".
>> The metadata described here would then either be used as-is, at
>> any URL, returned as draft-sakimura-oauth-meta metadata at the
>> RS; or as a basis for other metadata specs (like OpenID Connect).
>>
>> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute
>> of WWW-Authenticate response header, you have everything you need
>> to proceed
>>
>>
>> Yup. That's one of the requirements to be RESTful, is it not?
>>
>> In OAuth's case, the resource and 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 <***@mit.edu
>> <mailto:***@mit.edu>> wrote:
>>
>> The newly-trimmed OAuth Discovery document is helpful and
>> moving in the right direction. It does, however, still have
>> too many vestiges of its OpenID Connect origins. One issue in
>> particular still really bothers me: the use of
>> “/.well-known/openid-configuration” in the discovery portion.
>> Is this an OAuth discovery document, or an OpenID Connect
>> one? There is absolutely no compelling reason to tie the URL
>> to the OIDC discovery mechanism.
>>
>> I propose that we use
>> “/.well-known/oauth-authorization-server” as the default
>> discovery location, and state that the document MAY also be
>> reachable from “/.well-known/openid-configuration” if the
>> server also provides OpenID Connect on the same domain. Other
>> applications SHOULD use the same parameter names to describe
>> OAuth endpoints and functions inside their service-specific
>> discovery document.
>>
>> — Justin
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--
Chief Architect
Identity Services Engineering Work: ***@teamaol.com
AOL Inc. AIM: gffletch
Mobile: [phone] Twitter: http://twitter.com/gffletch
Office: [phone] Photos: http://georgefletcher.photography

[Manger, James]

> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture

The AS is issuing temporary credentials (access_tokens) to clients but doesn’t know where those credentials will work? That’s broken.

An AS should absolutely indicate where an access_token can be used. draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” (resource URI) values in an HTTP Link header. A better approach would be including a list of web origins in the token response beside the access_token field.

--
James Manger

From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of George Fletcher
Sent: Thursday, 25 February 2016 6:17 AM
To: Phil Hunt <***@oracle.com>; Nat Sakimura <***@gmail.com>
Cc: <***@ietf.org> <***@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would be required to get new tokens (if I understand correctly). And the RS move would have to coordinate with the AS to make sure all the timing is perfect in the switch over of endpoints.

I suspect a common deployment architecture today is that each RS requires one or more scopes to access it's resources. The client then asks the user to authorize a token with a requested list of scopes. The client can then send the token to the appropriate RS endpoint. The RS will not authorize access unless the token has the required scopes.

If the concern is that the client may accidentally send the token to a "bad" RS which will then replay the token, then I'd rather use a PoP mechanism because the point is that you want to ensure the correct client is presenting the token. Trying to ensure the client doesn't send the token to the wrong endpoint seems fraught with problems.

Thanks,
George

[Vladimir Dzhuvinov]

On 25/02/16 09:02, Manger, James wrote:
>> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture
> The AS is issuing temporary credentials (access_tokens) to clients but doesn’t know where those credentials will work? That’s broken.
>
> An AS should absolutely indicate where an access_token can be used. draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” (resource URI) values in an HTTP Link header. A better approach would be including a list of web origins in the token response beside the access_token field.
+1

This will appear more consistent with the current experience, and OAuth
does allow the token response JSON object to be extended with additional
members (as it's done in OpenID Connect already).

Cheers,
Vladimir

> --
> James Manger
>
> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of George Fletcher
> Sent: Thursday, 25 February 2016 6:17 AM
> To: Phil Hunt <***@oracle.com>; Nat Sakimura <***@gmail.com>
> Cc: <***@ietf.org> <***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would be required to get new tokens (if I understand correctly). And the RS move would have to coordinate with the AS to make sure all the timing is perfect in the switch over of endpoints.
>
> I suspect a common deployment architecture today is that each RS requires one or more scopes to access it's resources. The client then asks the user to authorize a token with a requested list of scopes. The client can then send the token to the appropriate RS endpoint. The RS will not authorize access unless the token has the required scopes.
>
> If the concern is that the client may accidentally send the token to a "bad" RS which will then replay the token, then I'd rather use a PoP mechanism because the point is that you want to ensure the correct client is presenting the token. Trying to ensure the client doesn't send the token to the wrong endpoint seems fraught with problems.
>
> Thanks,
> George
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

[Donald F. Coffin]

In fact, this is the method being used by utilities implementing the Green
Button Connect My Data interface (North American Energy Standards Boards'
(NAESB) Retail Energy Quadrant 21 (REQ.21) Standard (Energy Service Provider
Interface - ESPI). The Green Button Alliance is in the processing of
updating the specification to use OAuth 2.0. The industry OpenADE Task
Force, which is the technical WG of the UCAIug, defined additional
information be returned with the OAuth 2.0 Token Response that includes the
URI of the resource to which the AT can be used.



Best regards,

Don

Donald F. Coffin

Founder/CTO



REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221



Phone: [phone]

Email: <mailto:***@reminetworks.com>
***@reminetworks.com



From: Vladimir Dzhuvinov [mailto:***@connect2id.com]
Sent: Thursday, February 25, 2016 2:23 AM
To: ***@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location





On 25/02/16 09:02, Manger, James wrote:

I'm concerned that forcing the AS to know about all RS's endpoints that will
accept it's tokens creates a very brittle deployment architecture


The AS is issuing temporary credentials (access_tokens) to clients but
doesn't know where those credentials will work? That's broken.

An AS should absolutely indicate where an access_token can be used.
draft-sakimura-oauth-meta suggests indicating this with 1 or more "ruri"
(resource URI) values in an HTTP Link header. A better approach would be
including a list of web origins in the token response beside the
access_token field.

+1

This will appear more consistent with the current experience, and OAuth does
allow the token response JSON object to be extended with additional members
(as it's done in OpenID Connect already).

Cheers,
Vladimir




--
James Manger

From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of George Fletcher
Sent: Thursday, 25 February 2016 6:17 AM
To: Phil Hunt <mailto:***@oracle.com> <***@oracle.com>; Nat
Sakimura <mailto:***@gmail.com> <***@gmail.com>
Cc: <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
<***@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I'm concerned that forcing the AS to know about all RS's endpoints that will
accept it's tokens creates a very brittle deployment architecture. What if a
RS moves to a new endpoint? All clients would be required to get new tokens
(if I understand correctly). And the RS move would have to coordinate with
the AS to make sure all the timing is perfect in the switch over of
endpoints.

I suspect a common deployment architecture today is that each RS requires
one or more scopes to access it's resources. The client then asks the user
to authorize a token with a requested list of scopes. The client can then
send the token to the appropriate RS endpoint. The RS will not authorize
access unless the token has the required scopes.

If the concern is that the client may accidentally send the token to a "bad"
RS which will then replay the token, then I'd rather use a PoP mechanism
because the point is that you want to ensure the correct client is
presenting the token. Trying to ensure the client doesn't send the token to
the wrong endpoint seems fraught with problems.

Thanks,
George

[Nat Sakimura]

Interesting. Is there a link that I can download your spec etc. ?

I have not much preference over the actual endpoint link or the web origin.
As long as the semantics is clear, either is fine.
I was even considering using URI template. It will be extremely flexible,
but I am not sure about the current status of the library availability and
its qualities.

Re: RFC5988 header or JSON - If you go back to earlier drafts, I was using
JSON. This will make it independent of HTTPS.
Also, developers can just process the JSON and store it in JSON. This is a
overall win.
Downside is that there is no standard for doing JSON metadata. Since
Swagger is using JSON Schema way of expressing it, perhaps that's the way
we should go, though, HAL seems to be a bit more efficient and nice.

In either way, though, IMHO, it is important to define the link relation in
the RFC5988 IANA registry.
Converting RFC5988 link header to either JSON schema metadata or HAL is
trivial.

Nat


2016幎2月25日(朚) 23:05 Donald F. Coffin <***@reminetworks.com>:

> In fact, this is the method being used by utilities implementing the Green
> Button Connect My Data interface (North American Energy Standards Boards’
> (NAESB) Retail Energy Quadrant 21 (REQ.21) Standard (Energy Service
> Provider Interface – ESPI). The Green Button Alliance is in the processing
> of updating the specification to use OAuth 2.0. The industry OpenADE Task
> Force, which is the technical WG of the UCAIug, defined additional
> information be returned with the OAuth 2.0 Token Response that includes
> the URI of the resource to which the AT can be used.
>
>
>
> Best regards,
>
> Don
>
> Donald F. Coffin
>
> Founder/CTO
>
>
>
> REMI Networks
>
> 2335 Dunwoody Xing #E
>
> Dunwoody, GA 30338-8221
>
>
>
> Phone: [phone]
>
> Email: ***@reminetworks.com
>
>
>
> *From:* Vladimir Dzhuvinov [mailto:***@connect2id.com]
> *Sent:* Thursday, February 25, 2016 2:23 AM
> *To:* ***@ietf.org
>
>
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
>
>
> On 25/02/16 09:02, Manger, James wrote:
>
> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture
>
>
>
> The AS is issuing temporary credentials (access_tokens) to clients but doesn’t know where those credentials will work? That’s broken.
>
>
>
> An AS should absolutely indicate where an access_token can be used. draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” (resource URI) values in an HTTP Link header. A better approach would be including a list of web origins in the token response beside the access_token field.
>
> +1
>
> This will appear more consistent with the current experience, and OAuth
> does allow the token response JSON object to be extended with additional
> members (as it's done in OpenID Connect already).
>
> Cheers,
> Vladimir
>
>
> --
>
> James Manger
>
>
>
> From: OAuth [mailto:oauth-***@ietf.org <oauth-***@ietf.org>] On Behalf Of George Fletcher
>
> Sent: Thursday, 25 February 2016 6:17 AM
>
> To: Phil Hunt <***@oracle.com> <***@oracle.com>; Nat Sakimura <***@gmail.com> <***@gmail.com>
>
> Cc: <***@ietf.org> <***@ietf.org> <***@ietf.org> <***@ietf.org>
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would be required to get new tokens (if I understand correctly). And the RS move would have to coordinate with the AS to make sure all the timing is perfect in the switch over of endpoints.
>
>
>
> I suspect a common deployment architecture today is that each RS requires one or more scopes to access it's resources. The client then asks the user to authorize a token with a requested list of scopes. The client can then send the token to the appropriate RS endpoint. The RS will not authorize access unless the token has the required scopes.
>
>
>
> If the concern is that the client may accidentally send the token to a "bad" RS which will then replay the token, then I'd rather use a PoP mechanism because the point is that you want to ensure the correct client is presenting the token. Trying to ensure the client doesn't send the token to the wrong endpoint seems fraught with problems.
>
>
>
> Thanks,
>
> George
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> ***@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

[Donald F. Coffin]

Nat,



The information that will be used to update the NAESB REQ.21 Standard can be found at http://greenbuttondata.org. The document that defines the Authorization requirements is referenced as the “GreenButton Implementation Agreement <http://osgug.ucaiug.org/sgsystems/OpenADE/Shared%20Documents/Testing%20and%20Certification/GreenButtonTestPlan/referenceMaterial/GreenButtonAuthorization.docx> ”. The current NAESB REQ.21 Standard is available on the NAESB Website, but is a copyrighted standard and cost $250.00. However, NAESB does provide the standard for evaluation purposes, by contacting the NAESB office at ***@naesb.org <mailto:***@naesb.org> .



The Green Button website is the technical repository for the Green Button initiative. Therefore, there are several technical documents and videos available. Let me know if you need help finding anything.



Best regards,

Don

Donald F. Coffin

Founder/CTO



REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221



Phone: [phone]

Email: <mailto:***@reminetworks.com> ***@reminetworks.com



From: Nat Sakimura [mailto:***@gmail.com]
Sent: Thursday, February 25, 2016 10:17 AM
To: Donald F. Coffin <***@reminetworks.com>; Vladimir Dzhuvinov <***@connect2id.com>; ***@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location



Interesting. Is there a link that I can download your spec etc. ?



I have not much preference over the actual endpoint link or the web origin. As long as the semantics is clear, either is fine.

I was even considering using URI template. It will be extremely flexible, but I am not sure about the current status of the library availability and its qualities.



Re: RFC5988 header or JSON - If you go back to earlier drafts, I was using JSON. This will make it independent of HTTPS.

Also, developers can just process the JSON and store it in JSON. This is a overall win.

Downside is that there is no standard for doing JSON metadata. Since Swagger is using JSON Schema way of expressing it, perhaps that's the way we should go, though, HAL seems to be a bit more efficient and nice.



In either way, though, IMHO, it is important to define the link relation in the RFC5988 IANA registry.

Converting RFC5988 link header to either JSON schema metadata or HAL is trivial.



Nat





2016幎2月25日(朚) 23:05 Donald F. Coffin <***@reminetworks.com <mailto:***@reminetworks.com> >:

In fact, this is the method being used by utilities implementing the Green Button Connect My Data interface (North American Energy Standards Boards’ (NAESB) Retail Energy Quadrant 21 (REQ.21) Standard (Energy Service Provider Interface – ESPI). The Green Button Alliance is in the processing of updating the specification to use OAuth 2.0. The industry OpenADE Task Force, which is the technical WG of the UCAIug, defined additional information be returned with the OAuth 2.0 Token Response that includes the URI of the resource to which the AT can be used.



Best regards,

Don

Donald F. Coffin

Founder/CTO



REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221



Phone: [phone]

Email: <mailto:***@reminetworks.com> ***@reminetworks.com



From: Vladimir Dzhuvinov [mailto:***@connect2id.com <mailto:***@connect2id.com> ]
Sent: Thursday, February 25, 2016 2:23 AM
To: ***@ietf.org <mailto:***@ietf.org>


Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location





On 25/02/16 09:02, Manger, James wrote:

I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture


The AS is issuing temporary credentials (access_tokens) to clients but doesn’t know where those credentials will work? That’s broken.

An AS should absolutely indicate where an access_token can be used. draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” (resource URI) values in an HTTP Link header. A better approach would be including a list of web origins in the token response beside the access_token field.

+1

This will appear more consistent with the current experience, and OAuth does allow the token response JSON object to be extended with additional members (as it's done in OpenID Connect already).

Cheers,
Vladimir



--
James Manger

From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of George Fletcher
Sent: Thursday, 25 February 2016 6:17 AM
To: Phil Hunt <mailto:***@oracle.com> <***@oracle.com>; Nat Sakimura <mailto:***@gmail.com> <***@gmail.com>
Cc: <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would be required to get new tokens (if I understand correctly). And the RS move would have to coordinate with the AS to make sure all the timing is perfect in the switch over of endpoints.

I suspect a common deployment architecture today is that each RS requires one or more scopes to access it's resources. The client then asks the user to authorize a token with a requested list of scopes. The client can then send the token to the appropriate RS endpoint. The RS will not authorize access unless the token has the required scopes.

If the concern is that the client may accidentally send the token to a "bad" RS which will then replay the token, then I'd rather use a PoP mechanism because the point is that you want to ensure the correct client is presenting the token. Trying to ensure the client doesn't send the token to the wrong endpoint seems fraught with problems.

Thanks,
George

[George Fletcher]

Interesting... this is not at all my current experience:) If a RS goes
from v2 of it's API to v3 and that RS uses the current standard of
putting a "v2" or"v3" in it's API path... then a token issued for v2 of
the API can not be sent to v3 of the API, because v3 wasn't wasn't
registered/deployed when the token was issued.

The constant management of scopes to URI endpoints seems like a
complexity that will quickly get out of hand.

Thanks,
George

On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
>
>
> On 25/02/16 09:02, Manger, James wrote:
>>> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture
>> The AS is issuing temporary credentials (access_tokens) to clients but doesn’t know where those credentials will work? That’s broken.
>>
>> An AS should absolutely indicate where an access_token can be used. draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” (resource URI) values in an HTTP Link header. A better approach would be including a list of web origins in the token response beside the access_token field.
> +1
>
> This will appear more consistent with the current experience, and
> OAuth does allow the token response JSON object to be extended with
> additional members (as it's done in OpenID Connect already).
>
> Cheers,
> Vladimir
>
>> --
>> James Manger
>>
>> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of George Fletcher
>> Sent: Thursday, 25 February 2016 6:17 AM
>> To: Phil Hunt<***@oracle.com>; Nat Sakimura<***@gmail.com>
>> Cc:<***@ietf.org> <***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would be required to get new tokens (if I understand correctly). And the RS move would have to coordinate with the AS to make sure all the timing is perfect in the switch over of endpoints.
>>
>> I suspect a common deployment architecture today is that each RS requires one or more scopes to access it's resources. The client then asks the user to authorize a token with a requested list of scopes. The client can then send the token to the appropriate RS endpoint. The RS will not authorize access unless the token has the required scopes.
>>
>> If the concern is that the client may accidentally send the token to a "bad" RS which will then replay the token, then I'd rather use a PoP mechanism because the point is that you want to ensure the correct client is presenting the token. Trying to ensure the client doesn't send the token to the wrong endpoint seems fraught with problems.
>>
>> Thanks,
>> George
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

[George Fletcher]

That said, I'm not against the AS informing the client that the token
can be used at the MailResource, ContactResource and MessagingResource
to help the client know not to send the token to a BlogResource.
However, identifying the actual endpoint seems overly complex when what
is really trying to be protected is a token from being used where it
shouldn't be (which is solved by Pop)

Thanks,
George

On 2/25/16 10:25 AM, George Fletcher wrote:
> Interesting... this is not at all my current experience:) If a RS goes
> from v2 of it's API to v3 and that RS uses the current standard of
> putting a "v2" or"v3" in it's API path... then a token issued for v2
> of the API can not be sent to v3 of the API, because v3 wasn't wasn't
> registered/deployed when the token was issued.
>
> The constant management of scopes to URI endpoints seems like a
> complexity that will quickly get out of hand.
>
> Thanks,
> George
>
> On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
>>
>>
>> On 25/02/16 09:02, Manger, James wrote:
>>>> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture
>>> The AS is issuing temporary credentials (access_tokens) to clients but doesn’t know where those credentials will work? That’s broken.
>>>
>>> An AS should absolutely indicate where an access_token can be used. draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” (resource URI) values in an HTTP Link header. A better approach would be including a list of web origins in the token response beside the access_token field.
>> +1
>>
>> This will appear more consistent with the current experience, and
>> OAuth does allow the token response JSON object to be extended with
>> additional members (as it's done in OpenID Connect already).
>>
>> Cheers,
>> Vladimir
>>
>>> --
>>> James Manger
>>>
>>> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of George Fletcher
>>> Sent: Thursday, 25 February 2016 6:17 AM
>>> To: Phil Hunt<***@oracle.com>; Nat Sakimura<***@gmail.com>
>>> Cc:<***@ietf.org> <***@ietf.org>
>>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>>
>>> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would be required to get new tokens (if I understand correctly). And the RS move would have to coordinate with the AS to make sure all the timing is perfect in the switch over of endpoints.
>>>
>>> I suspect a common deployment architecture today is that each RS requires one or more scopes to access it's resources. The client then asks the user to authorize a token with a requested list of scopes. The client can then send the token to the appropriate RS endpoint. The RS will not authorize access unless the token has the required scopes.
>>>
>>> If the concern is that the client may accidentally send the token to a "bad" RS which will then replay the token, then I'd rather use a PoP mechanism because the point is that you want to ensure the correct client is presenting the token. Trying to ensure the client doesn't send the token to the wrong endpoint seems fraught with problems.
>>>
>>> Thanks,
>>> George
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> ***@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

[Vladimir Dzhuvinov]

I made a mistake in my response (good to never rush things :)

My +1 was for moving the suggested metadata params from the "Link"
header to the JSON object that represents the token response. Because in
there we already have the token itself and associated metadata
(expiration and scope).

I still haven't made up my mind about the spec as a whole though.

On 25/02/16 17:27, George Fletcher wrote:
> That said, I'm not against the AS informing the client that the token
> can be used at the MailResource, ContactResource and MessagingResource
> to help the client know not to send the token to a BlogResource.
> However, identifying the actual endpoint seems overly complex when
> what is really trying to be protected is a token from being used where
> it shouldn't be (which is solved by Pop)
>
> Thanks,
> George
>
> On 2/25/16 10:25 AM, George Fletcher wrote:
>> Interesting... this is not at all my current experience:) If a RS
>> goes from v2 of it's API to v3 and that RS uses the current standard
>> of putting a "v2" or"v3" in it's API path... then a token issued for
>> v2 of the API can not be sent to v3 of the API, because v3 wasn't
>> wasn't registered/deployed when the token was issued.
>>
>> The constant management of scopes to URI endpoints seems like a
>> complexity that will quickly get out of hand.
>>
>> Thanks,
>> George
>>
>> On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
>>>
>>>
>>> On 25/02/16 09:02, Manger, James wrote:
>>>>> I'm concerned that forcing the AS to know about all RS's endpoints
>>>>> that will accept it's tokens creates a very brittle deployment
>>>>> architecture
>>>> The AS is issuing temporary credentials (access_tokens) to clients
>>>> but doesn’t know where those credentials will work? That’s broken.
>>>>
>>>> An AS should absolutely indicate where an access_token can be used.
>>>> draft-sakimura-oauth-meta suggests indicating this with 1 or more
>>>> “ruri” (resource URI) values in an HTTP Link header. A better
>>>> approach would be including a list of web origins in the token
>>>> response beside the access_token field.
>>> +1
>>>
>>> This will appear more consistent with the current experience, and
>>> OAuth does allow the token response JSON object to be extended with
>>> additional members (as it's done in OpenID Connect already).
>>>
>>> Cheers,
>>> Vladimir
>>>
>>>> --
>>>> James Manger
>>>>
>>>> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of George
>>>> Fletcher
>>>> Sent: Thursday, 25 February 2016 6:17 AM
>>>> To: Phil Hunt<***@oracle.com>; Nat Sakimura<***@gmail.com>
>>>> Cc:<***@ietf.org> <***@ietf.org>
>>>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>>>
>>>> I'm concerned that forcing the AS to know about all RS's endpoints
>>>> that will accept it's tokens creates a very brittle deployment
>>>> architecture. What if a RS moves to a new endpoint? All clients
>>>> would be required to get new tokens (if I understand correctly).
>>>> And the RS move would have to coordinate with the AS to make sure
>>>> all the timing is perfect in the switch over of endpoints.
>>>>
>>>> I suspect a common deployment architecture today is that each RS
>>>> requires one or more scopes to access it's resources. The client
>>>> then asks the user to authorize a token with a requested list of
>>>> scopes. The client can then send the token to the appropriate RS
>>>> endpoint. The RS will not authorize access unless the token has the
>>>> required scopes.
>>>>
>>>> If the concern is that the client may accidentally send the token
>>>> to a "bad" RS which will then replay the token, then I'd rather use
>>>> a PoP mechanism because the point is that you want to ensure the
>>>> correct client is presenting the token. Trying to ensure the client
>>>> doesn't send the token to the wrong endpoint seems fraught with
>>>> problems.
>>>>
>>>> Thanks,
>>>> George
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> ***@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> ***@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>

[Manger, James]

You are right, George, that making the AS track /v2/
 or /v3/
 in RS paths is likely to be brittle — but tracking RS web origins is not too onerous.

PoP has some nice security advantages over bearer tokens or passwords. However, it should still be possible to use the latter fairly safely — but it does require the issuer of credentials to indicate where they can be used.

--
James Manger



From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of George Fletcher
Sent: Friday, 26 February 2016 2:28 AM
To: Vladimir Dzhuvinov <***@connect2id.com>; ***@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

That said, I'm not against the AS informing the client that the token can be used at the MailResource, ContactResource and MessagingResource to help the client know not to send the token to a BlogResource. However, identifying the actual endpoint seems overly complex when what is really trying to be protected is a token from being used where it shouldn't be (which is solved by Pop)

Thanks,
George
On 2/25/16 10:25 AM, George Fletcher wrote:
Interesting... this is not at all my current experience:) If a RS goes from v2 of it's API to v3 and that RS uses the current standard of putting a "v2" or"v3" in it's API path... then a token issued for v2 of the API can not be sent to v3 of the API, because v3 wasn't wasn't registered/deployed when the token was issued.

The constant management of scopes to URI endpoints seems like a complexity that will quickly get out of hand.

Thanks,
George
On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:

On 25/02/16 09:02, Manger, James wrote:

I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture

The AS is issuing temporary credentials (access_tokens) to clients but doesn’t know where those credentials will work? That’s broken.



An AS should absolutely indicate where an access_token can be used. draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” (resource URI) values in an HTTP Link header. A better approach would be including a list of web origins in the token response beside the access_token field.
+1

This will appear more consistent with the current experience, and OAuth does allow the token response JSON object to be extended with additional members (as it's done in OpenID Connect already).

Cheers,
Vladimir



--

James Manger



From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of George Fletcher

Sent: Thursday, 25 February 2016 6:17 AM

To: Phil Hunt <***@oracle.com><mailto:***@oracle.com>; Nat Sakimura <***@gmail.com><mailto:***@gmail.com>

Cc: <***@ietf.org><mailto:***@ietf.org> <***@ietf.org><mailto:***@ietf.org>

Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location



I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would be required to get new tokens (if I understand correctly). And the RS move would have to coordinate with the AS to make sure all the timing is perfect in the switch over of endpoints.



I suspect a common deployment architecture today is that each RS requires one or more scopes to access it's resources. The client then asks the user to authorize a token with a requested list of scopes. The client can then send the token to the appropriate RS endpoint. The RS will not authorize access unless the token has the required scopes.



If the concern is that the client may accidentally send the token to a "bad" RS which will then replay the token, then I'd rather use a PoP mechanism because the point is that you want to ensure the correct client is presenting the token. Trying to ensure the client doesn't send the token to the wrong endpoint seems fraught with problems.



Thanks,

George




_______________________________________________

OAuth mailing list

***@ietf.org<mailto:***@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth





_______________________________________________

OAuth mailing list

***@ietf.org<mailto:***@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth






_______________________________________________

OAuth mailing list

***@ietf.org<mailto:***@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth

[Nat Sakimura]

I will include the origin in the next rev.

For http header v.s JSON, shall I bring the JSON back in?
2016幎2月26日(金) 13:05 Manger, James <***@team.telstra.com>:

> You are right, George, that making the AS track /v2/
 or /v3/
 in RS paths
> is likely to be brittle — but tracking RS web origins is not too onerous.
>
>
>
> PoP has some nice security advantages over bearer tokens or passwords.
> However, it should still be possible to use the latter fairly safely — but
> it does require the issuer of credentials to indicate where they can be
> used.
>
>
>
> --
>
> James Manger
>
>
>
>
>
>
>
> *From:* OAuth [mailto:oauth-***@ietf.org] *On Behalf Of *George
> Fletcher
> *Sent:* Friday, 26 February 2016 2:28 AM
> *To:* Vladimir Dzhuvinov <***@connect2id.com>; ***@ietf.org
>
>
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> That said, I'm not against the AS informing the client that the token can
> be used at the MailResource, ContactResource and MessagingResource to help
> the client know not to send the token to a BlogResource. However,
> identifying the actual endpoint seems overly complex when what is really
> trying to be protected is a token from being used where it shouldn't be
> (which is solved by Pop)
>
> Thanks,
> George
>
> On 2/25/16 10:25 AM, George Fletcher wrote:
>
> Interesting... this is not at all my current experience:) If a RS goes
> from v2 of it's API to v3 and that RS uses the current standard of putting
> a "v2" or"v3" in it's API path... then a token issued for v2 of the API can
> not be sent to v3 of the API, because v3 wasn't wasn't registered/deployed
> when the token was issued.
>
> The constant management of scopes to URI endpoints seems like a complexity
> that will quickly get out of hand.
>
> Thanks,
> George
>
> On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
>
>
>
> On 25/02/16 09:02, Manger, James wrote:
>
> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture
>
> The AS is issuing temporary credentials (access_tokens) to clients but doesn’t know where those credentials will work? That’s broken.
>
>
>
> An AS should absolutely indicate where an access_token can be used. draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” (resource URI) values in an HTTP Link header. A better approach would be including a list of web origins in the token response beside the access_token field.
>
> +1
>
> This will appear more consistent with the current experience, and OAuth
> does allow the token response JSON object to be extended with additional
> members (as it's done in OpenID Connect already).
>
> Cheers,
> Vladimir
>
>
> --
>
> James Manger
>
>
>
> From: OAuth [mailto:oauth-***@ietf.org <oauth-***@ietf.org>] On Behalf Of George Fletcher
>
> Sent: Thursday, 25 February 2016 6:17 AM
>
> To: Phil Hunt <***@oracle.com> <***@oracle.com>; Nat Sakimura <***@gmail.com> <***@gmail.com>
>
> Cc: <***@ietf.org> <***@ietf.org> <***@ietf.org> <***@ietf.org>
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would be required to get new tokens (if I understand correctly). And the RS move would have to coordinate with the AS to make sure all the timing is perfect in the switch over of endpoints.
>
>
>
> I suspect a common deployment architecture today is that each RS requires one or more scopes to access it's resources. The client then asks the user to authorize a token with a requested list of scopes. The client can then send the token to the appropriate RS endpoint. The RS will not authorize access unless the token has the required scopes.
>
>
>
> If the concern is that the client may accidentally send the token to a "bad" RS which will then replay the token, then I'd rather use a PoP mechanism because the point is that you want to ensure the correct client is presenting the token. Trying to ensure the client doesn't send the token to the wrong endpoint seems fraught with problems.
>
>
>
> Thanks,
>
> George
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> ***@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> ***@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> ***@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

[nov matake]

It sounds like we want to return a list of available access tokens “aud” values from AS config discovery endpoint (and also via oauth-meta too?), doesn’t it?

and RS config discovery endpoint will return acceptable access token “iss” values, a list of every RS endpoints, required scopes per endpoint etc.
(it would be another thread though)

Thanks,
Nov

> On Feb 26, 2016, at 13:08, Nat Sakimura <***@gmail.com> wrote:
>
> I will include the origin in the next rev.
>
> For http header v.s JSON, shall I bring the JSON back in?
> 2016幎2月26日(金) 13:05 Manger, James <***@team.telstra.com <mailto:***@team.telstra.com>>:
> You are right, George, that making the AS track /v2/
 or /v3/
 in RS paths is likely to be brittle — but tracking RS web origins is not too onerous.
>
>
>
> PoP has some nice security advantages over bearer tokens or passwords. However, it should still be possible to use the latter fairly safely — but it does require the issuer of credentials to indicate where they can be used.
>
>
>
> --
>
> James Manger
>
>
>
>
>
>
>
> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org>] On Behalf Of George Fletcher
> Sent: Friday, 26 February 2016 2:28 AM
> To: Vladimir Dzhuvinov <***@connect2id.com <mailto:***@connect2id.com>>; ***@ietf.org <mailto:***@ietf.org>
>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
>
>
> That said, I'm not against the AS informing the client that the token can be used at the MailResource, ContactResource and MessagingResource to help the client know not to send the token to a BlogResource. However, identifying the actual endpoint seems overly complex when what is really trying to be protected is a token from being used where it shouldn't be (which is solved by Pop)
>
> Thanks,
> George
>
> On 2/25/16 10:25 AM, George Fletcher wrote:
>
> Interesting... this is not at all my current experience:) If a RS goes from v2 of it's API to v3 and that RS uses the current standard of putting a "v2" or"v3" in it's API path... then a token issued for v2 of the API can not be sent to v3 of the API, because v3 wasn't wasn't registered/deployed when the token was issued.
>
> The constant management of scopes to URI endpoints seems like a complexity that will quickly get out of hand.
>
> Thanks,
> George
>
> On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
>
>
>
> On 25/02/16 09:02, Manger, James wrote:
>
> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture
> The AS is issuing temporary credentials (access_tokens) to clients but doesn’t know where those credentials will work? That’s broken.
>
> An AS should absolutely indicate where an access_token can be used. draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” (resource URI) values in an HTTP Link header. A better approach would be including a list of web origins in the token response beside the access_token field.
> +1
>
> This will appear more consistent with the current experience, and OAuth does allow the token response JSON object to be extended with additional members (as it's done in OpenID Connect already).
>
> Cheers,
> Vladimir
>
>
>
> --
> James Manger
>
> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org>] On Behalf Of George Fletcher
> Sent: Thursday, 25 February 2016 6:17 AM
> To: Phil Hunt <***@oracle.com> <mailto:***@oracle.com>; Nat Sakimura <***@gmail.com> <mailto:***@gmail.com>
> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would be required to get new tokens (if I understand correctly). And the RS move would have to coordinate with the AS to make sure all the timing is perfect in the switch over of endpoints.
>
> I suspect a common deployment architecture today is that each RS requires one or more scopes to access it's resources. The client then asks the user to authorize a token with a requested list of scopes. The client can then send the token to the appropriate RS endpoint. The RS will not authorize access unless the token has the required scopes.
>
> If the concern is that the client may accidentally send the token to a "bad" RS which will then replay the token, then I'd rather use a PoP mechanism because the point is that you want to ensure the correct client is presenting the token. Trying to ensure the client doesn't send the token to the wrong endpoint seems fraught with problems.
>
> Thanks,
> George
>
>
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

[John Bradley]

A given AS may be supporting different protocols and or scopes with different privileges.

Those would need to be mapped into where the token can be used.

If we try to use audience only to stop cross RS replay it will in my opinion become hopelessly complex.

I think the only secure and practical solution is likely asymmetric POP. That only requires the RS to trust the AS. The AS doesn’t need to know the RS if it is using JWT access tokens.

I am skeptical that this can be solved by meta-data alone.

John B.
> On Feb 26, 2016, at 6:52 AM, nov matake <***@gmail.com> wrote:
>
> It sounds like we want to return a list of available access tokens “aud” values from AS config discovery endpoint (and also via oauth-meta too?), doesn’t it?
>
> and RS config discovery endpoint will return acceptable access token “iss” values, a list of every RS endpoints, required scopes per endpoint etc.
> (it would be another thread though)
>
> Thanks,
> Nov
>
>> On Feb 26, 2016, at 13:08, Nat Sakimura <***@gmail.com <mailto:***@gmail.com>> wrote:
>>
>> I will include the origin in the next rev.
>>
>> For http header v.s JSON, shall I bring the JSON back in?
>> 2016幎2月26日(金) 13:05 Manger, James <***@team.telstra.com <mailto:***@team.telstra.com>>:
>> You are right, George, that making the AS track /v2/
 or /v3/
 in RS paths is likely to be brittle — but tracking RS web origins is not too onerous.
>>
>>
>>
>> PoP has some nice security advantages over bearer tokens or passwords. However, it should still be possible to use the latter fairly safely — but it does require the issuer of credentials to indicate where they can be used.
>>
>>
>>
>> --
>>
>> James Manger
>>
>>
>>
>>
>>
>>
>>
>> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org>] On Behalf Of George Fletcher
>> Sent: Friday, 26 February 2016 2:28 AM
>> To: Vladimir Dzhuvinov <***@connect2id.com <mailto:***@connect2id.com>>; ***@ietf.org <mailto:***@ietf.org>
>>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>>
>>
>> That said, I'm not against the AS informing the client that the token can be used at the MailResource, ContactResource and MessagingResource to help the client know not to send the token to a BlogResource. However, identifying the actual endpoint seems overly complex when what is really trying to be protected is a token from being used where it shouldn't be (which is solved by Pop)
>>
>> Thanks,
>> George
>>
>> On 2/25/16 10:25 AM, George Fletcher wrote:
>>
>> Interesting... this is not at all my current experience:) If a RS goes from v2 of it's API to v3 and that RS uses the current standard of putting a "v2" or"v3" in it's API path... then a token issued for v2 of the API can not be sent to v3 of the API, because v3 wasn't wasn't registered/deployed when the token was issued.
>>
>> The constant management of scopes to URI endpoints seems like a complexity that will quickly get out of hand.
>>
>> Thanks,
>> George
>>
>> On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
>>
>>
>>
>> On 25/02/16 09:02, Manger, James wrote:
>>
>> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture
>> The AS is issuing temporary credentials (access_tokens) to clients but doesn’t know where those credentials will work? That’s broken.
>>
>> An AS should absolutely indicate where an access_token can be used. draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” (resource URI) values in an HTTP Link header. A better approach would be including a list of web origins in the token response beside the access_token field.
>> +1
>>
>> This will appear more consistent with the current experience, and OAuth does allow the token response JSON object to be extended with additional members (as it's done in OpenID Connect already).
>>
>> Cheers,
>> Vladimir
>>
>>
>>
>> --
>> James Manger
>>
>> From: OAuth [mailto:oauth-***@ietf.org <mailto:oauth-***@ietf.org>] On Behalf Of George Fletcher
>> Sent: Thursday, 25 February 2016 6:17 AM
>> To: Phil Hunt <***@oracle.com> <mailto:***@oracle.com>; Nat Sakimura <***@gmail.com> <mailto:***@gmail.com>
>> Cc: <***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would be required to get new tokens (if I understand correctly). And the RS move would have to coordinate with the AS to make sure all the timing is perfect in the switch over of endpoints.
>>
>> I suspect a common deployment architecture today is that each RS requires one or more scopes to access it's resources. The client then asks the user to authorize a token with a requested list of scopes. The client can then send the token to the appropriate RS endpoint. The RS will not authorize access unless the token has the required scopes.
>>
>> If the concern is that the client may accidentally send the token to a "bad" RS which will then replay the token, then I'd rather use a PoP mechanism because the point is that you want to ensure the correct client is presenting the token. Trying to ensure the client doesn't send the token to the wrong endpoint seems fraught with problems.
>>
>> Thanks,
>> George
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

[George Fletcher]

As long as the "aud" value is more akin to a fixed URI from which the
client can determine valid endpoints for that "aud", this could work. It
does make the client do a lot of discovery.

I don't think the "aud" value can be a domain.

Thanks,
George

On 2/26/16 12:52 AM, nov matake wrote:
> It sounds like we want to return a list of available access tokens
> “aud” values from AS config discovery endpoint (and also via
> oauth-meta too?), doesn’t it?
>
> and RS config discovery endpoint will return acceptable access token
> “iss” values, a list of every RS endpoints, required scopes per
> endpoint etc.
> (it would be another thread though)
>
> Thanks,
> Nov
>
>> On Feb 26, 2016, at 13:08, Nat Sakimura <***@gmail.com
>> <mailto:***@gmail.com>> wrote:
>>
>> I will include the origin in the next rev.
>>
>> For http header v.s JSON, shall I bring the JSON back in?
>> 2016幎2月26日(金) 13:05 Manger, James
>> <***@team.telstra.com
>> <mailto:***@team.telstra.com>>:
>>
>> You are right, George, that making the AS track /v2/
 or /v3/
 in
>> RS paths is likely to be brittle — but tracking RS web origins is
>> not too onerous.
>>
>> PoP has some nice security advantages over bearer tokens or
>> passwords. However, it should still be possible to use the latter
>> fairly safely — but it does require the issuer of credentials to
>> indicate where they can be used.
>>
>> --
>>
>> James Manger
>>
>> *From:*OAuth [mailto:oauth-***@ietf.org
>> <mailto:oauth-***@ietf.org>] *On Behalf Of *George Fletcher
>> *Sent:* Friday, 26 February 2016 2:28 AM
>> *To:* Vladimir Dzhuvinov <***@connect2id.com
>> <mailto:***@connect2id.com>>; ***@ietf.org
>> <mailto:***@ietf.org>
>>
>>
>> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>> That said, I'm not against the AS informing the client that the
>> token can be used at the MailResource, ContactResource and
>> MessagingResource to help the client know not to send the token
>> to a BlogResource. However, identifying the actual endpoint seems
>> overly complex when what is really trying to be protected is a
>> token from being used where it shouldn't be (which is solved by Pop)
>>
>> Thanks,
>> George
>>
>> On 2/25/16 10:25 AM, George Fletcher wrote:
>>
>> Interesting... this is not at all my current experience:) If
>> a RS goes from v2 of it's API to v3 and that RS uses the
>> current standard of putting a "v2" or"v3" in it's API path...
>> then a token issued for v2 of the API can not be sent to v3
>> of the API, because v3 wasn't wasn't registered/deployed when
>> the token was issued.
>>
>> The constant management of scopes to URI endpoints seems like
>> a complexity that will quickly get out of hand.
>>
>> Thanks,
>> George
>>
>> On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
>>
>> On 25/02/16 09:02, Manger, James wrote:
>>
>> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture
>>
>> The AS is issuing temporary credentials (access_tokens) to clients but doesn’t know where those credentials will work? That’s broken.
>>
>>
>>
>> An AS should absolutely indicate where an access_token can be used. draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” (resource URI) values in an HTTP Link header. A better approach would be including a list of web origins in the token response beside the access_token field.
>>
>> +1
>>
>> This will appear more consistent with the current
>> experience, and OAuth does allow the token response JSON
>> object to be extended with additional members (as it's
>> done in OpenID Connect already).
>>
>> Cheers,
>> Vladimir
>>
>>
>> --
>>
>> James Manger
>>
>>
>>
>> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of George Fletcher
>>
>> Sent: Thursday, 25 February 2016 6:17 AM
>>
>> To: Phil Hunt<***@oracle.com> <mailto:***@oracle.com>; Nat Sakimura<***@gmail.com> <mailto:***@gmail.com>
>>
>> Cc:<***@ietf.org> <mailto:***@ietf.org> <***@ietf.org> <mailto:***@ietf.org>
>>
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>>
>>
>>
>> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would be required to get new tokens (if I understand correctly). And the RS move would have to coordinate with the AS to make sure all the timing is perfect in the switch over of endpoints.
>>
>>
>>
>> I suspect a common deployment architecture today is that each RS requires one or more scopes to access it's resources. The client then asks the user to authorize a token with a requested list of scopes. The client can then send the token to the appropriate RS endpoint. The RS will not authorize access unless the token has the required scopes.
>>
>>
>>
>> If the concern is that the client may accidentally send the token to a "bad" RS which will then replay the token, then I'd rather use a PoP mechanism because the point is that you want to ensure the correct client is presenting the token. Trying to ensure the client doesn't send the token to the wrong endpoint seems fraught with problems.
>>
>>
>>
>> Thanks,
>>
>> George
>>
>>
>>
>>
>> _______________________________________________
>>
>> OAuth mailing list
>>
>> ***@ietf.org <mailto:***@ietf.org>
>>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> OAuth mailing list
>>
>> ***@ietf.org <mailto:***@ietf.org>
>>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> OAuth mailing list
>>
>> ***@ietf.org <mailto:***@ietf.org>
>>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>

[Thomas Broyer]

On Thu, Feb 25, 2016 at 4:25 PM George Fletcher <***@aol.com> wrote:

> Interesting... this is not at all my current experience:) If a RS goes
> from v2 of it's API to v3 and that RS uses the current standard of putting
> a "v2" or"v3" in it's API path... then a token issued for v2 of the API can
> not be sent to v3 of the API, because v3 wasn't wasn't registered/deployed
> when the token was issued.
>

Add to that:

- "restful" APIs have a lot of "endpoints" related to a single scope
- I know at least one AS that doesn't require RSs to register (I wonder
how it all works, and whether it's really secure –I hope so, given the
known RSs–, but that's how it is): documentation can be found (in French)
at https://doc.integ01.dev-franceconnect.fr/ (or
https://integ01.dev-franceconnect.fr/ if the previous URL doesn't work
for you, they have DNS configuration issues)
- even UMA doesn't register "resources" themselves, but only "resource
sets", and it doesn't even require a) an URI for the resource set, or b)
any "relationship" between the resource set URI (if any) and the URIs of
the resources "in" the resource set:
https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html



> The constant management of scopes to URI endpoints seems like a complexity
> that will quickly get out of hand.
>

+1

[George Fletcher]

The AS knows the RS's that will consume it's tokens because it knows the
scopes that it can allow the user to authorize. I don't think the AS
MUST know the endpoints of the RS (which is what the current drafts
require).

It is not often that the entity/group responsible for the Authorization
Service is also responsible for the actual resource server. Take for
example a Mail API run by one team and the Authorization server managed
by the Identity team.

Requiring the Mail Team to notify and coordinate the change of endpoints
for a new deployment is brittle.

Also, I believe the main reason for wanting to bind a token to an
endpoint is to protect the token from being sent to a malicious RS and
then having that RS replay the token. If possible replay of a token is
the main concern, then why not use PoP which ensures that only the
appropriate client and present the token. This seems a much cleaner way
to protect against this threat.

Thanks,
George

On 2/25/16 2:02 AM, Manger, James wrote:
>
> > I'm concerned that forcing the AS to know about all RS's endpoints
> that will accept it's tokens creates a very brittle deployment
> architecture
>
> The AS is issuing temporary credentials (access_tokens) to clients but
> doesn’t know where those credentials will work? That’s broken.
>
> An AS should absolutely indicate where an access_token can be used.
> draft-sakimura-oauth-meta suggests indicating this with 1 or more
> “ruri” (resource URI) values in an HTTP Link header. A better approach
> would be including a list of web origins in the token response beside
> the access_token field.
>
> --
>
> James Manger
>
> *From:*OAuth [mailto:oauth-***@ietf.org] *On Behalf Of *George
> Fletcher
> *Sent:* Thursday, 25 February 2016 6:17 AM
> *To:* Phil Hunt <***@oracle.com>; Nat Sakimura <***@gmail.com>
> *Cc:* <***@ietf.org> <***@ietf.org>
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> I'm concerned that forcing the AS to know about all RS's endpoints
> that will accept it's tokens creates a very brittle deployment
> architecture. What if a RS moves to a new endpoint? All clients would
> be required to get new tokens (if I understand correctly). And the RS
> move would have to coordinate with the AS to make sure all the timing
> is perfect in the switch over of endpoints.
>
> I suspect a common deployment architecture today is that each RS
> requires one or more scopes to access it's resources. The client then
> asks the user to authorize a token with a requested list of scopes.
> The client can then send the token to the appropriate RS endpoint. The
> RS will not authorize access unless the token has the required scopes.
>
> If the concern is that the client may accidentally send the token to a
> "bad" RS which will then replay the token, then I'd rather use a PoP
> mechanism because the point is that you want to ensure the correct
> client is presenting the token. Trying to ensure the client doesn't
> send the token to the wrong endpoint seems fraught with problems.
>
> Thanks,
> George
>

[Thomas Broyer]

Hi Nat,

On Wed, Feb 24, 2016 at 12:54 PM Nat Sakimura <***@gmail.com> wrote:

>
> 2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com>:
>
>
>> (well, except if there are several ASs each with different scopes; sounds
>> like an edge-case to me though; maybe RFC6750 should instead be updated
>> with such a parameter such that an RS could return several
>> WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
>>
>
> Yeah, I guess it is an edge case. I would rather like to see these authz
> servers to develop a trust framework under which they can agree on a single
> set of common scope parameter values.
>

Well, except that adding the "duri" and "auri" metadata links to the
"WWW-Authenticate: Bearer" response header(s) would easily solve those
issues (without judging here whether they're edge-case or not), and I don't
really see any other use-case for that metadata outside the unauthorized
use of a resource (your draft admits it's the "typical use-case").

[Nat Sakimura]

Right. As there can be multiple WWW-authenticate header, it is doable that
way. Maybe that's better in this respect, though it becomes a bit different
than other metadata. Alternatively, the scope can be added as a parameter
in the auri Web Link header.
Good things about the Link Header is that you can just configure the web
server config to return them. There is no code needed.

2016幎2月25日(朚) 0:01 Thomas Broyer <***@gmail.com>:

> Hi Nat,
>
> On Wed, Feb 24, 2016 at 12:54 PM Nat Sakimura <***@gmail.com> wrote:
>
>>
>> 2016幎2月22日(月) 18:44 Thomas Broyer <***@gmail.com>:
>>
>
>>
>>> (well, except if there are several ASs each with different scopes;
>>> sounds like an edge-case to me though; maybe RFC6750 should instead be
>>> updated with such a parameter such that an RS could return several
>>> WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
>>>
>>
>> Yeah, I guess it is an edge case. I would rather like to see these authz
>> servers to develop a trust framework under which they can agree on a single
>> set of common scope parameter values.
>>
>
> Well, except that adding the "duri" and "auri" metadata links to the
> "WWW-Authenticate: Bearer" response header(s) would easily solve those
> issues (without judging here whether they're edge-case or not), and I don't
> really see any other use-case for that metadata outside the unauthorized
> use of a resource (your draft admits it's the "typical use-case").
>

[Brian Campbell]

+1

On Fri, Feb 19, 2016 at 9:28 PM, Vladimir Dzhuvinov <***@connect2id.com
> wrote:

> +1
>
> On 19/02/16 23:59, Justin Richer wrote:
> > The newly-trimmed OAuth Discovery document is helpful and moving in the
> right direction. It does, however, still have too many vestiges of its
> OpenID Connect origins. One issue in particular still really bothers me:
> the use of “/.well-known/openid-configuration” in the discovery portion. Is
> this an OAuth discovery document, or an OpenID Connect one? There is
> absolutely no compelling reason to tie the URL to the OIDC discovery
> mechanism.
> >
> > I propose that we use “/.well-known/oauth-authorization-server” as the
> default discovery location, and state that the document MAY also be
> reachable from “/.well-known/openid-configuration” if the server also
> provides OpenID Connect on the same domain. Other applications SHOULD use
> the same parameter names to describe OAuth endpoints and functions inside
> their service-specific discovery document.
> >
> > — Justin
> > _______________________________________________
> > OAuth mailing list
> > ***@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

[Roland Hedberg]

+1

> 29 feb. 2016 kl. 15:41 skrev Brian Campbell <***@pingidentity.com>:
>
> +1
>
> On Fri, Feb 19, 2016 at 9:28 PM, Vladimir Dzhuvinov <***@connect2id.com <mailto:***@connect2id.com>> wrote:
> +1
>
> On 19/02/16 23:59, Justin Richer wrote:
> > The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this an OAuth discovery document, or an OpenID Connect one? There is absolutely no compelling reason to tie the URL to the OIDC discovery mechanism.
> >
> > I propose that we use “/.well-known/oauth-authorization-server” as the default discovery location, and state that the document MAY also be reachable from “/.well-known/openid-configuration” if the server also provides OpenID Connect on the same domain. Other applications SHOULD use the same parameter names to describe OAuth endpoints and functions inside their service-specific discovery document.
> >
> > — Justin
> > _______________________________________________
> > OAuth mailing list
> > ***@ietf.org <mailto:***@ietf.org>
> > https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org <mailto:***@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth