Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[nov matake]

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

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

Thanks,
Nov

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

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Nat Sakimura]

I will include the origin in the next rev.

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

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

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Manger, James]

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

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

--
James Manger



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

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

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

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

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

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

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

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



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

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

Cheers,
Vladimir



--

James Manger



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

Sent: Thursday, 25 February 2016 6:17 AM

To: Phil Hunt ; Nat Sakimura 


Cc:  


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



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



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



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



Thanks,

George




___

OAuth mailing list

OAuth@ietf.org

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





___

OAuth mailing list

OAuth@ietf.org

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






___

OAuth mailing list

OAuth@ietf.org

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

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

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[John Bradley]

Authorization server discovery.

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

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Donald F. Coffin]

+1 for “OAuth 2.0 Authorization Server Discovery”

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

 

Phone:  (949) 636-8571

Email: 
donald.cof...@reminetworks.com

 

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

 

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

 

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

 

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

 

In summary, which title do people prefer?

* “OAuth 2.0 Discovery”

* “OAuth 2.0 Authorization Server Discovery”

 

  -- Mike

 

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

 

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

Here are some example OIDC discovery docs:

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

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

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


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

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


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

Cheers,

Vladimir




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

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

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

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[George Fletcher]

+1 for “OAuth 2.0 Authorization Server Discovery”

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


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


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


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


In summary, which title do people prefer?

·“OAuth 2.0 Discovery”

·“OAuth 2.0 Authorization Server Discovery”

-- Mike

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

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

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


Here are some example OIDC discovery docs:

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

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

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


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


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


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


Cheers,

Vladimir



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

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

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

Phil

On Feb 24, 2016, at 16:04, Mike Jones 
  wrote:

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

  


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

  


 -- Mike

  


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

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

To: Mike Jones

Cc: 

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

  


Mike

  


Take a look at the assumptions you are making.

  


You seem to be assuming 

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Mike Jones]

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

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

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

In summary, which title do people prefer?

·   “OAuth 2.0 Discovery”

·   “OAuth 2.0 Authorization Server Discovery”

  -- Mike

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

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

Here are some example OIDC discovery docs:

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

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

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


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

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


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

Cheers,

Vladimir



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

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



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



Phil



On Feb 24, 2016, at 16:04, Mike Jones 
 wrote:



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



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



-- Mike



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

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

To: Mike Jones

Cc: 

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



Mike



Take a look at the assumptions you are making.



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



Would ms azure allow custom arch?



Phil



On Feb 24, 2016, at 15:28, Mike Jones 

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Thomas Broyer]

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

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

Add to that:

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



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

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

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Donald F. Coffin]

Nat,

 

The information that will be used to update the NAESB REQ.21 Standard can be 
found at http://greenbuttondata.org.  The document that defines the 
Authorization requirements is referenced as the “GreenButton Implementation 
Agreement 

 ”.   The current NAESB REQ.21 Standard is available on the NAESB Website, but 
is a copyrighted standard and cost $250.00.  However, NAESB does provide the 
standard for evaluation purposes, by contacting the NAESB office at 
na...@naesb.org  .

 

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

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

 

Phone:  (949) 636-8571

Email: 
donald.cof...@reminetworks.com

 

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

 

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

 

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

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

 

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

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

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

 

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

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

 

Nat

 

 

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

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

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

 

Phone:  (949) 636-8571

Email: 
donald.cof...@reminetworks.com

 

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


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

 

 

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

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

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

+1 

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

Cheers,
Vladimir



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

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

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Vladimir Dzhuvinov]

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

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

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

On 25/02/16 17:27, George Fletcher wrote:
> That said, I'm not against the AS informing the client that the token
> can be used at the MailResource, ContactResource and MessagingResource
> to help the client know not to send the token to a BlogResource.
> However, identifying the actual endpoint seems overly complex when
> what is really trying to be protected is a token from being used where
> it shouldn't be (which is solved by Pop)
>
> Thanks,
> George
>
> On 2/25/16 10:25 AM, George Fletcher wrote:
>> Interesting... this is not at all my current experience:) If a RS
>> goes from v2 of it's API to v3 and that RS uses the current standard
>> of putting a "v2" or"v3" in it's API path... then a token issued for
>> v2 of the API can not be sent to v3 of the API, because v3 wasn't
>> wasn't registered/deployed when the token was issued.
>>
>> The constant management of scopes to URI endpoints seems like a
>> complexity that will quickly get out of hand.
>>
>> Thanks,
>> George
>>
>> On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote:
>>>
>>>
>>> On 25/02/16 09:02, Manger, James wrote:
> I'm concerned that forcing the AS to know about all RS's endpoints
> that will accept it's tokens creates a very brittle deployment
> architecture
 The AS is issuing temporary credentials (access_tokens) to clients
 but doesn’t know where those credentials will work? That’s broken.

 An AS should absolutely indicate where an access_token can be used.
 draft-sakimura-oauth-meta suggests indicating this with 1 or more
 “ruri” (resource URI) values in an HTTP Link header. A better
 approach would be including a list of web origins in the token
 response beside the access_token field.
>>> +1
>>>
>>> This will appear more consistent with the current experience, and
>>> OAuth does allow the token response JSON object to be extended with
>>> additional members (as it's done in OpenID Connect already).
>>>
>>> Cheers,
>>> Vladimir
>>>
 -- 
 James Manger

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

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

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

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

 Thanks,
 George


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




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

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[George Fletcher]

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


Thanks,
George

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


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


Thanks,
George

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



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

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

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

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

+1

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


Cheers,
Vladimir


--
James Manger

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

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

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

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

Thanks,
George


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




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





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


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

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[George Fletcher]

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


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


Thanks,
George

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



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

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

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

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

+1

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


Cheers,
Vladimir


--
James Manger

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

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

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

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

Thanks,
George


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




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



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

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Nat Sakimura]

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

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

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

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

Nat


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

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

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[George Fletcher]

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


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


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


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


Thanks,
George

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


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


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


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


--

James Manger

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

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

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


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


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


Thanks,
George



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

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Donald F. Coffin]

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

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

 

Phone:  (949) 636-8571

Email:
donald.cof...@reminetworks.com

 

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

 

 

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

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

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

+1 

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

Cheers,
Vladimir




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

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






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

 

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

[OAUTH-WG] (no subject)

[Dred J]

 --   J Dred from  --
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Vladimir Dzhuvinov]

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

Here are some example OIDC discovery docs:

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

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

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


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

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


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

Cheers,

Vladimir




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