Subject: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

From: Phil Hunt <[email-masked]>
Date: Sun, 13 Mar 2016 16:12:42 -0700

This draft is a proposed alternate proposal for draft-ietf-oauth-discovery.  As such, it contains the same registry for OAuth Config Metadata as the authors believe that both solutions are not required, or depending on WG discussion they will be merged. The intent is to provide a simple complete draft for consideration.

How it works...
Given that a client has previously discovered an OAuth protected resource, the bound configuration method allows a client to return the configuration for an oauth authorization server that can issue tokens for the resource URI specified by the client.  The AS is not required to be in the same domain.  The AS is however required to know if it can issue tokens for a resource service (which presumes some agreement exists on tokens etc).

The draft does not require that the resource exist (e.g. for unconfigured or new user based resources). It only requires that the AS service provider agrees it can issue tokens.

From a security perspective, returning the OAuth service configuration for a specified resource URI serves to confirm the client is in possession of a valid resource URI ensuring the client has received a valid set of endpoints for the resource and the associated oauth services.

I propose that the WG consider the alternate draft carefully as well as other submissions and evaluate the broader discovery problem before proceeding with WGLC on OAuth Discovery.

Thanks!

Phil

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

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-hunt-oauth-bound-config-00.txt
> Date: March 13, 2016 at 3:53:37 PM PDT
> To: "Phil Hunt" <[email-masked]>, "Anthony Nadalin" <[email-masked]>, "Tony Nadalin" <[email-masked]>
> 
> 
> A new version of I-D, draft-hunt-oauth-bound-config-00.txt
> has been successfully submitted by Phil Hunt and posted to the
> IETF repository.
> 
> Name:		draft-hunt-oauth-bound-config
> Revision:	00
> Title:		OAuth 2.0 Bound Configuration Lookup
> Document date:	2016-03-13
> Group:		Individual Submission
> Pages:		22
> URL:            https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
> Htmlized:       https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
> 
> 
> Abstract:
>   This specification defines a mechanism for the client of an OAuth 2.0
>   protected resource service to obtain the configuration details of an
>   OAuth 2.0 authorization server that is capable of authorizing access
>   to a specific resource service.  The information includes the OAuth
>   2.0 component endpoint location URIs and as well as authorization
>   server capabilities.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: John Bradley <[email-masked]>
Date: Sun, 13 Mar 2016 22:45:26 -0300

As I have told Phil off list.  

Discovery is the wrong place to try and provide security against man in the middle attacks on the RS.

This requires the client to know what the RS URI is before retrieving the information on the AS Configuration.

The proposal Mike and I have been working on requires the client to have a notion of what API it is looking for and retrieve the .well-known file for that API from the issuer.   That allows a protocol like Connect to register its own config file that can point to the RS.   

If the API specific well known is not available the client can try the default oauth-server one.

That then allows us to deal with restricting where AT are presented as part of the protocol rather then dragging discovery in as a requirement.

In my opinion the resource the token is targeted to should be separated from the scope and returned as part of the meta-data about the AT along with scopes granted and expiry time.   We should also have a input parameter for resources so that a client can restrict tokens issued to a subset of the ones granted by the refresh token.   It would then also be possible to ask a AS for a token for a unregistered RS and have the AS produce a JWT access token with the resource as an audience if policy allows.

That however was supposed to be dealt with as part of the mixed up client set of mitigations.  
In that the goal was to mitigate the attacks by returning meta-data about the tokens, and not to require discovery.

We intend to return “iss” and “cleint_id” for the code, and I intend to discuss at the F2F returning resource for AT as well.

Those mitigate the attack.  

I will continue to resist mixing up discovery of configuration meta-data with mitigation of the attacks.

We return meta-data about the tokens now, because AT are opaque to the client, we neglected to include some of the information for the client needs to be secure.   We just need to add that in to the existing flows.

While Phil’s proposal is easier for the AS to implement as an add on, it puts more of a burden on the client needing to potentially change how it stores the relationships between AS and RS to prevent compromise, I think the solution should be biased towards simplicity on the client side.

If we return the resources as part of the existing meta data the client checks that against the resource it intends to send the token to and if it is not in the list then it can’t send the token.  Simple check every time it gets a new AT, no optionality.

I am not saying anything new Nat has been advocating basically this for some time, and dis submit a draft.   I prefer to return the info in the existing format rather than as link headers,  but that is the largest difference between what Nat and I are saying with respect to resource.

That is the core of my problem with Phil’s draft.

I guess we will need to have a long conversation in BA.

Regards
John B.

> On Mar 13, 2016, at 8:12 PM, Phil Hunt <[email-masked]> wrote:
> 
>> From: [email-masked] <mailto:[email-masked]>
>> To: "Phil Hunt" <[email-masked] <mailto:[email-masked]>>, "Anthony Nadalin" <[email-masked] <mailto:[email-masked]>>, "Tony Nadalin" <[email-masked] <mailto:[email-masked]>>
>> 
>> 
>> URL:            https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt <https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt>
>> Status:         https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ <https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/>
>> Htmlized:       https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 <https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00>
>> 
>> 
>> Abstract:
>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>> 
>> The IETF Secretariat
>> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Jones <[email-masked]>
Date: Mon, 14 Mar 2016 05:28:48 +0000

Thanks for posting this, Phil.  It provides a concrete example of a way that protected resource discovery could be added to authorization server metadata discovery, and as such, should provide useful input for working group discussions on this topic.  It’s always great when someone takes the time to write an actual draft that can be examined and implemented, and I appreciate you doing that.

The content of your draft points out that there appears to be complete agreement on what the authorization server metadata format should be, which is great!  I’ll note that Section 3 of draft-hunt-oauth-bound-config-00 titled “Authorization Server Metadata” is an exact copy of Section 2 of draft-ietf-oauth-discovery-01 (with the same title), modulo applying a correction suggested by the working group.  To me this suggests that the authorization server metadata definitions in draft-ietf-oauth-discovery (which is now the whole normative content of the draft) are clearly ready for standardization, since even your alternative proposal includes them verbatim.

Reading your draft, the problem I have with it is that you are returning the AS metadata only as a WebFinger response, rather than as an https-protected resource published by the authorization server.  The choice to only return this via WebFinger makes your draft incompatible with most deployed implementations of OAuth metadata, including the 22 implementations using it listed at http://openid.net/certification/ (see the “OP Config” column in the table) and OAuth 2.0 libraries such as Microsoft’s “ADAL” library, which uses the metadata path for client configuration.  Without having ASs provide the metadata as an https-protected resource, implementations such as ADAL can’t use it for client configuration as the currently do.

Therefore, I would request that you make these minor revisions to your draft and republish, so as to provide a unified way forward that is compatible with all known existing OAuth Discovery deployments:

1.       Modify your section 2 “Authorization Server WebFinger Discovery” to have the WebFinger request return the issuer identifier for the AS as the “WebFinger “rel” value, rather than returning the metadata values by value as the “properties” value.

2.       Reference the metadata definitions from Section 2 of draft-ietf-oauth-discovery, rather than duplicating them in your Section 3.

That would have the advantage of paring your draft down to only the new things that it proposes, enabling them to be more clearly understood and evaluated on their own merits.  I look forward to the discussions of ways of performing additional kinds of OAuth discovery, and consider your draft a valuable input to those discussions.

                                                          Best wishes,
                                                          -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Sunday, March 13, 2016 6:45 PM
To: Phil Hunt <[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

Regards
John B.

On Mar 13, 2016, at 8:12 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

How it works...

Thanks!

Phil

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

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-hunt-oauth-bound-config-00.txt
Date: March 13, 2016 at 3:53:37 PM PDT
To: "Phil Hunt" <[email-masked]<mailto:[email-masked]>>, "Anthony Nadalin" <[email-masked]<mailto:[email-masked]>>, "Tony Nadalin" <[email-masked]<mailto:[email-masked]>>

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

The IETF Secretariat

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

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 14 Mar 2016 15:01:20 +0000

Mike, there is no need to rush standardizing the metadata since there are still obvious issues with discovery or what one thinks discovery should be and should not be. This is also not the OpenID Foundation, this group should not be constrained by what OpenID has done but we should be informed. Some companies/individuals may have taken what was used by OpenID and used that as Oauth Discovery but once again we should not be restrained in what is technically the best choice because OpenID did it a certain way, it may be that OpenID did it the best way but lets not try to force the decision bases upon OpenID Certification.

From: OAuth [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Sunday, March 13, 2016 10:29 PM
To: Phil Hunt <[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

Reading your draft, the problem I have with it is that you are returning the AS metadata only as a WebFinger response, rather than as an https-protected resource published by the authorization server.  The choice to only return this via WebFinger makes your draft incompatible with most deployed implementations of OAuth metadata, including the 22 implementations using it listed at http://openid.net/certification/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.net%2fcertification%2f&data=01%7c01%7ctonynad%40microsoft.com%7c58284b200e8f43930bf708d34bc98ca0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=0545jB5xOjrJF0Kre7BXKgdGBR6wZSTcHVEwftxjoUQ%3d> (see the “OP Config” column in the table) and OAuth 2.0 libraries such as Microsoft’s “ADAL” library, which uses the metadata path for client configuration.  Without having ASs provide the metadata as an https-protected resource, implementations such as ADAL can’t use it for client configuration as the currently do.

                                                          Best wishes,
                                                          -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Sunday, March 13, 2016 6:45 PM
To: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Cc: oauth <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

Regards
John B.

How it works...

Thanks!

Phil

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

Begin forwarded message:

Name:             draft-hunt-oauth-bound-config
Revision:         00
Title:               OAuth 2.0 Bound Configuration Lookup
Document date:          2016-03-13
Group:             Individual Submission
Pages:              22
URL:            https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2finternet-drafts%2fdraft-hunt-oauth-bound-config-00.txt&data=01%7c01%7ctonynad%40microsoft.com%7c58284b200e8f43930bf708d34bc98ca0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UB8l7iuCKiKlBGPc8FWwVGuX0sL30utwoGkHdnEP3dg%3d>
Status:         https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-hunt-oauth-bound-config%2f&data=01%7c01%7ctonynad%40microsoft.com%7c58284b200e8f43930bf708d34bc98ca0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=hRwZw4at5lMDnvxMQS998hoadtzmUuomSJnw5WcCNK8%3d>
Htmlized:       https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-hunt-oauth-bound-config-00&data=01%7c01%7ctonynad%40microsoft.com%7c58284b200e8f43930bf708d34bc98ca0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=fxrOEXrKOl%2beXwa%2fnM%2fEfHaRUXUIsHXcu3rfD3ofFQM%3d>

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2f&data=01%7c01%7ctonynad%40microsoft.com%7c58284b200e8f43930bf708d34bc98ca0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=4F7sO0JgzQvBe3HxUyOphLu85XG7U6hl3YTCrxkx8OY%3d>.

The IETF Secretariat

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

---

From: Phil Hunt <[email-masked]>
Date: Mon, 14 Mar 2016 11:56:17 -0700

Thanks to Mike and John for their feedback.  I’ll take each in turn:

Mike,

Regarding your suggested amendments

Item 1: Returning the config URL would create two problems. One,it makes bound discovery a two-step process - that adds complexity.  It seems far simpler to mandate TLS (which I think it already does in the security considerations).  

The two-step process allows the current discovery process to continue. I disagree with this. This is why I put forward an “alternate" draft that is almost the same but simply adds the check before returning the configuration data.  I worry that  developers would have no incentive to do the two-step approach. They would just start at step 2 which in turn puts AS’s at risk of exposing tokens because it works. This makes OAuth promiscuous.

Regarding existing implementations. Most of those implementations are for OIDC.  I think it makes sense for OIDF to continue use of OIDC's discovery spec because the UserInfo endpoint is well defined and the likelihood of a client mis-informed about the resource endpoint is not there.  IMO This does not apply to the broader OAuth community.

Item 2:  It may be appropriate to have a separate configuration registry specification, but I think we should hold off until we have a complete solution and then make the decision what drafts should exist and how many pieces.  A big concern is the perceived complexity of multiple solutions and multiple drafts.

As to John Bradley’s comments:

Re: Discovery is the wrong place to mitigate threats. 
I’m confused by this.  Our mandate was to solve a security threat by having a discovery specification to prevent clients being mis-lead about endpoints (of which resource service is one) in an oauth protected exchange.  Maybe what you mean is we should not use .well-known of any kind and we should just create a “/Config” endpoint to OAuth?

Re: Your proposal for MITM mitigation
You propose that instead the resource endpoint check should be in the oauth protocol itself.  The difference is that validation is transferred back to the client to get it right. As well, without the client informing the AS, I can’t see a way for the AS to know what endpoint the client is using.  The webfinger approach does this once and only requires that the host name be checked in many cases.

As a principle, the members have discussed many times that the AS service should do validation when possible — this was particularly true at the Germany meeting when this came up. This is why I prefer the client tell the service provider what it intends to do and the service provider can fail that request immediately if necessary. We don’t have to depend on the developer getting the spec correct to fail the correct way.

I worry that adding more parameters to the authz and token protocol flows increases complexity and attack surface. It also means per authorization validation has to take place vs. a one-time validation at config time.  Placing it in the configuration lookup phase (whether via web finger or just a special OAuth endpoint) seems more appropriate and far less complex - as the request itself is simple and has only one parameter. Here we are not considered about legitimacy of the client. we’re just concerned with the issue "has the client been correctly informed?”

That said, it may be that when we consider all the use cases, some combination of AS protocol and discovery may be both needed. I’m not ready to make conclusions about this.  The current oauth-discovery spec seems to put future generic clients at risk and that is my primary concern.

Best Regards,

Phil

@independentid

> On Mar 13, 2016, at 10:28 PM, Mike Jones <[email-masked]> wrote:
> 
> Reading your draft, the problem I have with it is that you are returning the AS metadata only as a WebFinger response, rather than as an https-protected resource published by the authorization server.  The choice to only return this via WebFinger makes your draft incompatible with most deployed implementations of OAuth metadata, including the 22 implementations using it listed athttp://openid.net/certification/ <http://openid.net/certification/> (see the “OP Config” column in the table) and OAuth 2.0 libraries such as Microsoft’s “ADAL” library, which uses the metadata path for client configuration.  Without having ASs provide the metadata as an https-protected resource, implementations such as ADAL can’t use it for client configuration as the currently do. <>
>  
> On Mar 13, 2016, at 8:12 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>  
> www.independentid.com <http://www.independentid.com/>
> [email-masked] <mailto:[email-masked]>
>  
> 
> 
> Begin forwarded message:
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: John Bradley <[email-masked]>
Date: Mon, 14 Mar 2016 18:13:49 -0300

We had two mandates.  One was to provide a spec for AS metadata.   The other was to mitigate the client mixup attack.  The request was to do the latter without requiring the former for clients that don’t otherwise need discovery.

Returning the issuer and client_id from the authorization endpoint and the client checking them can be done by the client without discovery. 

Any client that has the resource and issuer hard coded probably doesn’t need discovery.  
One of the things that a client will need discovery for is to find the RS, so requiring the client to know the RS URI before getting the AS config seems backwards to me. 

Unless the client tells the AS where it intends to use the token we will be leaving a security hole because the bearer tokens will have too loose an audience if they have one at all.

True you are telling the AS (Webfinger service) what the RS is but that is not at a place that is useful in the token production process.

I also think there are use cases where the AS doesn’t know all the possible RS.   That is not something that a out of band check can address.
There are also cases where a token might be good at multiple RS endpoints intentionally.  In your solution the client would need to make a discovery request for each endpoint.
Those requests lack the context of who the client and resource owner are.  I think that will be a problem in some use cases. 

If this is added to the token endpoint it would be checked when code or refresh are exchanged, not every time the token is used.   
With a out of band check the client would never know if a RS was removed/revoked.   

I don’t see checking when refreshing a token as something that is a huge burden.

If the server wants to do the check on it’s side then we could require the client to send the RS URI in the token request. that way you really know the client is not going to get a token for the wrong RS endpoint.
If you check out of band in discovery you really have no idea if the client is checking.

John B.

> On Mar 14, 2016, at 3:56 PM, Phil Hunt <[email-masked]> wrote:
> 
>> On Mar 13, 2016, at 10:28 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of John Bradley
>> To: Phil Hunt <[email-masked] <mailto:[email-masked]>>
>> Cc: oauth <[email-masked] <mailto:[email-masked]>>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Mon, 14 Mar 2016 15:17:11 -0700

Inline

Phil

> On Mar 14, 2016, at 14:13, John Bradley <[email-masked]> wrote:
> 
There is no mandate for any of this. See http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt
> Returning the issuer and client_id from the authorization endpoint and the client checking them can be done by the client without discovery. 

How does this address the issue of whether the client is talking to the wrong endpoint?
> Any client that has the resource and issuer hard coded probably doesn’t need discovery.  
We agree

> One of the things that a client will need discovery for is to find the RS, so requiring the client to know the RS URI before getting the AS config seems backwards to me. 
How can you make an assumption on order? You seem to be conflating authentication with authorization by assuming the identity drives what the resource is. 

There are lots of applications that require user rights but are not identify centric. For example a document service. 
> Unless the client tells the AS where it intends to use the token we will be leaving a security hole because the bearer tokens will have too loose an audience if they have one at all.
This is the biggest risk we have IMHO. 
> True you are telling the AS (Webfinger service) what the RS is but that is not at a place that is useful in the token production process.

This has nothing to do with token production. 

What we want to ensure is whether an honest client is correctly configured and has not been mislead - eg by a phishing page. 
> I also think there are use cases where the AS doesn’t know all the possible RS.   That is not something that a out of band check can address.

May be. Lets identify them. 

> There are also cases where a token might be good at multiple RS endpoints intentionally.

>  In your solution the client would need to make a discovery request for each endpoint.
Sure. Otherwise how would it know if there is one AS or a pool of AS servers assigned to each instance?
> Those requests lack the context of who the client and resource owner are.  I think that will be a problem in some use cases. 

Not sure I agree. This is about discovering a valid set of endpoints. For mitm, we mainly want to check the hostname is correct. If a client chooses evil.com the cert can be valid and TLS will pass. How does it otherwise know it is supposed to talk to res.example.com?
> If this is added to the token endpoint it would be checked when code or refresh are exchanged, not every time the token is used.   
Your proposal requires rhe client to check. I am not clear how the AS can know the exact uri. It is far easier to validate than to lookup since as you say the client may be authorized to use multiple ASs. 
> With a out of band check the client would never know if a RS was removed/revoked.  

Not sure that is in scope. 

None of the current proposals address this issue. 
> I don’t see checking when refreshing a token as something that is a huge burden.

Still its a lot more than once. 

Why don't you draft another alternative?
> If you check out of band in discovery you really have no idea if the client is checking.

In the new webfinger draft, the client isn't checking. The service provider simply does not disclose oauth information to misconfigured clients. 
>> www.independentid.com
>> [email-masked]
>>> Reading your draft, the problem I have with it is that you are returning the AS metadata only as a WebFinger response, rather than as an https-protected resource published by the authorization server.  The choice to only return this via WebFinger makes your draft incompatible with most deployed implementations of OAuth metadata, including the 22 implementations using it listed athttp://openid.net/certification/ (see the “OP Config” column in the table) and OAuth 2.0 libraries such as Microsoft’s “ADAL” library, which uses the metadata path for client configuration.  Without having ASs provide the metadata as an https-protected resource, implementations such as ADAL can’t use it for client configuration as the currently do.
>>>  
>>> www.independentid.com
>>> [email-masked]

---

From: Hans Zandbelt <[email-masked]>
Date: Mon, 14 Mar 2016 22:26:04 +0000

On 3/14/16 10:17 PM, Phil Hunt (IDM) wrote:
<snip>
> On Mar 14, 2016, at 14:13, John Bradley <[email-masked]
> <mailto:[email-masked]>> wrote:

Yet any client that has hard coded a resource and 2 issuers doesn't need 
discovery either but is vulnerable to the IDP mixup attack.

I'd really like to see the two being addressed independently of each 
other, regardless of the fact that a Discovery solution *could* solve 
the IDP mixup attack as well.

Hans.

-- 
Hans Zandbelt              | Sr. Technical Architect
[email-masked] | Ping Identity

---

From: John Bradley <[email-masked]>
Date: Mon, 14 Mar 2016 19:26:34 -0300

Yes I will work on another proposal for allowing clients to specify what resource they want a token for and providing the meta-data to the client about the resources that a token is valid for.

We have part of it in the POP key distribution spec and talked about separating it, as it is used more places than just for assigning keys.   
I know some AS use different token formats for different RS so are all-ready needing to pass the resource in the request to avoid making a mess of scopes.

John B.

> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) <[email-masked]> wrote:
> 
> Inline
> 
> Phil
> 
> On Mar 14, 2016, at 14:13, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> 
> There is no mandate for any of this. See http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt <http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt>
>> 
> Not sure I agree. This is about discovering a valid set of endpoints. For mitm, we mainly want to check the hostname is correct. If a client chooses evil.com <http://evil.com/> the cert can be valid and TLS will pass. How does it otherwise know it is supposed to talk to res.example.com <http://res.example.com/>?
>> 
>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 14 Mar 2016 22:29:55 +0000

I would really like to see a comprehensive solution not this piece work, so we know what we are solving and what we are not.

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hans Zandbelt
Sent: Monday, March 14, 2016 3:26 PM
To: Phil Hunt (IDM) <[email-masked]>; John Bradley <[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

>> Any client that has the resource and issuer hard coded probably 
>> doesn't need discovery.
> We agree

Yet any client that has hard coded a resource and 2 issuers doesn't need discovery either but is vulnerable to the IDP mixup attack.

I'd really like to see the two being addressed independently of each other, regardless of the fact that a Discovery solution *could* solve the IDP mixup attack as well.

Hans.

_______________________________________________
OAuth mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c8cd9a8b2e020444382a708d34c57a6b4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1dsstJfhduQ3mZERUx6%2fO3OE241RK7ataalg6RY6JmA%3d

---

From: Justin Richer <[email-masked]>
Date: Mon, 14 Mar 2016 18:44:34 -0400

I agree that this is valuable, and not just for PoP. In all honesty, it’s not even really required for PoP to function in many cases — it’s just an optimization for one particular kind of key distribution mechanism in that case.

In the years of deployment experience with OAuth 2, I think we’ve really got three different kinds of things that currently get folded into “scope” that we might want to try separating out better:

 - What things do I want to access? (photos, profile)
 - What actions do I want to take on these things? (read, write, delete)
 - How long do I want these tokens to work? (offline_access/refresh_token, one time use, next hour, etc)

I think the first one is close to the audience/resource parameters that have been bandied about a few times, including in the current token exchange document. We should be consistent across drafts in that regard. The second is more traditional scope-ish. The third has been patched in with things like “offline_access” in certain APIs.

Just another vector to think about if we’re going to be adding things like “audience” or “resource” or both to the token requests.

 — Justin

> On Mar 14, 2016, at 6:26 PM, John Bradley <[email-masked]> wrote:
> 
>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Inline
>> 
>> Phil
>>

---

From: John Bradley <[email-masked]>
Date: Mon, 14 Mar 2016 20:29:06 -0300

Yes Brian and I discussed the reasons for separating audience/resource/destination from scope yesterday, and how that might impact token exchange and the need to align.

I think this is a core problem that needs to be addressed.   

The mixup at the resource is posable because scope is too overloaded.  Unless scopes were structured the client can’t tell what resource servers apply to a given scope.
The AS winds up applying the wrong audience to the AT, and the client has no way to tell.

There is no problem with giving a AT to a bad  or unknown RS.  That needs to be made safe by putting the correct audience in the AT.  
To do that the AS needs to know where the client is going to use the token so it can produce the correct token type and include the correct audience.

I agree that we also see a lot of hacks around using scopes and other mechanisms to indicate requested token validity time.

Scope is too overloaded, and we don’t return sufficient token meta-data with the opaque tokens.   
We need to address the core problem and not patch a symptom by adding external discovery.

John B.

> On Mar 14, 2016, at 7:44 PM, Justin Richer <[email-masked]> wrote:
> 
>> On Mar 14, 2016, at 6:26 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Hans Zandbelt <[email-masked]>
Date: Mon, 14 Mar 2016 23:29:19 +0000

+1, I've found the very same in OAuth deployments that I was involved 
in; the hard part is to give names and descriptions to these concepts so 
that they cover all use cases and can be applied unambiguously

Hans.

On 3/14/16 10:44 PM, Justin Richer wrote:
> I agree that this is valuable, and not just for PoP. In all honesty,
> it’s not even really required for PoP to function in many cases — it’s
> just an optimization for one particular kind of key distribution
> mechanism in that case.
>
> In the years of deployment experience with OAuth 2, I think we’ve really
> got three different kinds of things that currently get folded into
> “scope” that we might want to try separating out better:
>
>
>   - How long do I want these tokens to work?
> (offline_access/refresh_token, one time use, next hour, etc)
>
>
> I think the first one is close to the audience/resource parameters that
> have been bandied about a few times, including in the current token
> exchange document. We should be consistent across drafts in that regard.
> The second is more traditional scope-ish. The third has been patched in
> with things like “offline_access” in certain APIs.
>
> Just another vector to think about if we’re going to be adding things
> like “audience” or “resource” or both to the token requests.
>
>   — Justin
>
>
>> Yes I will work on another proposal for allowing clients to specify
>> what resource they want a token for and providing the meta-data to the
>> client about the resources that a token is valid for.
>>
>> We have part of it in the POP key distribution spec and talked about
>> separating it, as it is used more places than just for assigning keys.
>> I know some AS use different token formats for different RS so are
>> all-ready needing to pass the resource in the request to avoid making
>> a mess of scopes.
>>
>> John B.
>>
>>
>>
>>
>>
>>>> We had two mandates.  One was to provide a spec for AS metadata.
>>>> The other was to mitigate the client mixup attack.  The request was
>>>> to do the latter without requiring the former for clients that don’t
>>>> otherwise need discovery.
>>> There is no mandate for any of this. See
>>> http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt
>>>>
>>>> Returning the issuer and client_id from the authorization endpoint
>>>> and the client checking them can be done by the client without
>>>> discovery.
>>>
>>>> doesn’t need discovery.
>>>> One of the things that a client will need discovery for is to find
>>>> the RS, so requiring the client to know the RS URI before getting
>>>> the AS config seems backwards to me.
>>> How can you make an assumption on order? You seem to be conflating
>>> authentication with authorization by assuming the identity drives
>>> what the resource is.
>>>
>>> There are lots of applications that require user rights but are not
>>> identify centric. For example a document service.
>>>>
>>>> Unless the client tells the AS where it intends to use the token we
>>>> will be leaving a security hole because the bearer tokens will have
>>>> too loose an audience if they have one at all.
>>>> True you are telling the AS (Webfinger service) what the RS is but
>>>> that is not at a place that is useful in the token production process.
>>>
>>> What we want to ensure is whether an honest client is correctly
>>> configured and has not been mislead - eg by a phishing page.
>>>>
>>>> I also think there are use cases where the AS doesn’t know all the
>>>> possible RS.   That is not something that a out of band check can
>>>> address.
>>>
>>>> Those requests lack the context of who the client and resource owner
>>>> are.  I think that will be a problem in some use cases.
>>>
>>> Not sure I agree. This is about discovering a valid set of endpoints.
>>> For mitm, we mainly want to check the hostname is correct. If a
>>> client chooses evil.com <http://evil.com/> the cert can be valid and
>>> TLS will pass. How does it otherwise know it is supposed to talk to
>>> res.example.com <http://res.example.com/>?
>>>>
>>>> If this is added to the token endpoint it would be checked when code
>>>> or refresh are exchanged, not every time the token is used.
>>> Your proposal requires rhe client to check. I am not clear how the AS
>>> can know the exact uri. It is far easier to validate than to lookup
>>> since as you say the client may be authorized to use multiple ASs.
>>>> If the server wants to do the check on it’s side then we could
>>>> require the client to send the RS URI in the token request. that way
>>>> you really know the client is not going to get a token for the wrong
>>>> RS endpoint.
>>> In the new webfinger draft, the client isn't checking. The service
>>> provider simply does not disclose oauth information to misconfigured
>>> clients.
>>>>
>>>> John B.
>>>>
>>>>
>>>>> Item 1: Returning the config URL would create two problems. One,it
>>>>> makes bound discovery a two-step process - that adds complexity.
>>>>>  It seems far simpler to mandate TLS (which I think it already does
>>>>> in the security considerations).
>>>>>
>>>>> The two-step process allows the current discovery process to
>>>>> continue. I disagree with this. This is why I put forward an
>>>>> “alternate" draft that is almost the same but simply adds the check
>>>>> before returning the configuration data.  I worry that  developers
>>>>> would have no incentive to do the two-step approach. They would
>>>>> just start at step 2 which in turn puts AS’s at risk of exposing
>>>>> tokens because it works. This makes OAuth promiscuous.
>>>>>
>>>>> Regarding existing implementations. Most of those implementations
>>>>> are for OIDC.  I think it makes sense for OIDF to continue use of
>>>>> OIDC's discovery spec because the UserInfo endpoint is well defined
>>>>> and the likelihood of a client mis-informed about the resource
>>>>> endpoint is not there.  IMO This does not apply to the broader
>>>>> OAuth community.
>>>>>
>>>>> Item 2:  It may be appropriate to have a separate configuration
>>>>> registry specification, but I think we should hold off until we
>>>>> have a complete solution and then make the decision what drafts
>>>>> should exist and how many pieces.  A big concern is the perceived
>>>>> complexity of multiple solutions and multiple drafts.
>>>>>
>>>>> I’m confused by this.  Our mandate was to solve a security threat
>>>>> by having a discovery specification to prevent clients being
>>>>> mis-lead about endpoints (of which resource service is one) in an
>>>>> oauth protected exchange.  Maybe what you mean is we should not use
>>>>> .well-known of any kind and we should just create a “/Config”
>>>>> endpoint to OAuth?
>>>>>
>>>>> You propose that instead the resource endpoint check should be in
>>>>> the oauth protocol itself.  The difference is that validation is
>>>>> transferred back to the client to get it right. As well, without
>>>>> the client informing the AS, I can’t see a way for the AS to know
>>>>> what endpoint the client is using.  The webfinger approach does
>>>>> this once and only requires that the host name be checked in many
>>>>> cases.
>>>>>
>>>>> As a principle, the members have discussed many times that the AS
>>>>> service should do validation when possible — this was particularly
>>>>> true at the Germany meeting when this came up. This is why I prefer
>>>>> the client tell the service provider what it intends to do and the
>>>>> service provider can fail that request immediately if necessary. We
>>>>> don’t have to depend on the developer getting the spec correct to
>>>>> fail the correct way.
>>>>>
>>>>> I worry that adding more parameters to the authz and token protocol
>>>>> flows increases complexity and attack surface. It also means per
>>>>> authorization validation has to take place vs. a one-time
>>>>> validation at config time.  Placing it in the configuration lookup
>>>>> phase (whether via web finger or just a special OAuth endpoint)
>>>>> seems more appropriate and far less complex - as the request itself
>>>>> is simple and has only one parameter. Here we are not considered
>>>>> about legitimacy of the client. we’re just concerned with the issue
>>>>> "has the client been correctly informed?”
>>>>>
>>>>> That said, it may be that when we consider all the use cases, some
>>>>> combination of AS protocol and discovery may be both needed. I’m
>>>>> not ready to make conclusions about this.  The current
>>>>> oauth-discovery spec seems to put future generic clients at risk
>>>>> and that is my primary concern.
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Phil
>>>>>
>>>>> @independentid
>>>>>> On Mar 13, 2016, at 10:28 PM, Mike Jones
>>>>>> <[email-masked] <mailto:[email-masked]>>
>>>>>> wrote:
>>>>>>
>>>>>> Thanks for posting this, Phil.  It provides a concrete example of
>>>>>> a way that protected resource discovery could be added to
>>>>>> authorization server metadata discovery, and as such, should
>>>>>> provide useful input for working group discussions on this topic.
>>>>>> It’s always great when someone takes the time to write an actual
>>>>>> draft that can be examined and implemented, and I appreciate you
>>>>>> doing that.
>>>>>> The content of your draft points out that there appears to be
>>>>>> complete agreement on what the authorization server metadata
>>>>>> format should be, which is great!  I’ll note that Section 3 of
>>>>>> draft-hunt-oauth-bound-config-00 titled “Authorization Server
>>>>>> Metadata” is an exact copy of Section 2 of
>>>>>> draft-ietf-oauth-discovery-01 (with the same title), modulo
>>>>>> applying a correction suggested by the working group.  To me this
>>>>>> suggests that the authorization server metadata definitions in
>>>>>> draft-ietf-oauth-discovery (which is now the whole normative
>>>>>> content of the draft) are clearly ready for standardization, since
>>>>>> even your alternative proposal includes them verbatim.
>>>>>> Reading your draft, the problem I have with it is that you are
>>>>>> returning the AS metadata only as a WebFinger response, rather
>>>>>> than as an https-protected resource published by the authorization
>>>>>> server.  The choice to only return this via WebFinger makes your
>>>>>> draft incompatible with most deployed implementations of OAuth
>>>>>> metadata, including the 22 implementations using it listed
>>>>>> athttp://openid.net/certification/(see the “OP Config” column in
>>>>>> the table) andOAuth 2.0 libraries such as Microsoft’s “ADAL”
>>>>>> library, which uses the metadata path for client configuration.
>>>>>> Without having ASs provide the metadata as an https-protected
>>>>>> resource, implementations such as ADAL can’t use it for client
>>>>>> configuration as the currently do.
>>>>>> Therefore, I would request that you make these minor revisions to
>>>>>> your draft and republish, so as to provide a unified way forward
>>>>>> that is compatible with all known existing OAuth Discovery
>>>>>> deployments:
>>>>>> 1.Modify your section 2 “Authorization Server WebFinger Discovery”
>>>>>> to have the WebFinger request return the issuer identifier for the
>>>>>> AS as the “WebFinger “rel” value, rather than returning the
>>>>>> metadata values by value as the “properties” value.
>>>>>> 2.Reference the metadata definitions from Section 2 of
>>>>>> draft-ietf-oauth-discovery, rather than duplicating them in your
>>>>>> Section 3.
>>>>>> That would have the advantage of paring your draft down to only
>>>>>> the new things that it proposes, enabling them to be more clearly
>>>>>> understood and evaluated on their own merits.  I look forward to
>>>>>> the discussions of ways of performing additional kinds of OAuth
>>>>>> discovery, and consider your draft a valuable input to those
>>>>>> discussions.
>>>>>>                                                           Best wishes,
>>>>>>                                                           -- Mike
>>>>>> *From:*OAuth [mailto:[email-masked]]*On Behalf Of*John Bradley
>>>>>> *Sent:*Sunday, March 13, 2016 6:45 PM
>>>>>> *To:*Phil Hunt <[email-masked] <mailto:[email-masked]>>
>>>>>> *Cc:*oauth <[email-masked] <mailto:[email-masked]>>
>>>>>> *Subject:*Re: [OAUTH-WG] New Version Notification for
>>>>>> draft-hunt-oauth-bound-config-00.txt
>>>>>> This requires the client to know what the RS URI is before
>>>>>> retrieving the information on the AS Configuration.
>>>>>> The proposal Mike and I have been working on requires the client
>>>>>> to have a notion of what API it is looking for and retrieve the
>>>>>> .well-known file for that API from the issuer.   That allows a
>>>>>> protocol like Connect to register its own config file that can
>>>>>> point to the RS.
>>>>>> That then allows us to deal with restricting where AT are
>>>>>> presented as part of the protocol rather then dragging discovery
>>>>>> in as a requirement.
>>>>>> In my opinion the resource the token is targeted to should be
>>>>>> separated from the scope and returned as part of the meta-data
>>>>>> about the AT along with scopes granted and expiry time.   We
>>>>>> should also have a input parameter for resources so that a client
>>>>>> can restrict tokens issued to a subset of the ones granted by the
>>>>>> refresh token.   It would then also be possible to ask a AS for a
>>>>>> token for a unregistered RS and have the AS produce a JWT access
>>>>>> token with the resource as an audience if policy allows.
>>>>>> In that the goal was to mitigate the attacks by returning
>>>>>> meta-data about the tokens, and not to require discovery.
>>>>>> We intend to return “iss” and “cleint_id” for the code, and I
>>>>>> intend to discuss at the F2F returning resource for AT as well.
>>>>>> I will continue to resist mixing up discovery of configuration
>>>>>> meta-data with mitigation of the attacks.
>>>>>> We return meta-data about the tokens now, because AT are opaque to
>>>>>> the client, we neglected to include some of the information for
>>>>>> the client needs to be secure.   We just need to add that in to
>>>>>> the existing flows.
>>>>>> While Phil’s proposal is easier for the AS to implement as an add
>>>>>> on, it puts more of a burden on the client needing to potentially
>>>>>> change how it stores the relationships between AS and RS to
>>>>>> prevent compromise, I think the solution should be biased towards
>>>>>> simplicity on the client side.
>>>>>> If we return the resources as part of the existing meta data the
>>>>>> client checks that against the resource it intends to send the
>>>>>> token to and if it is not in the list then it can’t send the
>>>>>> token.  Simple check every time it gets a new AT, no optionality.
>>>>>> I am not saying anything new Nat has been advocating basically
>>>>>> this for some time, and dis submit a draft.   I prefer to return
>>>>>> the info in the existing format rather than as link headers,  but
>>>>>> that is the largest difference between what Nat and I are saying
>>>>>> with respect to resource.
>>>>>>     This draft is a proposed alternate proposal for
>>>>>>     draft-ietf-oauth-discovery.  As such, it contains the same
>>>>>>     registry for OAuth Config Metadata as the authors believe that
>>>>>>     both solutions are not required, or depending on WG discussion
>>>>>>     they will be merged. The intent is to provide a simple
>>>>>>     complete draft for consideration.
>>>>>>     How it works...
>>>>>>     Given that a client has previously discovered an OAuth
>>>>>>     protected resource, the bound configuration method allows a
>>>>>>     client to return the configuration for an oauth authorization
>>>>>>     server that can issue tokens for the resource URI specified by
>>>>>>     the client.  The AS is not required to be in the same domain.
>>>>>>      The AS is however required to know if it can issue tokens for
>>>>>>     a resource service (which presumes some agreement exists on
>>>>>>     tokens etc).
>>>>>>     The draft does not require that the resource exist (e.g. for
>>>>>>     unconfigured or new user based resources). It only requires
>>>>>>     that the AS service provider agrees it can issue tokens.
>>>>>>     From a security perspective, returning the OAuth service
>>>>>>     configuration for a specified resource URI serves to confirm
>>>>>>     the client is in possession of a valid resource URI ensuring
>>>>>>     the client has received a valid set of endpoints for the
>>>>>>     resource and the associated oauth services.
>>>>>>     I propose that the WG consider the alternate draft carefully
>>>>>>     as well as other submissions and evaluate the broader
>>>>>>     discovery problem before proceeding with WGLC on OAuth Discovery.
>>>>>>     Thanks!
>>>>>>     Phil
>>>>>>     @independentid
>>>>>>         *From:[email-masked]
>>>>>>         <mailto:[email-masked]>
>>>>>>         *Subject: New Version Notification for
>>>>>>         draft-hunt-oauth-bound-config-00.txt*
>>>>>>         *Date:*March 13, 2016 at 3:53:37 PM PDT
>>>>>>         *To:*"Phil Hunt" <[email-masked]
>>>>>>         <mailto:[email-masked]>>, "Anthony Nadalin"
>>>>>>         <[email-masked] <mailto:[email-masked]>>,
>>>>>>         "Tony Nadalin" <[email-masked]
>>>>>>         <mailto:[email-masked]>>
>>>>>>
>>>>>>
>>>>>>         Name:draft-hunt-oauth-bound-config
>>>>>>         Revision:00
>>>>>>         Title:OAuth 2.0 Bound Configuration Lookup
>>>>>>         Document date:2016-03-13
>>>>>>         Group:Individual Submission
>>>>>>         Pages:22
>>>>>>         URL:
>>>>>>         https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt
>>>>>>         Status:
>>>>>>         https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/
>>>>>>         Htmlized:
>>>>>>         https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00
>>>>>>
>>>>>>
>>>>>>         Abstract:
>>>>>>         until the htmlized version and diff are available
>>>>>>         attools.ietf.org <http://tools.ietf.org/>.
>>>>>>
>>>>>>         The IETF Secretariat
>>>>>>

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 15 Mar 2016 12:37:59 +0000

Hi All

I've alway been thinking of Client Credentials as being the simplest 
flow but now that I'm looking at implementing it myself to be used in 
the real productions, I'm realizing that there's something I do not 
understand about it:

Do the clients using Client Credentials flow need to be 
OAuth2-registered, even when such clients are already known to the 
authentication system ?

For example, there might be some LDAP/etc entry for Alice (name, 
password). Now a client is using a client credentials flow to get an 
access token:

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

I hope that in this case no explicit registration (the one typically 
required in redirection based flows) is needed, the client (Alice) has 
been 'implicitly' registered (as far as the notion of OAuth2 client is 
concerned) in LDAP/etc.

If the explicit registration with OAuth2 AS was still required in the 
case above then it would lead to a fairly massive duplication of effort 
(Alice is registered in Ldap, then also with OAuth2 AS), etc

Can someone clarify it please ?

Thanks, Sergey

---

From: Justin Richer <[email-masked]>
Date: Tue, 15 Mar 2016 08:53:12 -0400

Is Alice the client here (the piece of software), or is Alice the 
resource owner? If Alice is the resource owner, then you should 
absolutely not be using the client credentials flow like this.

The client credentials flow is designed for cases where the client is 
acting on its own behalf, not on behalf of any particular user. It's an 
optimization of the canonical authorization code flow, where there is no 
interaction with the resource owner because there is no resource owner 
as a separate entity. It's most useful for backend systems that would 
have traditionally used a developer key to get access to bulk data. If 
you're using it for single-user access, you're doing it wrong.

Also, you should keep in mind that things that seem "simple" on the 
surface are often simplified at the cost of making specific security 
concessions and assumptions. The authorization code flow is "complex" 
for very good reasons, all of them security focused. You should never 
pick a different OAuth flow just because it looks simpler, you should 
only pick them if you're within the use case that it was designed for, 
and therefor the assumptions of its security patterns match.

We've seen a *ton* of problems with people picking the implicit flow in 
the real world and using it with clients other than in-browser 
applications that it was designed for. If you're not in that specific 
space, you're taking on huge risks.

  -- Justin

On 3/15/2016 8:37 AM, Sergey Beryozkin wrote:
> case above then it would lead to a fairly massive duplication of 
> effort (Alice is registered in Ldap, then also with OAuth2 AS), etc
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 15 Mar 2016 13:01:16 +0000

Hi

After following the recent thread on multiple authorization servers, but 
also reading some other related threads, I have a question related to 
when the token introspection can be avoided.

My understanding has been that given that access tokens are opaque the 
RS does not know anything about its content, hence that was the purpose 
of the token introspection spec: provide an interoperable way for RS to 
submit a token to AS and get the token data for RS to make a final 
decision about this token.

I think if the access tokens are really opaque, i.e, they are sequences 
RS can not look into, then having the introspection option is the only 
way to check what the token is really about.

But the recent replies with respect to using JWS or JWE tokens have 
confused me.

1. AccessToken as JWS JWT Token:

RS can easily look into it, but Justin mentioned that in one case they 
first validate this JWS token and then forward it for some further 
introspection. Why start introspecting if the token has been validated 
and its content is visible ?
Perhaps because some token data which are sensitive are only visible in 
the introspection response ? If yes then why use a self-contained token 
if some more external data are associated with it.

2. AccessToken as JWE JWT Token: this option was mentioned a couple of 
times recently, Jonh B. suggested in the other thread the introspection 
may not be needed (sorry if I misread it).
The question here, how can RS deal with a JWE token, it would need to 
share the decrypting key with AS.

So, is introspection needed only for the completely opaque tokens or it 
is also needed for JWS and JWE tokens. I'd say it might be reasonable to 
skip it in case of JWS, depending on the specific requirements (as the 
expiry, issuer, will be typically set in JWS JWT), while with JWE I can 
not see how RS can avoid introspecting unless it shares the 
secret/private key with AS.

Thanks, Sergey

---

From: John Bradley <[email-masked]>
Date: Tue, 15 Mar 2016 10:05:07 -0300

I think you may be confusing Client credentials flow with resource owner credentials flow.

If there is a resource owner in the flow use code.   The resource owner credentials flow is a bad idea and only put in for backwards compatibility.

John B.

> On Mar 15, 2016, at 9:37 AM, Sergey Beryozkin <[email-masked]> wrote:
> 
> Hi All
> 
> I've alway been thinking of Client Credentials as being the simplest flow but now that I'm looking at implementing it myself to be used in the real productions, I'm realizing that there's something I do not understand about it:
> 
> Do the clients using Client Credentials flow need to be OAuth2-registered, even when such clients are already known to the authentication system ?
> 
> For example, there might be some LDAP/etc entry for Alice (name, password). Now a client is using a client credentials flow to get an access token:
> 
> POST /token HTTP/1.1
> Host: server.example.com
> I hope that in this case no explicit registration (the one typically required in redirection based flows) is needed, the client (Alice) has been 'implicitly' registered (as far as the notion of OAuth2 client is concerned) in LDAP/etc.
> 
> If the explicit registration with OAuth2 AS was still required in the case above then it would lead to a fairly massive duplication of effort (Alice is registered in Ldap, then also with OAuth2 AS), etc
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 15 Mar 2016 09:11:30 -0400

The access tokens are opaque to the client, not the RS.

  -- Justin

On 3/15/2016 9:01 AM, Sergey Beryozkin wrote:
> Hi
>
> After following the recent thread on multiple authorization servers, 
> but also reading some other related threads, I have a question related 
> to when the token introspection can be avoided.
>
> RS does not know anything about its content, hence that was the 
> purpose of the token introspection spec: provide an interoperable way 
> for RS to submit a token to AS and get the token data for RS to make a 
> final decision about this token.
>
> I think if the access tokens are really opaque, i.e, they are 
> sequences RS can not look into, then having the introspection option 
> is the only way to check what the token is really about.
>
> Perhaps because some token data which are sensitive are only visible 
> in the introspection response ? If yes then why use a self-contained 
> token if some more external data are associated with it.
>
> times recently, Jonh B. suggested in the other thread the 
> introspection may not be needed (sorry if I misread it).
> So, is introspection needed only for the completely opaque tokens or 
> it is also needed for JWS and JWE tokens. I'd say it might be 
> reasonable to skip it in case of JWS, depending on the specific 
> requirements (as the expiry, issuer, will be typically set in JWS 
> JWT), while with JWE I can not see how RS can avoid introspecting 
> unless it shares the secret/private key with AS.
>
>
> Thanks, Sergey
>
>
>
>
>

---

From: John Bradley <[email-masked]>
Date: Tue, 15 Mar 2016 10:12:16 -0300

Access tokens are opaque to the client not the RS.

You have three basic design choices.
1 Use a token that the RS can locally validate.  JWT or SAML are standard options or you could do your own custom format and use a HMAC to integrity protect them.  If using astandard token format this supports multiple AS.

2 Use a completely opaque token and introspect it at a known AS.  This supports one AS

3 Hybrid use a JWT that contains an issuer as the token but with a single opaque claim that is used as a ID by the AS.  The RS receives the token looks at the issuer and sends the token to the issuer for introspection.   The  introspection endpoint checks the signature and looks up the reference to provide the introspection response as in 2.   This supports multiple AS.

I think Juston was recommending 3 as something he has done.

John B.

> On Mar 15, 2016, at 10:01 AM, Sergey Beryozkin <[email-masked]> wrote:
> 
> Hi
> 
> After following the recent thread on multiple authorization servers, but also reading some other related threads, I have a question related to when the token introspection can be avoided.
> 
> My understanding has been that given that access tokens are opaque the RS does not know anything about its content, hence that was the purpose of the token introspection spec: provide an interoperable way for RS to submit a token to AS and get the token data for RS to make a final decision about this token.
> 
> I think if the access tokens are really opaque, i.e, they are sequences RS can not look into, then having the introspection option is the only way to check what the token is really about.
> 
> But the recent replies with respect to using JWS or JWE tokens have confused me.
> 
> RS can easily look into it, but Justin mentioned that in one case they first validate this JWS token and then forward it for some further introspection. Why start introspecting if the token has been validated and its content is visible ?
> Perhaps because some token data which are sensitive are only visible in the introspection response ? If yes then why use a self-contained token if some more external data are associated with it.
> 
> 2. AccessToken as JWE JWT Token: this option was mentioned a couple of times recently, Jonh B. suggested in the other thread the introspection may not be needed (sorry if I misread it).
> The question here, how can RS deal with a JWE token, it would need to share the decrypting key with AS.
> 
> So, is introspection needed only for the completely opaque tokens or it is also needed for JWS and JWE tokens. I'd say it might be reasonable to skip it in case of JWS, depending on the specific requirements (as the expiry, issuer, will be typically set in JWS JWT), while with JWE I can not see how RS can avoid introspecting unless it shares the secret/private key with AS.
> 
> 
> Thanks, Sergey
> 
> 
> 
> 
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 15 Mar 2016 13:17:47 +0000

Hi Justin

Many thanks for the quick response.
On 15/03/16 12:53, Justin Richer wrote:
> resource owner?
Piece of software, something that needs to run without the human user 
being involved
> If Alice is the resource owner, then you should
Sure.

> you're using it for single-user access, you're doing it wrong.
I guess I'm still OK here, as I said, it is a piece of software which 
runs without a user. Like in all web services (SOAP or plain HTTP client 
invocations) where the client sets some credentials and accesses some 
data in the remote service.

> and therefor the assumptions of its security patterns match.
+1
> space, you're taking on huge risks.
Sure, I understand.

So, as far as my original question is concerned, given that a client 
piece of software (no human user is involved) uses some credentials to 
get the token with client_credentials, would it be OK to avoid the 
explicit 'Client' registration with AS, given that the authentication 
system employed by AS is already aware of such credentials, I guess yes.

Thanks, Sergey

---

From: Justin Richer <[email-masked]>
Date: Tue, 15 Mar 2016 09:18:38 -0400

And don't forget option 4: look it up in a database because the RS and 
AS are in the same box.

  -- Justin

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 15 Mar 2016 13:21:56 +0000

Hi John
> I think you may be confusing Client credentials flow with resource owner credentials flow.
Sorry, I should've clarified initially, it is a piece of software that 
needs to run without a human user. So I hope it is still client_credentials.

> If there is a resource owner in the flow use code.   The resource owner credentials flow is a bad idea and only put in for backwards compatibility.
Right, I was about to ask how resource owner credentials can help :-), 
but I guess I'll stay away from it for now.

Thanks, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 15 Mar 2016 13:31:51 +0000

Hi John, Justin
> Access tokens are opaque to the client not the RS.
But only if they are self-contained as in the option 1 below, right ?
> 1 Use a token that the RS can locally validate.  JWT or SAML are standard options or you could do your own custom format and use a HMAC to integrity protect them.  If using astandard token format t…

OK.
> 2 Use a completely opaque token and introspect it at a known AS.  This supports one AS
OK

> I think Juston was recommending 3 as something he has done.
Thanks for clarifying it, that was what 'jti' was for I believe, very 
interesting, I did not get the first time I read it for sure :-).
But this is a non-interoperable solution, right ? I.e, it depends on a 
given AS preparing a token this way, would other AS be able to do it too ?

Thanks, Sergey

---

From: Justin Richer <[email-masked]>
Date: Tue, 15 Mar 2016 09:33:35 -0400

Hi Sergey, one comment inline

> But only if they are self-contained as in the option 1 below, right ?

No. They're non-opaque to the RS in all cases. In that, the RS needs to 
be able to figure out what information the token represents. That 
doesn't mean that the RS can *parse* the token, but it needs to be able 
to find all associated security info about the token (scopes, users, 
clients, expirations) in order to make it work.

>> 1 Use a token that the RS can locally validate.  JWT or SAML are 
>> standard options or you could do your own custom format and use a 
>> HMAC to integrity protect them.  If using astandard token format this 
>> supports multiple AS.
>
> OK.
>>
>> 3 Hybrid use a JWT that contains an issuer as the token but with a 
>> single opaque claim that is used as a ID by the AS.  The RS receives 
>> the token looks at the issuer and sends the token to the issuer for 
>> introspection.   The introspection endpoint checks the signature and 
>> looks up the reference to provide the introspection response as in 
>> 2.   This supports multiple AS.
>>
>>> but also reading some other related threads, I have a question 
>>> related to when the token introspection can be avoided.
>>>
>>> My understanding has been that given that access tokens are opaque 
>>> the RS does not know anything about its content, hence that was the 
>>> purpose of the token introspection spec: provide an interoperable 
>>> way for RS to submit a token to AS and get the token data for RS to 
>>> make a final decision about this token.
>>>
>>> RS can easily look into it, but Justin mentioned that in one case 
>>> they first validate this JWS token and then forward it for some 
>>> further introspection. Why start introspecting if the token has been 
>>> validated and its content is visible ?
>>> 2. AccessToken as JWE JWT Token: this option was mentioned a couple 
>>> of times recently, Jonh B. suggested in the other thread the

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 15 Mar 2016 13:35:19 +0000

Hi Justin

> And don't forget option 4: look it up in a database because the RS and
Sometimes I feel like I understand OAuth2 and today I'm feeling like 
I've no idea  what it is :-).

Are AS and RS meant to be collocated ? I thought it was a demo situation 
only :-)

Cheers, Sergey

>>> On Mar 15, 2016, at 10:01 AM, Sergey Beryozkin<[email-masked]>  wrote:
>>>
>>> Hi
>>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 15 Mar 2016 09:36:50 -0400

On 3/15/2016 9:35 AM, Sergey Beryozkin wrote:
> Are AS and RS meant to be collocated ? I thought it was a demo 
> situation only :-)
>
> Cheers, Sergey

They're conceptually separate, but they can be served by the same 
machine and therefore have trusted, proprietary, back-end communications 
between them that don't need to be interoperable. It's not just for 
demos, and it's actually one of the most common (if not the most common) 
deployment of OAuth 2.

  -- Justin

>>> HMAC to integrity protect them.  If using astandard token format 
>>> this supports multiple AS.
>>>
>>> introspection.   The  introspection endpoint checks the signature 
>>> and looks up the reference to provide the introspection response as 
>>> in 2.   This supports multiple AS.
>>>
>>>> After following the recent thread on multiple authorization 
>>>> servers, but also reading some other related threads, I have a 
>>>> question related to when the token introspection can be avoided.
>>>>
>>>> sequences RS can not look into, then having the introspection 
>>>> option is the only way to check what the token is really about.
>>>>
>>>> further introspection. Why start introspecting if the token has 
>>>> been validated and its content is visible ?
>>>> Perhaps because some token data which are sensitive are only 
>>>> visible in the introspection response ? If yes then why use a 
>>>> self-contained token if some more external data are associated with 
>>>> it.
>>>>
>>>> So, is introspection needed only for the completely opaque tokens 
>>>> or it is also needed for JWS and JWE tokens. I'd say it might be

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 15 Mar 2016 13:39:36 +0000

Hi Justin

It does help, thanks, I was really meaning to ask whether RS was able to 
parse it or not itself, without getting the external introspection 
support, but using a wrong term, 'opaque' for it :-).

Thanks
Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 15 Mar 2016 13:49:03 +0000

Hi Justin

I guess it depends on what the customer requirements are, with the AS 
vendor neutrality being one of the variables - something that we had to 
deal with recently.
Or if the RS stack is flexible in a way that it can be easily adapted to 
work with AS from multiple vendors. I can see how it works.

Thanks, Sergey

---

From: John Bradley <[email-masked]>
Date: Tue, 15 Mar 2016 11:12:49 -0300

One of the things JWT allows is interoperable access tokens from multiple AS.   

The OAuth specs have always been a bit hand-wavy about access tokens saying that they are a local implementation decision.

You can use JWT or introspection or a database lookup, but leave it to the implementation to decide.

With RS that are truly separate from AS and may be accepting tokens from multiple AS interoperability is perhaps becoming more of an issue.

At some point it might be worth the WG at-least laying out the options for developers in one place.

John B.

> On Mar 15, 2016, at 10:49 AM, Sergey Beryozkin <[email-masked]> wrote:
> 
> Hi Justin
> 
> I guess it depends on what the customer requirements are, with the AS vendor neutrality being one of the variables - something that we had to deal with recently.
> Or if the RS stack is flexible in a way that it can be easily adapted to work with AS from multiple vendors. I can see how it works.
> 
> Thanks, Sergey
>

---

From: George Fletcher <[email-masked]>
Date: Tue, 15 Mar 2016 10:57:32 -0400

We have also implemented option 3. In our case, the RS is supporting our 
own AS and an external trusted AS. The hybrid JWT allows us to know 
where to validate the token and also allows the external AS to protect 
it's token in a way that is not visible to us.

Thanks,
George

---

From: Brian Campbell <[email-masked]>
Date: Tue, 15 Mar 2016 09:00:12 -0600

Discovery in general for OAuth isn't well understood. This conversation and
others like it around the 'discovery' draft demonstrate that. But
publishing AS metadata is something that is understood and already in wide
use for Connect. The rough consensus (except for a very few but vocal
dissenters) on this list over the last few weeks/months has been that
draft-ietf-oauth-discovery should describing AS metadata and its location.
It's been suggested that the title reflect that scope and I might even
suggest that the document identifier be changed to avoid further
confusion.

The IDP mixup is addressed by the AS identifying itself to the client in
the authorization response (it has a few other things in it that arguably
shouldn't be in or should be elsewhere but that's a different question).
The Mix-Up Mitigation draft uses the issuer value to do that. Issuer
becomes a logical name/identifier for an AS. And that can tie it to AS
metadata or even discovery if/when that exists. But discovery or AS
metadata isn't necessary there. Yes Tony, we'd all like to see a
comprehensive solution but conflating different and unrelated things is
only making matters worse (as I'm sure you are well aware).

A 'bad RS' phishing for legitimate access tokens is a different kind of
endpoint confusion. Most deployments now have a static relationship defined
between RS and AS so it's more of a potential problem in the future.
Despite the concern voiced about it the potential (as far as I can tell
anyway), draft-hunt-oauth-bound-config provides a very nice attack vector
for such a 'bad RS' by pointing to an AS to obtain tokens it could misuse
at legitimate RS(s). John has alluded to this.

There have been a number of incremental updates/extensions to OAuth 2.0 and
there look to be more coming.  Concerns have been expressed over the number
of documents and implements knowing what to use when. I don't think the
answer is to try and jam unrelated new stuff into new docs to keep the
number of docs low is a good idea though. I'd much prefer to have concise
and cohesive documents. The larger issue of confusion around too many
documents should be addressed at a higher level. For example, something
like an implementation guide or even something like an OAuth 2.1 that
describes the available extensions and when/why one would use them.

On Mon, Mar 14, 2016 at 4:29 PM, Anthony Nadalin <[email-masked]>
wrote:

> I would really like to see a comprehensive solution not this piece work,
> so we know what we are solving and what we are not.
>
> other, regardless of the fact that a Discovery solution *could* solve the
> IDP mixup attack as well.
>
> Hans.
>
> --

---

From: George Fletcher <[email-masked]>
Date: Tue, 15 Mar 2016 11:09:45 -0400

I worry about two directions I see in this thread...

1. Client's accessing resources dynamically so that discovery is 
required to know the correct AS, etc. This is pretty much the classic 
use case for UMA and I'd rather not re-invent the wheel.

2. Creating a tight coupling between RS and AS such that RS endpoint 
changes must be continually communicated to the AS. If an RS supports 
multiple AS's then the RS has to deal with "guaranteed" delivery. The AS 
needs an endpoint to receive such communications. If not dynamic via 
APIs, then deployment of the new RS is bound by the associated AS's 
getting and deploying the new endpoints. Can both endpoints of the RS be 
supported within the AS for some period of time, etc. This is an 
operation nightmare and almost assuredly going to go wrong in production.

Maybe an OAuth2 "audience binding" spec is what's needed for those 
deployments that require this. I believe that is what John Bradley is 
suggesting.

Thanks,
George

On 3/14/16 7:29 PM, Hans Zandbelt wrote:
> in; the hard part is to give names and descriptions to these concepts 
> so that they cover all use cases and can be applied unambiguously
>
> Hans.
>

---

From: John Bradley <[email-masked]>
Date: Tue, 15 Mar 2016 12:37:06 -0300

Yes,  I think bearer tokens with no audience are a bad idea.

The AS needs to infer an audience from the scopes snd/or have the client specify the desired audience.

If the AT has a audience or audiences then as long as the endpoint URI are provided as meta-data with the token, the client can determine if it is sending the token to the correct place.

I think Phil would prefer the server rather than the client do the check, but the client always needs to take some responsibility to not leak tokens giving them to the wrong RS or the code to the wrong token endpoint is leaking.

I imagine that claims based access tokens are going to become more popular and the static relationship between one RS and one AS will not be the majority of deployments over time. 

In any case where the client is configured up front to know the RS and the AS it seems like that would not require Phil’s Solution, but that is the only case supported by that discovery.
  
If the client itself is bad there is not much you can do to stop it from passing on the AT in way way it wants.  That however is a different problem and needs claimed URI or attestations to prevent client spoofing.
William and I are working on that in the mobile best practices draft.

John B.

> On Mar 15, 2016, at 12:09 PM, George Fletcher <[email-masked]> wrote:
> 
> 1. Client's accessing resources dynamically so that discovery is required to know the correct AS, etc. This is pretty much the classic use case for UMA and I'd rather not re-invent the wheel.
> 
> 2. Creating a tight coupling between RS and AS such that RS endpoint changes must be continually communicated to the AS. If an RS supports multiple AS's then the RS has to deal with "guaranteed" delivery. The AS needs an endpoint to receive such communications. If not dynamic via APIs, then deployment of the new RS is bound by the associated AS's getting and deploying the new endpoints. Can both endpoints of the RS be supported within the AS for some period of time, etc. This is an operation nightmare and almost assuredly going to go wrong in production.
> 
> Maybe an OAuth2 "audience binding" spec is what's needed for those deployments that require this. I believe that is what John Bradley is suggesting.
> 
> Thanks,
> George
> 
>> +1, I've found the very same in OAuth deployments that I was involved in; the hard part is to give names and descriptions to these concepts so that they cover all use cases and can be applied unambiguously 
>> 
>> Hans. 
>> 
>>>> On Mar 14, 2016, at 6:26 PM, John Bradley <[email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked]> <mailto:[email-masked]>> wrote: 
>>>> 
>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]> 
>>>>> <mailto:[email-masked]> <mailto:[email-masked]>> wrote: 
>>>>> 
>>>>> Inline 
>>>>> 
>>>>> Phil 
>>>>> 
>>>>> On Mar 14, 2016, at 14:13, John Bradley <[email-masked] <mailto:[email-masked]> 
>>>>> <mailto:[email-masked]> <mailto:[email-masked]>> wrote: 
>>>>> 
>>>>> http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt <http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt> 
>>>>>> 
>>>>> client chooses evil.com <http://evil.com/> <http://evil.com/> the cert can be valid and 
>>>>> res.example.com <http://res.example.com/> <http://res.example.com/>? 
>>>>>> 
>>>>>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt <[email-masked] <mailto:[email-masked]> 
>>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>> wrote: 
>>>>>>> 
>>>>>>> www.independentid.com <http://www.independentid.com/> <http://www.independentid.com/> <http://www.independentid.com/> 
>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> 
>>>>>>>> wrote: 
>>>>>>>> 
>>>>>>>> *From:*OAuth [mailto:[email-masked] <mailto:[email-masked]>]*On Behalf Of*John Bradley 
>>>>>>>> *To:*Phil Hunt <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> 
>>>>>>>> *Cc:*oauth <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> 
>>>>>>>>     On Mar 13, 2016, at 8:12 PM, Phil Hunt <[email-masked] <mailto:[email-masked]> 
>>>>>>>>     <mailto:[email-masked]> <mailto:[email-masked]>> wrote: 
>>>>>>>>     www.independentid.com <http://www.independentid.com/> <http://www.independentid.com/> <http://www.independentid.com/> 
>>>>>>>>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>         Begin forwarded message: 
>>>>>>>>         <mailto:[email-masked]> <mailto:[email-masked]> 
>>>>>>>>         *To:*"Phil Hunt" <[email-masked] <mailto:[email-masked]> 
>>>>>>>>         <mailto:[email-masked]> <mailto:[email-masked]>>, "Anthony Nadalin" 
>>>>>>>>         <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>>, 
>>>>>>>>         "Tony Nadalin" <[email-masked] <mailto:[email-masked]> 
>>>>>>>>         <mailto:[email-masked]> <mailto:[email-masked]>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>         https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt <https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt>
>>>>>>>>         Status: 
>>>>>>>>         https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ <https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/> 
>>>>>>>>         Htmlized: 
>>>>>>>>         https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 <https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>         Abstract: 
>>>>>>>>         attools.ietf.org <http://tools.ietf.org/> <http://tools.ietf.org/>. 
>>>>>>>> 
>>>>>>>>         The IETF Secretariat 
>>>>>>>> 
>>>>>>>>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> 
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>

---

From: Justin Richer <[email-masked]>
Date: Tue, 15 Mar 2016 11:29:31 -0400

So long as you’re storing the client_id and client_secret in your LDAP and not putting a username and password (that normally represents a person) into the software, you’re fine. That’s just a case of externalizing the client registration to the LDAP system — it’s still registered. 

Otherwise, if you’re putting a person’s information into the client there, you’re doing impersonation. That’s bad, don’t do that.

 — Justin

> On Mar 15, 2016, at 9:17 AM, Sergey Beryozkin <[email-masked]> wrote:
> 
> Hi Justin
> 
> Piece of software, something that needs to run without the human user being involved
> I guess I'm still OK here, as I said, it is a piece of software which runs without a user. Like in all web services (SOAP or plain HTTP client invocations) where the client sets some credentials and accesses some data in the remote service.
> 
> So, as far as my original question is concerned, given that a client piece of software (no human user is involved) uses some credentials to get the token with client_credentials, would it be OK to avoid the explicit 'Client' registration with AS, given that the authentication system employed by AS is already aware of such credentials, I guess yes.
> 
> Thanks, Sergey
>> 
>>  -- Justin
>>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 15 Mar 2016 08:40:52 -0700

Regarding 2.

The bound config spec makes no such requirement of knowing the and its path structure.  

If you feel that you have other security measures and that clients will always have the proper AS, then you can wildcard the whole resource parameter.  It still might be advisable to at least check that your clients are using a URL of the form https://*.aol.com/* or https://*.partner.com/*.

The benefit is that at least you know the client is intending to wield the token somewhere in your domain or your partner’s domain. as opposed to something like news.aol.myevildomain.com.

The difference here is that security remains the responsibility of the service provider in all cases.  The check is up to the service provider rather than the client. This means that we don’t have to rely on trusting that the client developer bothered to check the configuration (as in other proposals that modify OAuth protocol itself) — we know well they won’t because they won’t have to. The server side validation is trivial.  I’m not sure how much easier this can be.  

Phil

@independentid

> On Mar 15, 2016, at 8:09 AM, George Fletcher <[email-masked]> wrote:
>

---

From: Brian Campbell <[email-masked]>
Date: Tue, 15 Mar 2016 09:46:21 -0600

If the client specifies the desired audience(s)/resource(s), is that
metadata to the client needed? The AS can audience restrict the token as
needed or respond with an error if it can't or wont issue a token for the
resource the client asked for.

On Tue, Mar 15, 2016 at 9:37 AM, John Bradley <[email-masked]> wrote:

> If the AT has a audience or audiences then as long as the endpoint URI are
> provided as meta-data with the token, the client can determine if it is
> sending the token to the correct place.
>
> I think Phil would prefer the server rather than the client do the check,
> but the client always needs to take some responsibility to not leak tokens
> giving them to the wrong RS or the code to the wrong token endpoint is
> leaking.
>
> I imagine that claims based access tokens are going to become more popular
> and the static relationship between one RS and one AS will not be the
> majority of deployments over time.
>
> In any case where the client is configured up front to know the RS and the
> AS it seems like that would not require Phil’s Solution, but that is the
> only case supported by that discovery.
>
> If the client itself is bad there is not much you can do to stop it from
> passing on the AT in way way it wants.  That however is a different problem
> and needs claimed URI or attestations to prevent client spoofing.
> 1. Client's accessing resources dynamically so that discovery is required
> to know the correct AS, etc. This is pretty much the classic use case for
> UMA and I'd rather not re-invent the wheel.
>
> needs an endpoint to receive such communications. If not dynamic via APIs,
> then deployment of the new RS is bound by the associated AS's getting and
> deploying the new endpoints. Can both endpoints of the RS be supported
> within the AS for some period of time, etc. This is an operation nightmare
> and almost assuredly going to go wrong in production.
>
> +1, I've found the very same in OAuth deployments that I was involved in;
> the hard part is to give names and descriptions to these concepts so that
> they cover all use cases and can be applied unambiguously
>
> Hans.
>
> On Mar 14, 2016, at 6:26 PM, John Bradley <[email-masked]
> <mailto:[email-masked]> <[email-masked]>> wrote:
>
> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) <[email-masked]
> <mailto:[email-masked]> <[email-masked]>> wrote:
>
> Inline
>
> Phil
>
> <mailto:[email-masked]> <[email-masked]>> wrote:
>
> On Mar 14, 2016, at 3:56 PM, Phil Hunt <[email-masked]
> <mailto:[email-masked]> <[email-masked]>> wrote:
>
> <http://www.independentid.com/>
> [email-masked] <mailto:[email-masked]> <[email-masked]>
>
>
>
>
>
> <[email-masked] <mailto:[email-masked]>
> <[email-masked]>>
> wrote:
>
> *From:*OAuth [mailto:[email-masked] <[email-masked]>]*On
> Behalf Of*John Bradley
> *To:*Phil Hunt <[email-masked] <mailto:[email-masked]>
> <[email-masked]>>
> *Cc:*oauth <[email-masked] <mailto:[email-masked]> <[email-masked]>>
>     On Mar 13, 2016, at 8:12 PM, Phil Hunt <[email-masked]
>     <mailto:[email-masked]> <[email-masked]>> wrote:
> <http://www.independentid.com/>
> <[email-masked]>
>         <mailto:[email-masked]> <[email-masked]>
>         <mailto:[email-masked]> <[email-masked]>>, "Anthony
> Nadalin"
>         <[email-masked] <mailto:[email-masked]>
> <[email-masked]>>,
>         <mailto:[email-masked]> <[email-masked]>>
>
>
>     [email-masked] <mailto:[email-masked]> <[email-masked]>
> [email-masked] <mailto:[email-masked]> <[email-masked]>

---

From: George Fletcher <[email-masked]>
Date: Tue, 15 Mar 2016 11:54:47 -0400

I'm not against binding audiences to a token. (Note that in many 
deployments today, a single access token can be used at many endpoints 
representing different services. It's not uncommon for a client to 
request a token to access the mail endpoints, messaging endpoints, 
contacts endpoints, etc. This requires the ability to associate multiple 
audiences to a single token.)

The issue is whether it's possible to represent the RS with an abstract 
audience identifier (e.g. URN?) rather than a specific endpoint. Taking 
this approach provides a level of indirection that is much easier to 
configure. The AS likely knows (or can be configured) that it supports a 
Instant-Messaging RS. The client can then use some other mechanism to 
determine the exact endpoint of that abstract audience identifier. This 
keeps the relationships defined without the tight-coupling of 
registering endpoints (even with wild cards).

Now if the direction is to move to a token can only have one audience, 
to me that isn't OAuth2. It's a perfectly fine model, but we should be 
addressing that as the next gen spec, not trying to layer it on the 
existing one that has different deployment semantics.

Thanks,
George

On 3/15/16 11:37 AM, John Bradley wrote:
> If the AT has a audience or audiences then as long as the endpoint URI 
> are provided as meta-data with the token, the client can determine if 
> it is sending the token to the correct place.
>
> I think Phil would prefer the server rather than the client do the 
> check, but the client always needs to take some responsibility to not 
> leak tokens giving them to the wrong RS or the code to the wrong token 
> endpoint is leaking.
>
> I imagine that claims based access tokens are going to become more 
> popular and the static relationship between one RS and one AS will not 
> be the majority of deployments over time.
>
> In any case where the client is configured up front to know the RS and 
> the AS it seems like that would not require Phil’s Solution, but that 
> is the only case supported by that discovery.
> If the client itself is bad there is not much you can do to stop it 
> from passing on the AT in way way it wants.  That however is a 
> different problem and needs claimed URI or attestations to prevent 
> client spoofing.
>> On Mar 15, 2016, at 12:09 PM, George Fletcher <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> multiple AS's then the RS has to deal with "guaranteed" delivery. The 
>> AS needs an endpoint to receive such communications. If not dynamic 
>> via APIs, then deployment of the new RS is bound by the associated 
>> AS's getting and deploying the new endpoints. Can both endpoints of 
>> the RS be supported within the AS for some period of time, etc. This 
>> is an operation nightmare and almost assuredly going to go wrong in 
>> production.
>>
>>> +1, I've found the very same in OAuth deployments that I was 
>>> involved in; the hard part is to give names and descriptions to 
>>> these concepts so that they cover all use cases and can be applied 
>>> unambiguously
>>>
>>> Hans.
>>>
>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>
>>>>>> Inline
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> client chooses evil.com <http://evil.com> <http://evil.com/> the 
>>>>>> cert can be valid and
>>>>>> res.example.com <http://res.example.com> <http://res.example.com/>?
>>>>>>>
>>>>>>> If you check out of band in discovery you really have no idea if 
>>>>>>> the
>>>>>>> client is checking.
>>>>>>
>>>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>>>
>>>>>>>>> If the API specific well known is not available the client can 
>>>>>>>>> try
>>>>>>>>> the default oauth-server one.
>>>>>>>>> That however was supposed to be dealt with as part of the 
>>>>>>>>> mixed up
>>>>>>>>> client set of mitigations.
>>>>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>>>>           This specification defines a mechanism for the 
>>>>>>>>> client of
>>>>>>>>>         an OAuth 2.0
>>>>>>>>> attools.ietf.org <http://attools.ietf.org> 
>>>>>>>>> <http://tools.ietf.org/>.
>>>>>>>>>
>>>>>>>>>         The IETF Secretariat
>>>>>>>>>

---

From: George Fletcher <[email-masked]>
Date: Tue, 15 Mar 2016 12:01:24 -0400

I understand the benefit of having the client specify where it wants to 
present the token. However, in general, the client knows which kind of 
resource it's going to connect to (even if it doesn't know the exact 
endpoint). For example, if the client speaks PortableContacts, then it 
can potentially discover any PortableContact RS and attempt to get 
authorization to access the endpoints, but the client can't connect to 
the mail RS because it's not coded to work with those endpoints.

Therefore, the client has an understanding of the protocol of the RS and 
can possibly discover related endpoints (what webfinger was really 
designed for) but it can't support some random new protocol. As I wrote 
in my response to John Bradley, I believe audience binding should use an 
abstract identifier not an API endpoint.

Thanks,
George

On 3/15/16 11:40 AM, Phil Hunt wrote:
> If you feel that you have other security measures and that clients 
> will always have the proper AS, then you can wildcard the whole 
> resource parameter.  It still might be advisable to at least check 
> that your clients are using a URL of the form https://*.aol.com/* or 
> https://*.partner.com/*.
>
> The benefit is that at least you know the client is intending to wield 
> the token somewhere in your domain or your partner’s domain. as 
> opposed to something like news.aol.myevildomain.com 
> <http://news.aol.myevildomain.com>.
>
> The difference here is that security remains the responsibility of the 
> service provider in all cases.  The check is up to the service 
> provider rather than the client. This means that we don’t have to rely 
> on trusting that the client developer bothered to check the 
> configuration (as in other proposals that modify OAuth protocol 
> itself) — we know well they won’t because they won’t have to. The 
> server side validation is trivial.  I’m not sure how much easier this 
> can be.
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
>> On Mar 15, 2016, at 8:09 AM, George Fletcher <[email-masked] 

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

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 15 Mar 2016 16:34:15 +0000

> and its content is visible ?

Because you want to know whether it's been revoked before its expiration.
Introspection is the only way (unless AS and RS are colocated), as only the
AS knows.

> if some more external data are associated with it.

If the token is not valid (bad issuer, bad signature, expired; or if the
scopes are included: insufficient scopes), it saves you a request to the
introspection endpoint ;-)
Only if the token passes the first checks would you introspect it to see if
it's still active (not revoked) and possibly retrieve more data about it.

> share the decrypting key with AS.

I think that was the idea yes (didn't someone commented on the thread that
they deployed JWT tokens with shared secrets or symmetric keys?)

> secret/private key with AS.

As Justin mentioned in the other thread: introspection is useful
(required?) for checking the "liveness" of the token.

Side-note: given the size of a JWT compared to some "simpler", opaque
tokens (mere identifiers), and the fact introspection response are likely
to be cached for a few minutes by the RS, I wonder if using a JWT so you
can possibly avoid an introspection request outweights (sic!) the bloat of
a JWT sent repeatedly over the network (possibly a network with high
latency, low bandwidth, and sometimes paid based on exchanged volumes).
This is rhetoric actually: I side on the "small token that require
introspection" until someone comes with a compelling argument to go the
other way.

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Tue, 15 Mar 2016 09:42:22 -0700

Thanks George

I think we have to discuss cases where mitigstion is not needed such as oidc. 

My concern is to make the mitigation choice the AS's and not the client. 

Phil

> On Mar 15, 2016, at 09:01, George Fletcher <[email-masked]> wrote:
> 
> I understand the benefit of having the client specify where it wants to present the token. However, in general, the client knows which kind of resource it's going to connect to (even if it doesn't know the exact endpoint). For example, if the client speaks PortableContacts, then it can potentially discover any PortableContact RS and attempt to get authorization to access the endpoints, but the client can't connect to the mail RS because it's not coded to work with those endpoints.
> 
> Therefore, the client has an understanding of the protocol of the RS and can possibly discover related endpoints (what webfinger was really designed for) but it can't support some random new protocol. As I wrote in my response to John Bradley, I believe audience binding should use an abstract identifier not an API endpoint.
> 
> Thanks,
> George
>

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 15 Mar 2016 17:04:18 +0000

Pushing documents such as AS metadata because Connect uses them does not help anything but muddies the water, Metadata is not a solution to Mix-up and Metadata is not a solution to Discovery, both Discovery and Mix-up are problems we need and agreed to fix. So I totally agree that we should not be conflating metadata with Mix-up or Discovery. I’m not hearing overwhelming consensus on adopting the metadata, maybe that is just consensus amongst OpenID folks and yes there are a few vocal people.

Most RS and AS relationships are not static relationships, we are seeing tenants that are suppling their own AS infrastructure as well as seeing portable RS’s which gets us into some very dynamic situations.

From: OAuth [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Tuesday, March 15, 2016 8:00 AM
To: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

Discovery in general for OAuth isn't well understood. This conversation and others like it around the 'discovery' draft demonstrate that. But publishing AS metadata is something that is understood and already in wide use for Connect. The rough consensus (except for a very few but vocal dissenters) on this list over the last few weeks/months has been that draft-ietf-oauth-discovery should describing AS metadata and its location. It's been suggested that the title reflect that scope and I might even suggest that the document identifier be changed to avoid further confusion.
The IDP mixup is addressed by the AS identifying itself to the client in the authorization response (it has a few other things in it that arguably shouldn't be in or should be elsewhere but that's a different question). The Mix-Up Mitigation draft uses the issuer value to do that. Issuer becomes a logical name/identifier for an AS. And that can tie it to AS metadata or even discovery if/when that exists. But discovery or AS metadata isn't necessary there. Yes Tony, we'd all like to see a comprehensive solution but conflating different and unrelated things is only making matters worse (as I'm sure you are well aware).
A 'bad RS' phishing for legitimate access tokens is a different kind of endpoint confusion. Most deployments now have a static relationship defined between RS and AS so it's more of a potential problem in the future. Despite the concern voiced about it the potential (as far as I can tell anyway), draft-hunt-oauth-bound-config provides a very nice attack vector for such a 'bad RS' by pointing to an AS to obtain tokens it could misuse at legitimate RS(s). John has alluded to this.

There have been a number of incremental updates/extensions to OAuth 2.0 and there look to be more coming.  Concerns have been expressed over the number of documents and implements knowing what to use when. I don't think the answer is to try and jam unrelated new stuff into new docs to keep the number of docs low is a good idea though. I'd much prefer to have concise and cohesive documents. The larger issue of confusion around too many documents should be addressed at a higher level. For example, something like an implementation guide or even something like an OAuth 2.1 that describes the available extensions and when/why one would use them.

On Mon, Mar 14, 2016 at 4:29 PM, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:
I would really like to see a comprehensive solution not this piece work, so we know what we are solving and what we are not.

-----Original Message-----
From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Hans Zandbelt
Sent: Monday, March 14, 2016 3:26 PM
To: Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>>; John Bradley <[email-masked]<mailto:[email-masked]>>
Cc: oauth <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

> On Mar 14, 2016, at 14:13, John Bradley <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

Hans.

--
Hans Zandbelt              | Sr. Technical Architect
[email-masked]<mailto:[email-masked]> | Ping Identity

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

---

From: George Fletcher <[email-masked]>
Date: Tue, 15 Mar 2016 13:17:35 -0400

I'm less concerned about making the mitigation choice the AS's because 
to prevent the leaking of tokens you need a "good" client in both cases. 
An evil client can still request a token correctly and then send it to 
an evil RS.

If a client that "does the right thing" is required, then I don't see a 
huge advantage to either the client or the AS for performing this check.

On 3/15/16 12:42 PM, Phil Hunt (IDM) wrote:
> On Mar 15, 2016, at 09:01, George Fletcher <[email-masked] 
>> I understand the benefit of having the client specify where it wants 
>> to present the token. However, in general, the client knows which 
>> kind of resource it's going to connect to (even if it doesn't know 
>> the exact endpoint). For example, if the client speaks 
>> PortableContacts, then it can potentially discover any 
>> PortableContact RS and attempt to get authorization to access the 
>> endpoints, but the client can't connect to the mail RS because it's 
>> not coded to work with those endpoints.
>>
>> Therefore, the client has an understanding of the protocol of the RS 
>> and can possibly discover related endpoints (what webfinger was 
>> really designed for) but it can't support some random new protocol. 
>> As I wrote in my response to John Bradley, I believe audience binding 
>> should use an abstract identifier not an API endpoint.
>>
>> Thanks,
>> George
>>
>>> The benefit is that at least you know the client is intending to 
>>> wield the token somewhere in your domain or your partner’s domain. 
>>> as opposed to something like news.aol.myevildomain.com 
>>> The difference here is that security remains the responsibility of 
>>> the service provider in all cases.  The check is up to the service 
>>> provider rather than the client. This means that we don’t have to 
>>> rely on trusting that the client developer bothered to check the 
>>> server side validation is trivial.  I’m not sure how much easier 
>>> this can be.
>>>
>>> Phil
>>>
>>> @independentid
>>>> required to know the correct AS, etc. This is pretty much the 
>>>> classic use case for UMA and I'd rather not re-invent the wheel.
>>>>
>>>> 2. Creating a tight coupling between RS and AS such that RS 
>>>> endpoint changes must be continually communicated to the AS. If an 
>>>> RS supports multiple AS's then the RS has to deal with "guaranteed" 
>>>> delivery. The AS needs an endpoint to receive such communications. 
>>>> If not dynamic via APIs, then deployment of the new RS is bound by 
>>>> the associated AS's getting and deploying the new endpoints. Can 
>>>> both endpoints of the RS be supported within the AS for some period 
>>>> of time, etc. This is an operation nightmare and almost assuredly 
>>>> going to go wrong in production.
>>>>
>>>> deployments that require this. I believe that is what John Bradley 
>>>> is suggesting.
>>>>
>>>> Thanks,
>>>> George
>>>>
>>>>>>>> How does this address the issue of whether the client is 
>>>>>>>> talking to
>>>>>>>> the wrong endpoint?
>>>>>>>>>
>>>>>>>>>  In your solution the client would need to make a discovery 
>>>>>>>>> request
>>>>>>>>> for each endpoint.
>>>>>>>> Sure. Otherwise how would it know if there is one AS or a pool 
>>>>>>>> of AS
>>>>>>>> servers assigned to each instance?
>>>>>>>> client chooses evil.com <http://evil.com> <http://evil.com/> 
>>>>>>>> the cert can be valid and
>>>>>>>>> I don’t see checking when refreshing a token as something that 
>>>>>>>>> is a
>>>>>>>>> huge burden.
>>>>>>>>
>>>>>>>>> If you check out of band in discovery you really have no idea 
>>>>>>>>> if the
>>>>>>>>> client is checking.
>>>>>>>>
>>>>>>>>>>> Discovery is the wrong place to try and provide security 
>>>>>>>>>>> against
>>>>>>>>>>> man in the middle attacks on the RS.
>>>>>>>>>>> If the API specific well known is not available the client 
>>>>>>>>>>> can try
>>>>>>>>>>>           protected resource service to obtain the 
>>>>>>>>>>> configuration
>>>>>>>>>>>         details of an
>>>>>>>>>>>         Please note that it may take a couple of minutes 
>>>>>>>>>>> from the
>>>>>>>>>>>         time of submission

---

From: Justin Richer <[email-masked]>
Date: Tue, 15 Mar 2016 13:23:15 -0400

+1 to all of this.

Our reasoning for the JWT+introspection was to allow for an RS to take in tokens from multiple AS, by looking up the issuer in the JWT itself.

 — Justin

> On Mar 15, 2016, at 12:34 PM, Thomas Broyer <[email-masked]> wrote:
> 
> 
> 
> On Tue, Mar 15, 2016 at 2:02 PM Sergey Beryozkin <[email-masked] <mailto:[email-masked]>> wrote:
> Hi
> 
> Because you want to know whether it's been revoked before its expiration. Introspection is the only way (unless AS and RS are colocated), as only the AS knows.
>  
> If the token is not valid (bad issuer, bad signature, expired; or if the scopes are included: insufficient scopes), it saves you a request to the introspection endpoint ;-)
> Only if the token passes the first checks would you introspect it to see if it's still active (not revoked) and possibly retrieve more data about it.
>  
> I think that was the idea yes (didn't someone commented on the thread that they deployed JWT tokens with shared secrets or symmetric keys?)
>  
> As Justin mentioned in the other thread: introspection is useful (required?) for checking the "liveness" of the token.
> 
> Side-note: given the size of a JWT compared to some "simpler", opaque tokens (mere identifiers), and the fact introspection response are likely to be cached for a few minutes by the RS, I wonder if using a JWT so you can possibly avoid an introspection request outweights (sic!) the bloat of a JWT sent repeatedly over the network (possibly a network with high latency, low bandwidth, and sometimes paid based on exchanged volumes).
> This is rhetoric actually: I side on the "small token that require introspection" until someone comes with a compelling argument to go the other way.

---

From: George Fletcher <[email-masked]>
Date: Tue, 15 Mar 2016 13:37:34 -0400

While I understand the desire for small tokens, we chose JWT as a 
wrapper for the external AS opaque token so that we would have a generic 
implementation that can be expanded to additional partners without 
affecting our implementation.

You could assign each AS in a multiple AS closed environment a unique 
value and then pre/post-fix it to the opaque token so that the RS could 
know where to introspect it. This is still a structured token, just a 
binary representation to save size. There are probably better binary 
ways to do this:)

Thanks,
George

On 3/15/16 12:34 PM, Thomas Broyer wrote:
>     servers, but
>     purpose
>     sequences
> Because you want to know whether it's been revoked before its 
> expiration. Introspection is the only way (unless AS and RS are 
> colocated), as only the AS knows.
>
>     visible in
> If the token is not valid (bad issuer, bad signature, expired; or if 
> the scopes are included: insufficient scopes), it saves you a request 
> to the introspection endpoint ;-)
> Only if the token passes the first checks would you introspect it to 
> see if it's still active (not revoked) and possibly retrieve more data 
> about it.
>
>     introspection
> I think that was the idea yes (didn't someone commented on the thread 
> that they deployed JWT tokens with shared secrets or symmetric keys?)
>
>     or it
> tokens (mere identifiers), and the fact introspection response are 
> likely to be cached for a few minutes by the RS, I wonder if using a 
> JWT so you can possibly avoid an introspection request outweights 
> (sic!) the bloat of a JWT sent repeatedly over the network (possibly a 
> network with high latency, low bandwidth, and sometimes paid based on 
> exchanged volumes).
> introspection" until someone comes with a compelling argument to go 
> the other way.
>
>

---

From: John Bradley <[email-masked]>
Date: Tue, 15 Mar 2016 14:37:41 -0300

If the client specifies the resource it wants the token for, then the meta-data would not be required unless the resources the token is good at are different from the request.  
Lat is the same logic as scopes.

For backwards compatibility if the client is happy with the default resources based on scopes then I think it is a good idea to tell the client what the resources are in the response.

I suspect that it is simpler with less optionality and always return the resources, even if they are not required.

John B.

> On Mar 15, 2016, at 12:46 PM, Brian Campbell <[email-masked]> wrote:
> 
> If the client specifies the desired audience(s)/resource(s), is that metadata to the client needed? The AS can audience restrict the token as needed or respond with an error if it can't or wont issue a token for the resource the client asked for. 
> 
> On Tue, Mar 15, 2016 at 9:37 AM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>> On Mar 15, 2016, at 12:09 PM, George Fletcher <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>>>> client chooses evil.com <http://evil.com/> <http://evil.com/> <http://evil.com/> the cert can be valid and 
>>>>>> res.example.com <http://res.example.com/> <http://res.example.com/> <http://res.example.com/>? 
>>>>>>> 
>>>>>>>>> athttp://openid.net/certification/ <>(see the “OP Config” column in 
>>>>>>>>>         *From:[email-masked] <mailto:[email-masked]> 
>>>>>>>>>         attools.ietf.org <http://attools.ietf.org/> <http://tools.ietf.org/> <http://tools.ietf.org/>. 
>>>>>>>>> 
>>>>>>>>>         The IETF Secretariat 
>>>>>>>>>

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 15 Mar 2016 17:39:46 +0000

Hi Thomas

Yes, we currently only support 'small' tokens with the introspection and 
the local caching (though not time but size based which is not ideal if 
we talk about the revocations, though in a high end servers that should 
still invalidate the cache fast enough).
But that does not support multiple AS (I haven't had such a requirement 
but it is an important thing to know about), so a 'light-weight' hybrid 
JWS as it was suggested by several experts seems like a neat compromise.

Sergey
On 15/03/16 16:34, Thomas Broyer wrote:
> Only if the token passes the first checks would you introspect it to see
> if it's still active (not revoked) and possibly retrieve more data about it.
>
> likely to be cached for a few minutes by the RS, I wonder if using a JWT
> so you can possibly avoid an introspection request outweights (sic!) the
> bloat of a JWT sent repeatedly over the network (possibly a network with
> high latency, low bandwidth, and sometimes paid based on exchanged volumes).

-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

---

From: John Bradley <[email-masked]>
Date: Tue, 15 Mar 2016 14:43:07 -0300

I am trying to support multiple audiences in a token.   We are agreed on that.

The problem with having a abstract audience is how a client would verify the RS URI is correct.  

If we wanted abstract Audience could be a HTTPS URI with only host component,  or a Fully qualified URI that can be retrieved by the client to get the concrete resource endpoints.  
That however starts down the road to resource discovery.

John B.
> On Mar 15, 2016, at 12:54 PM, George Fletcher <[email-masked]> wrote:
> 
> I'm not against binding audiences to a token. (Note that in many deployments today, a single access token can be used at many endpoints representing different services. It's not uncommon for a client to request a token to access the mail endpoints, messaging endpoints, contacts endpoints, etc. This requires the ability to associate multiple audiences to a single token.)
> 
> The issue is whether it's possible to represent the RS with an abstract audience identifier (e.g. URN?) rather than a specific endpoint. Taking this approach provides a level of indirection that is much easier to configure. The AS likely knows (or can be configured) that it supports a Instant-Messaging RS. The client can then use some other mechanism to determine the exact endpoint of that abstract audience identifier. This keeps the relationships defined without the tight-coupling of registering endpoints (even with wild cards).
> 
> Now if the direction is to move to a token can only have one audience, to me that isn't OAuth2. It's a perfectly fine model, but we should be addressing that as the next gen spec, not trying to layer it on the existing one that has different deployment semantics.
> 
> Thanks,
> George
> 
>>>>>> On Mar 14, 2016, at 6:26 PM, John Bradley < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> 
>>>>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> 
>>>>>>> On Mar 14, 2016, at 14:13, John Bradley < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> 
>>>>>>> client chooses evil.com <http://evil.com/>  <http://evil.com/><http://evil.com/> <http://evil.com/> the cert can be valid and 
>>>>>>>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> 
>>>>>>>>>> athttp://openid.net/certification/ <athttp://openid.net/certification/>(see the “OP Config” column in 
>>>>>>>>>> *To:*Phil Hunt < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> 
>>>>>>>>>>         *To:*"Phil Hunt" < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> 
>>>>>>>>>>         "Tony Nadalin" < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>

---

From: Brian Campbell <[email-masked]>
Date: Tue, 15 Mar 2016 11:44:39 -0600

I was thinking it'd be simpler to error, if the requested resource(s)
weren't okay. That puts the burden of checking in the AS. And doesn't add
anything to the token or authorization response. I see the potential
similarity to scope but not sure it's worth it.

On Tue, Mar 15, 2016 at 11:37 AM, John Bradley <[email-masked]> wrote:

> If the client specifies the resource it wants the token for, then the
> meta-data would not be required unless the resources the token is good at
> are different from the request.
> For backwards compatibility if the client is happy with the default
> resources based on scopes then I think it is a good idea to tell the client
> what the resources are in the response.
>
> I suspect that it is simpler with less optionality and always return the
> resources, even if they are not required.
>
> John B.
>
>> are provided as meta-data with the token, the client can determine if it is
>> popular and the static relationship between one RS and one AS will not be
>> the majority of deployments over time.
>>
>> the AS it seems like that would not require Phil’s Solution, but that is
>> the only case supported by that discovery.
>>

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 15 Mar 2016 17:41:54 +0000

On Tue, Mar 15, 2016 at 6:23 PM Justin Richer <[email-masked]> wrote:

> +1 to all of this.
>
> Our reasoning for the JWT+introspection was to allow for an RS to take in
> tokens from multiple AS, by looking up the issuer in the JWT itself.
>

But then, as I said, you need the AS to "cooperate" by making their ATs
JWTs; only for one RS that want to also accept ATs from other (concurrent?)
ASs. They could make everyone pay the price with bloated tokens, or start
treating some RSs different from others (at registration time, say you want
JWTs), or add extensions to the authorization endpoint or token endpoint so
clients can ask for JWT tokens.

Overall, I think my proposal to exchange an AS token for a RS-specific
token at an AS-specific endpoint at the RS (see mail in the other thread
from last week; that phrasing here is “fun” but not really legible ;-) )
would have the best of both worlds.
At the RS, linking the issued token with the received token from the AS
allows the RS to introspect the original token from time to time to check
for revocation (possibly in addition to its own revocation mechanism for
its own tokens).
Downside is that clients now have to do the token exchange and keep track
of both tokens.

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 15 Mar 2016 17:51:46 +0000

Hi Justin

AFAIK many Java JAAS systems, etc have things like "username", 
"password" set in various properties files, etc, and often these are 
really "client_id", "client_secret" in that these are not meant to 
support  a direct authentication between some command line client and 
this server.

I understand that if say I had a user working with some server, the user 
has authenticated, then the server does some outbound call on behalf of 
this user, then it is the impersonation, and I'd plan to use client 
credentials here but rather user a code flow. STS for the REST of us 
seems to be to support different cases...

Many Thanks
Sergey

-- 
Sergey Beryozkin

Talend Community Coders

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 15 Mar 2016 17:52:47 +0000

Sorry,
> support  a direct authentication between some command line client and
Was actually trying to say above "are meant to"
>> So long as you’re storing the client_id and client_secret in your LDAP
>> and not putting a username and password (that normally represents a
>> person) into the software, you’re fine. That’s just a case of
>> externalizing the client registration to the LDAP system — it’s still
>> registered.
>>
>> Otherwise, if you’re putting a person’s information into the client
>> there, you’re doing impersonation. That’s bad, don’t do that.
>>
>>   — Justin
>>
>>> runs without a user. Like in all web services (SOAP or plain HTTP
>>> client invocations) where the client sets some credentials and
>>> accesses some data in the remote service.
>>>
>>> piece of software (no human user is involved) uses some credentials
>>> to get the token with client_credentials, would it be OK to avoid the

-- 
Sergey Beryozkin

Talend Community Coders

---

From: John Bradley <[email-masked]>
Date: Tue, 15 Mar 2016 14:56:47 -0300

I think it is a AS policy decision if it should error or take the requested resource and issue a token audianced for that resource.

I guess the question is how to transition from now to a future state.   If you cannot upgrade all the clients at once.

A processing rule on the AS that allowed some clients to not send the requested resource , but would error out for other upgraded clients  with a "resource not allowed” oauth error would work and not require the return of the resources.  

If you return the resources and let the client error if it is trying to send to the wrong endpoint that make upgrading easier, but gives less control to the AS.

I could live with it ether way.

The advantage of always sending it in the token request is that it allows the AS to do the mapping from a resource URI to one or more abstract audience for the token.

That might help address George’s concern.

John B.

> On Mar 15, 2016, at 2:44 PM, Brian Campbell <[email-masked]> wrote:
> 
> I was thinking it'd be simpler to error, if the requested resource(s) weren't okay. That puts the burden of checking in the AS. And doesn't add anything to the token or authorization response. I see the potential similarity to scope but not sure it's worth it.   
> 
> On Tue, Mar 15, 2016 at 11:37 AM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>> On Mar 15, 2016, at 12:46 PM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: George Fletcher <[email-masked]>
Date: Tue, 15 Mar 2016 13:57:49 -0400

Yes, I agree the level of indirection starts us down the road to 
discovery... but if we want the audience binding it's a road I feel we 
have to traverse. The other option creates too tight a coupling in my mind.

On 3/15/16 1:43 PM, John Bradley wrote:
> If we wanted abstract Audience could be a HTTPS URI with only host 
> component,  or a Fully qualified URI that can be retrieved by the 
> client to get the concrete resource endpoints.
>> On Mar 15, 2016, at 12:54 PM, George Fletcher <[email-masked] 
>> deployments today, a single access token can be used at many 
>> endpoints representing different services. It's not uncommon for a 
>> client to request a token to access the mail endpoints, messaging 
>> endpoints, contacts endpoints, etc. This requires the ability to 
>> associate multiple audiences to a single token.)
>>
>> The issue is whether it's possible to represent the RS with an 
>> abstract audience identifier (e.g. URN?) rather than a specific 
>> endpoint. Taking this approach provides a level of indirection that 
>> is much easier to configure. The AS likely knows (or can be 
>> configured) that it supports a Instant-Messaging RS. The client can 
>> then use some other mechanism to determine the exact endpoint of that 
>> abstract audience identifier. This keeps the relationships defined 
>> without the tight-coupling of registering endpoints (even with wild 
>> cards).
>>
>> Now if the direction is to move to a token can only have one 
>> audience, to me that isn't OAuth2. It's a perfectly fine model, but 
>> we should be addressing that as the next gen spec, not trying to 
>> layer it on the existing one that has different deployment semantics.
>>
>> Thanks,
>> George
>>
>>> If the AT has a audience or audiences then as long as the endpoint 
>>> URI are provided as meta-data with the token, the client can 
>>> determine if it is sending the token to the correct place.
>>>
>>> check, but the client always needs to take some responsibility to 
>>> not leak tokens giving them to the wrong RS or the code to the wrong 
>>> token endpoint is leaking.
>>>
>>> popular and the static relationship between one RS and one AS will 
>>> not be the majority of deployments over time.
>>>
>>> In any case where the client is configured up front to know the RS 
>>> and the AS it seems like that would not require Phil’s Solution, but 
>>> that is the only case supported by that discovery.
>>>>>>>>>>> attools.ietf.org <http://attools.ietf.org/>

---

From: George Fletcher <[email-masked]>
Date: Tue, 15 Mar 2016 14:14:41 -0400

I think Justin provided a good break down of the different aspects a 
client wants to specify about the requested token. (my paraphrase)
   1. what RS's the token will be used at
   2. authorization privilege requests
   3. token-timing adjustments

I'm not sure passing the full endpoint to the AS will help with my 
concerns... The AS could potentially do a webfinger on the resource URI 
and determine if it's an RS that it supports... though that requires all 
RS's to support webfinger. What I really want to avoid is the AS having 
this list of URIs to RS that is almost assuredly to get out of sync.

On 3/15/16 1:56 PM, John Bradley wrote:
> I think it is a AS policy decision if it should error or take the 
> requested resource and issue a token audianced for that resource.
Actually, the error cases are interesting. What if the passed in 
resource/audience doesn't actually match a requested scope? Or some 
match and some don't? Is it better to send back a token with less 
capability? or error the entire request?
>
> I guess the question is how to transition from now to a future state. 
>   If you cannot upgrade all the clients at once.
>
> A processing rule on the AS that allowed some clients to not send the 
> requested resource , but would error out for other upgraded clients 
>  with a "resource not allowed” oauth error would work and not require 
> the return of the resources.
>
> If you return the resources and let the client error if it is trying 
> to send to the wrong endpoint that make upgrading easier, but gives 
> less control to the AS.
>
> The advantage of always sending it in the token request is that it 
> allows the AS to do the mapping from a resource URI to one or more 
> abstract audience for the token.
I thought Justin provided a good break down of the different aspects a 
client wants to specify about the requested token. (my paraphrase)
   1. what RS's the token will be used at
   2. authorization privilege requests
   3. token-timing adjustments

The question is how does a client internally reference a resource 
server? If it's a fixed RS endpoint, then it sort of doesn't matter, the 
client isn't going to send the token to the wrong endpoint anyway and it 
can easily reference the audience by an abstract URI.

If the client can dynamically find new RS's to interact with. How does 
that happen? Does the client get handed an endpoint to use? or does it 
do some sort of discovery to determine the endpoint? I suppose both are 
possible.

Could we prescribe that the realm value of RFC 6750 error response be 
effectively a resource-service-id (like issuer for the AS). The client 
would then need to do discovery on that value to find the valid 
endpoints of the RS. This could be done once and the resource-service-id 
could be used as the "abstract" RS identifier. This requires no more 
discovery than adding an AS to the client.
> That might help address George’s concern.
I'm not sure passing the full endpoint to the AS will help with my 
concerns... The AS could potentially do a webfinger on the resource URI 
and determine if it's an RS that it supports... though that requires all 
RS's to support webfinger. What I really want to avoid is the AS having 
this map of URIs to RS that is almost assuredly to get out of sync.
>
> John B.
>
>
>> On Mar 15, 2016, at 2:44 PM, Brian Campbell 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> weren't okay. That puts the burden of checking in the AS. And doesn't 
>> add anything to the token or authorization response. I see the 
>> potential similarity to scope but not sure it's worth it.
>>
>>     If the client specifies the resource it wants the token for, then
>>     the meta-data would not be required unless the resources the
>>     token is good at are different from the request.
>>     For backwards compatibility if the client is happy with the
>>     default resources based on scopes then I think it is a good idea
>>     to tell the client what the resources are in the response.
>>
>>     I suspect that it is simpler with less optionality and always
>>     return the resources, even if they are not required.
>>
>>     John B.
>>
>>>     On Mar 15, 2016, at 12:46 PM, Brian Campbell
>>>     <[email-masked] <mailto:[email-masked]>>
>>>     wrote:
>>>
>>>     If the client specifies the desired audience(s)/resource(s), is
>>>     that metadata to the client needed? The AS can audience restrict
>>>     the token as needed or respond with an error if it can't or wont
>>>     issue a token for the resource the client asked for.
>>>
>>>         The AS needs to infer an audience from the scopes snd/or
>>>         have the client specify the desired audience.
>>>
>>>         If the AT has a audience or audiences then as long as the
>>>         endpoint URI are provided as meta-data with the token, the
>>>         client can determine if it is sending the token to the
>>>         correct place.
>>>
>>>         I think Phil would prefer the server rather than the client
>>>         do the check, but the client always needs to take some
>>>         responsibility to not leak tokens giving them to the wrong
>>>         RS or the code to the wrong token endpoint is leaking.
>>>
>>>         I imagine that claims based access tokens are going to
>>>         become more popular and the static relationship between one
>>>         RS and one AS will not be the majority of deployments over
>>>         time.
>>>
>>>         In any case where the client is configured up front to know
>>>         the RS and the AS it seems like that would not require
>>>         Phil’s Solution, but that is the only case supported by that
>>>         discovery.
>>>         If the client itself is bad there is not much you can do to
>>>         stop it from passing on the AT in way way it wants. That
>>>         however is a different problem and needs claimed URI or
>>>         attestations to prevent client spoofing.
>>>>         On Mar 15, 2016, at 12:09 PM, George Fletcher
>>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>         1. Client's accessing resources dynamically so that
>>>>         discovery is required to know the correct AS, etc. This is
>>>>         pretty much the classic use case for UMA and I'd rather not
>>>>         re-invent the wheel.
>>>>
>>>>         endpoint changes must be continually communicated to the
>>>>         AS. If an RS supports multiple AS's then the RS has to deal
>>>>         with "guaranteed" delivery. The AS needs an endpoint to
>>>>         receive such communications. If not dynamic via APIs, then
>>>>         deployment of the new RS is bound by the associated AS's
>>>>         getting and deploying the new endpoints. Can both endpoints
>>>>         of the RS be supported within the AS for some period of
>>>>         time, etc. This is an operation nightmare and almost
>>>>         assuredly going to go wrong in production.
>>>>
>>>>         Maybe an OAuth2 "audience binding" spec is what's needed
>>>>         for those deployments that require this. I believe that is
>>>>         what John Bradley is suggesting.
>>>>
>>>>         Thanks,
>>>>         George
>>>>
>>>>>         +1, I've found the very same in OAuth deployments that I
>>>>>         was involved in; the hard part is to give names and
>>>>>         descriptions to these concepts so that they cover all use
>>>>>         cases and can be applied unambiguously
>>>>>
>>>>>         Hans.
>>>>>
>>>>>>>         On Mar 14, 2016, at 6:26 PM, John Bradley
>>>>>>>         <[email-masked] <mailto:[email-masked]>
>>>>>>>>         On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM)
>>>>>>>>         <[email-masked] <mailto:[email-masked]>
>>>>>>>>         On Mar 14, 2016, at 14:13, John Bradley
>>>>>>>>         <[email-masked] <mailto:[email-masked]>
>>>>>>>>         How does this address the issue of whether the client
>>>>>>>>         is talking to
>>>>>>>>         the wrong endpoint?
>>>>>>>>>
>>>>>>>>>         There are also cases where a token might be good at
>>>>>>>>>         multiple RS
>>>>>>>>>         endpoints intentionally.
>>>>>>>>
>>>>>>>>>          In your solution the client would need to make a
>>>>>>>>>         discovery request
>>>>>>>>>         for each endpoint.
>>>>>>>>         Sure. Otherwise how would it know if there is one AS or
>>>>>>>>         a pool of AS
>>>>>>>>         client chooses evil.com <http://evil.com/>
>>>>>>>>         <http://evil.com/> <http://evil.com/> the cert can be
>>>>>>>>         valid and
>>>>>>>>         res.example.com <http://res.example.com/>
>>>>>>>>         <http://res.example.com/> <http://res.example.com/>?
>>>>>>>>>
>>>>>>>>>         With a out of band check the client would never know
>>>>>>>>>         if a RS was
>>>>>>>>>         removed/revoked.
>>>>>>>>
>>>>>>>>>         I don’t see checking when refreshing a token as
>>>>>>>>>         something that is a
>>>>>>>>>         huge burden.
>>>>>>>>
>>>>>>>>>         If you check out of band in discovery you really have
>>>>>>>>>         no idea if the
>>>>>>>>>         client is checking.
>>>>>>>>
>>>>>>>>>>         On Mar 14, 2016, at 3:56 PM, Phil Hunt
>>>>>>>>>>         <[email-masked] <mailto:[email-masked]>
>>>>>>>>>>         <mailto:[email-masked]>
>>>>>>>>>>         <mailto:[email-masked]>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>         <mailto:[email-masked]>
>>>>>>>>>>>         <mailto:[email-masked]>>
>>>>>>>>>>>         wrote:
>>>>>>>>>>>
>>>>>>>>>>>         <mailto:[email-masked]>
>>>>>>>>>>>         <mailto:[email-masked]>>
>>>>>>>>>>>         *Cc:*oauth <[email-masked] <mailto:[email-masked]>
>>>>>>>>>>>         <mailto:[email-masked]> <mailto:[email-masked]>>
>>>>>>>>>>>         Discovery is the wrong place to try and provide
>>>>>>>>>>>         security against
>>>>>>>>>>>         If the API specific well known is not available the
>>>>>>>>>>>         client can try
>>>>>>>>>>>         That however was supposed to be dealt with as part
>>>>>>>>>>>         of the mixed up
>>>>>>>>>>>             On Mar 13, 2016, at 8:12 PM, Phil Hunt
>>>>>>>>>>>         <[email-masked] <mailto:[email-masked]>
>>>>>>>>>>>         <mailto:[email-masked]>
>>>>>>>>>>>         <mailto:[email-masked]>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                 Begin forwarded message:
>>>>>>>>>>>         <mailto:[email-masked]>
>>>>>>>>>>>         <mailto:[email-masked]>
>>>>>>>>>>>         <mailto:[email-masked]>
>>>>>>>>>>>         <mailto:[email-masked]>>,
>>>>>>>>>>>         <mailto:[email-masked]>
>>>>>>>>>>>                   This specification defines a mechanism for
>>>>>>>>>>>         the client of
>>>>>>>>>>>                 an OAuth 2.0
>>>>>>>>>>>                   to a specific resource service.  The
>>>>>>>>>>>         information
>>>>>>>>>>>         includes the OAuth
>>>>>>>>>>>                   2.0 component endpoint location URIs and
>>>>>>>>>>>         as well as
>>>>>>>>>>>         authorization
>>>>>>>>>>>         server capabilities.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                 Please note that it may take a couple of
>>>>>>>>>>>         minutes from the
>>>>>>>>>>>                 time of submission
>>>>>>>>>>>         <http://tools.ietf.org/> <http://tools.ietf.org/>.
>>>>>>>>>>>
>>>>>>>>>>>                 The IETF Secretariat
>>>>>>>>>>>
>>>>>>>>>>>         <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>>>         <mailto:[email-masked]> <mailto:[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Tue, 15 Mar 2016 16:26:18 -0300

I think Phil and others are concerned that a developer might get bad info to put in the client , some out of band discovery goes wrong or the user is somehow tricked into specifying a bad resource to the client.

So getting a bad resource is a touch hypothetical. 

For Connect we could suppose that someone publishes a malicious discovery document listing themselves as the RS but all the other endpoints are at the good AS so the client registers, authorizes the user and gives the AT to the bad guy.  The confused client mitigation by returning client_id_and issuer from the authorization endpoint will stop the attack before the token can be given to the token endpoint or RS.

So protecting the AT at this point is more for a unknown attack that would confuse whatever protocol/API that is using OAuth about what RS to use.

In reality this is what PoP is supposed to be for.

I guess the question is what short of PoP can we do to prevent the client leaking tokens to bad RS that confuse it via the application protocol.

If we want to del with this in OAuth then we need to tell the AS where the token is going to be used or tel the client where the token can be used. 

I think letting the client tell the AS where it wants the token used having the AS construct a audience out of that is probably the best thing.  to get around having a pre-established relationship between the AS and RS.

John B.

> On Mar 15, 2016, at 3:14 PM, George Fletcher <[email-masked]> wrote:
> 
> 
> 
> I think Justin provided a good break down of the different aspects a client wants to specify about the requested token. (my paraphrase)
> I'm not sure passing the full endpoint to the AS will help with my concerns... The AS could potentially do a webfinger on the resource URI and determine if it's an RS that it supports... though that requires all RS's to support webfinger. What I really want to avoid is the AS having this list of URIs to RS that is almost assuredly to get out of sync.
> 
> 
> 
> Actually, the error cases are interesting. What if the passed in resource/audience doesn't actually match a requested scope? Or some match and some don't? Is it better to send back a token with less capability? or error the entire request?
>> 
>> 
> I thought Justin provided a good break down of the different aspects a client wants to specify about the requested token. (my paraphrase)
> The question is how does a client internally reference a resource server? If it's a fixed RS endpoint, then it sort of doesn't matter, the client isn't going to send the token to the wrong endpoint anyway and it can easily reference the audience by an abstract URI.
> 
> If the client can dynamically find new RS's to interact with. How does that happen? Does the client get handed an endpoint to use? or does it do some sort of discovery to determine the endpoint? I suppose both are possible.
> 
> Could we prescribe that the realm value of RFC 6750 error response be effectively a resource-service-id (like issuer for the AS). The client would then need to do discovery on that value to find the valid endpoints of the RS. This could be done once and the resource-service-id could be used as the "abstract" RS identifier. This requires no more discovery than adding an AS to the client.
>> 
> I'm not sure passing the full endpoint to the AS will help with my concerns... The AS could potentially do a webfinger on the resource URI and determine if it's an RS that it supports... though that requires all RS's to support webfinger. What I really want to avoid is the AS having this map of URIs to RS that is almost assuredly to get out of sync.
>> 
>> 
>> John B.
>> 
>> 
>>> On Mar 15, 2016, at 2:44 PM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> On Tue, Mar 15, 2016 at 11:37 AM, John Bradley < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>>> On Mar 15, 2016, at 12:46 PM, Brian Campbell < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> On Tue, Mar 15, 2016 at 9:37 AM, John Bradley < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>>>> On Mar 15, 2016, at 12:09 PM, George Fletcher < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>>>>>>>>  <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]>> wrote: 
>>>>>>>> 
>>>>>>>>>  <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]>> wrote: 
>>>>>>>>> 
>>>>>>>>> Inline 
>>>>>>>>> 
>>>>>>>>> Phil 
>>>>>>>>> 
>>>>>>>>>  <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]>> wrote: 
>>>>>>>>> 
>>>>>>>>>  <http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt>http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt <http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt> 
>>>>>>>>>> 
>>>>>>>>> res.example.com <http://res.example.com/>  <http://res.example.com/><http://res.example.com/> <http://res.example.com/>? 
>>>>>>>>>> 
>>>>>>>>>>>  <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]>> wrote: 
>>>>>>>>>>> 
>>>>>>>>>>>  <http://www.independentid.com/>www.independentid.com <http://www.independentid.com/>  <http://www.independentid.com/><http://www.independentid.com/> <http://www.independentid.com/> 
>>>>>>>>>>>  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]>> 
>>>>>>>>>>>> wrote: 
>>>>>>>>>>>> 
>>>>>>>>>>>> *From:*OAuth [ <mailto:[email-masked]>mailto:[email-masked] <mailto:[email-masked]>]*On Behalf Of*John Bradley 
>>>>>>>>>>>> *To:*Phil Hunt < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]>> 
>>>>>>>>>>>> *Cc:*oauth < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]>> 
>>>>>>>>>>>>     On Mar 13, 2016, at 8:12 PM, Phil Hunt < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> 
>>>>>>>>>>>>      <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]>> wrote: 
>>>>>>>>>>>>      <http://www.independentid.com/>www.independentid.com <http://www.independentid.com/>  <http://www.independentid.com/><http://www.independentid.com/> <http://www.independentid.com/> 
>>>>>>>>>>>>      <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>         Begin forwarded message: 
>>>>>>>>>>>>         *From:* <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> 
>>>>>>>>>>>>          <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]> 
>>>>>>>>>>>>          <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]>>, "Anthony Nadalin" 
>>>>>>>>>>>>         < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]>>, 
>>>>>>>>>>>>          <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>          <https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt>https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt <https://www.ietf.org/internet-drafts/draft-hunt-oauth-bound-config-00.txt>
>>>>>>>>>>>>         Status: 
>>>>>>>>>>>>          <https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/>https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/ <https://datatracker.ietf.org/doc/draft-hunt-oauth-bound-config/> 
>>>>>>>>>>>>         Htmlized: 
>>>>>>>>>>>>          <https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00>https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00 <https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>         Abstract: 
>>>>>>>>>>>>         attools.ietf.org <http://attools.ietf.org/>  <http://tools.ietf.org/><http://tools.ietf.org/> <http://tools.ietf.org/>. 
>>>>>>>>>>>> 
>>>>>>>>>>>>         The IETF Secretariat 
>>>>>>>>>>>> 
>>>>>>>>>>>>      <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]> 
>>>>>>>>>>>>      <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>>  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]><mailto:[email-masked]> <mailto:[email-masked]> 
>>>>>>>>  <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> 
>>>>>>>  <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
> Identity Services Engineering     Work: [email-masked] <mailto:[email-masked]>
> AOL Inc.                          AIM:  gffletch
> Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch <http://twitter.com/gffletch>
> Office: +1-703-265-2544           Photos: http://georgefletcher.photography <http://georgefletcher.photography/>

---

From: George Fletcher <[email-masked]>
Date: Tue, 15 Mar 2016 17:28:52 -0400

On 3/15/16 3:26 PM, John Bradley wrote:
> I think Phil and others are concerned that a developer might get bad 
> info to put in the client , some out of band discovery goes wrong or 
> the user is somehow tricked into specifying a bad resource to the client.
>
If we are really trying to solve this problem holistically, then we 
probably need to first describe the use cases we want to solve. I'm 
starting to wonder if we are all providing solutions to slightly 
different use cases.
>
> For Connect we could suppose that someone publishes a malicious 
> discovery document listing themselves as the RS but all the other 
> endpoints are at the good AS so the client registers, authorizes the 
> user and gives the AT to the bad guy.  The confused client mitigation 
> by returning client_id_and issuer from the authorization endpoint will 
> stop the attack before the token can be given to the token endpoint or RS.
Agreed and I'm fine with this solution.
>
> So protecting the AT at this point is more for a unknown attack that 
> would confuse whatever protocol/API that is using OAuth about what RS 
> to use.
Yes. This is where we need to describe some use cases (preferably real 
vs contrived) before we propose solutions. In most cases the RS 
endpoints are hard coded into the client or maybe pulled from a 
different central config endpoint (which is fixed).

That's why the only case I could think of is a client that works with 
multiple RS endpoints from different providers that server the same 
content (e.g. PortableContacts API). In this use case, the user of the 
client would need to enter the location of the RS they wanted to use and 
then the flow would start from there. In reality, most services like 
this would have a fixed set of RS's they work with and again it wouldn't 
be dynamic.
> I guess the question is what short of PoP can we do to prevent the 
> client leaking tokens to bad RS that confuse it via the application 
> protocol.
>
> If we want to del with this in OAuth then we need to tell the AS where 
> the token is going to be used or tel the client where the token can be 
> used.
>
> I think letting the client tell the AS where it wants the token used 
> having the AS construct a audience out of that is probably the best 
> thing.  to get around having a pre-established relationship between 
> the AS and RS.
Even if the client tells the AS where it wants to use the token (via 
some endpoint URL), the AS still needs to have a relationship with the 
RS (at a minimum as an endpointURL-to-RS map) otherwise how can it 
determine if it is allowed to issue an access token to the user for that 
RS. This map is what I want to avoid "building" into the AS. Do we need 
"dynamic RS registration" to support this?

>
> John B.
>
>> On Mar 15, 2016, at 3:14 PM, George Fletcher <[email-masked] 
>> concerns... The AS could potentially do a webfinger on the resource 
>> URI and determine if it's an RS that it supports... though that 
>> requires all RS's to support webfinger. What I really want to avoid 
>> is the AS having this list of URIs to RS that is almost assuredly to 
>> get out of sync.
>>
>>
>>
>>> I guess the question is how to transition from now to a future 
>>> state.   If you cannot upgrade all the clients at once.
>>>
>>> A processing rule on the AS that allowed some clients to not send 
>>> the requested resource , but would error out for other upgraded 
>>> clients  with a "resource not allowed” oauth error would work and 
>>> not require the return of the resources.
>>>
>> I thought Justin provided a good break down of the different aspects 
>> a client wants to specify about the requested token. (my paraphrase)
>> server? If it's a fixed RS endpoint, then it sort of doesn't matter, 
>> the client isn't going to send the token to the wrong endpoint anyway 
>> and it can easily reference the audience by an abstract URI.
>>
>> If the client can dynamically find new RS's to interact with. How 
>> does that happen? Does the client get handed an endpoint to use? or 
>> does it do some sort of discovery to determine the endpoint? I 
>> suppose both are possible.
>>
>> effectively a resource-service-id (like issuer for the AS). The 
>> client would then need to do discovery on that value to find the 
>> valid endpoints of the RS. This could be done once and the 
>> resource-service-id could be used as the "abstract" RS identifier. 
>> This requires no more discovery than adding an AS to the client.
>>>
>> concerns... The AS could potentially do a webfinger on the resource 
>> URI and determine if it's an RS that it supports... though that 
>> requires all RS's to support webfinger. What I really want to avoid 
>> is the AS having this map of URIs to RS that is almost assuredly to 
>> get out of sync.
>>>
>>> John B.
>>>
>>>
>>>> I was thinking it'd be simpler to error, if the requested 
>>>> resource(s) weren't okay. That puts the burden of checking in the 
>>>> AS. And doesn't add anything to the token or authorization 
>>>> response. I see the potential similarity to scope but not sure it's 
>>>> worth it.
>>>>
>>>> On Tue, Mar 15, 2016 at 11:37 AM, John Bradley<[email-masked]>wrote:
>>>>
>>>>     If the client specifies the resource it wants the token for,
>>>>     then the meta-data would not be required unless the resources
>>>>     the token is good at are different from the request.
>>>>     default resources based on scopes then I think it is a good
>>>>     idea to tell the client what the resources are in the response.
>>>>
>>>>>     <[email-masked]> wrote:
>>>>>
>>>>>     If the client specifies the desired audience(s)/resource(s),
>>>>>     is that metadata to the client needed? The AS can audience
>>>>>     restrict the token as needed or respond with an error if it
>>>>>     can't or wont issue a token for the resource the client asked for.
>>>>>
>>>>>     On Tue, Mar 15, 2016 at 9:37 AM, John
>>>>>     Bradley<[email-masked]>wrote:
>>>>>
>>>>>         I think Phil would prefer the server rather than the
>>>>>         client do the check, but the client always needs to take
>>>>>         some responsibility to not leak tokens giving them to the
>>>>>         wrong RS or the code to the wrong token endpoint is leaking.
>>>>>
>>>>>         become more popular and the static relationship between
>>>>>         one RS and one AS will not be the majority of deployments
>>>>>         over time.
>>>>>
>>>>>         In any case where the client is configured up front to
>>>>>         know the RS and the AS it seems like that would not
>>>>>         require Phil’s Solution, but that is the only case
>>>>>         supported by that discovery.
>>>>>         If the client itself is bad there is not much you can do
>>>>>         to stop it from passing on the AT in way way it wants. 
>>>>>         That however is a different problem and needs claimed URI
>>>>>         or attestations to prevent client spoofing.
>>>>>>         <[email-masked]> wrote:
>>>>>>
>>>>>>         discovery is required to know the correct AS, etc. This
>>>>>>         is pretty much the classic use case for UMA and I'd
>>>>>>         rather not re-invent the wheel.
>>>>>>
>>>>>>         2. Creating a tight coupling between RS and AS such that
>>>>>>         RS endpoint changes must be continually communicated to
>>>>>>         the AS. If an RS supports multiple AS's then the RS has
>>>>>>         to deal with "guaranteed" delivery. The AS needs an
>>>>>>         endpoint to receive such communications. If not dynamic
>>>>>>         via APIs, then deployment of the new RS is bound by the
>>>>>>         associated AS's getting and deploying the new endpoints.
>>>>>>         Can both endpoints of the RS be supported within the AS
>>>>>>         for some period of time, etc. This is an operation
>>>>>>         nightmare and almost assuredly going to go wrong in
>>>>>>         production.
>>>>>>
>>>>>>         for those deployments that require this. I believe that
>>>>>>         is what John Bradley is suggesting.
>>>>>>
>>>>>>         Thanks,
>>>>>>         George
>>>>>>
>>>>>>>         descriptions to these concepts so that they cover all
>>>>>>>         use cases and can be applied unambiguously
>>>>>>>
>>>>>>>         Hans.
>>>>>>>
>>>>>>>>>         <[email-masked]
>>>>>>>>>>         <[email-masked]
>>>>>>>>>>         <[email-masked]
>>>>>>>>>>         Sure. Otherwise how would it know if there is one AS
>>>>>>>>>>         or a pool of AS
>>>>>>>>>>         client choosesevil.com
>>>>>>>>>>         <http://evil.com/><http://evil.com/>the cert can be
>>>>>>>>>>         valid and
>>>>>>>>>>         res.example.com
>>>>>>>>>>         <http://res.example.com/><http://res.example.com/>?
>>>>>>>>>>>
>>>>>>>>>>>         If you check out of band in discovery you really
>>>>>>>>>>>         have no idea if the
>>>>>>>>>>>         client is checking.
>>>>>>>>>>
>>>>>>>>>>>>         <[email-masked]
>>>>>>>>>>>>>         <[email-masked]<mailto:[email-masked]>>
>>>>>>>>>>>>>         wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>         *To:*Phil Hunt
>>>>>>>>>>>>>         <[email-masked]<mailto:[email-masked]>>
>>>>>>>>>>>>>         *Cc:*oauth <[email-masked]<mailto:[email-masked]>>
>>>>>>>>>>>>>         If the API specific well known is not available
>>>>>>>>>>>>>         the client can try
>>>>>>>>>>>>>         <[email-masked]
>>>>>>>>>>>>>         <[email-masked]<mailto:[email-masked]>>,
>>>>>>>>>>>>>         attools.ietf.org
>>>>>>>>>>>>>         <http://attools.ietf.org/><http://tools.ietf.org/>.
>>>>>>>>>>>>>
>>>>>>>>>>>>>         The IETF Secretariat
>>>>>>>>>>>>>

---

From: John Bradley <[email-masked]>
Date: Tue, 15 Mar 2016 19:14:58 -0300

If the AS is audience restricting the tokens then it just needs to put the right audience in the token based on what the client is asking for.  
That is safe as the RS wouldn’t be able to replay the token someplace else.

That would need to be a AS policy if it wanted to do that for unknown RS.   

Allowing more than one audience in a token is a convince but a well known security risk with bearer tokens.

A AS would probably want to have only one audience in a AT for a untrusted RS, but may allow multiple if they are all trusted.

John B.

> On Mar 15, 2016, at 6:28 PM, George Fletcher <[email-masked]> wrote:
> 
> 
> If we are really trying to solve this problem holistically, then we probably need to first describe the use cases we want to solve. I'm starting to wonder if we are all providing solutions to slightly different use cases.
>> 
> Yes. This is where we need to describe some use cases (preferably real vs contrived) before we propose solutions. In most cases the RS endpoints are hard coded into the client or maybe pulled from a different central config endpoint (which is fixed).
> 
> That's why the only case I could think of is a client that works with multiple RS endpoints from different providers that server the same content (e.g. PortableContacts API). In this use case, the user of the client would need to enter the location of the RS they wanted to use and then the flow would start from there. In reality, most services like this would have a fixed set of RS's they work with and again it wouldn't be dynamic.
>> 
> Even if the client tells the AS where it wants to use the token (via some endpoint URL), the AS still needs to have a relationship with the RS (at a minimum as an endpointURL-to-RS map) otherwise how can it determine if it is allowed to issue an access token to the user for that RS. This map is what I want to avoid "building" into the AS. Do we need "dynamic RS registration" to support this?
> 
>> 
>> John B.
>> 
>>> On Mar 15, 2016, at 3:14 PM, George Fletcher <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>> 
>>>>>>>>>>>>>  <http://www.independentid.com/>www.independentid.com <http://www.independentid.com/> <http://www.independentid.com/> <http://www.independentid.com/> 
>>>>>>>>>>>>>  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> 
>>>>>>>>>>>>>> wrote: 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> *Cc:*oauth < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>> 
>>>>>>>>>>>>>>      <http://www.independentid.com/>www.independentid.com <http://www.independentid.com/> <http://www.independentid.com/> <http://www.independentid.com/> 
>>>>>>>>>>>>>>      <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>         Begin forwarded message: 
>>>>>>>>>>>>>>         < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>>, 
>>>>>>>>>>>>>>      <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]> 
>>>>>>>>>>  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]>

---

From: George Fletcher <[email-masked]>
Date: Wed, 16 Mar 2016 10:27:20 -0400

On 3/15/16 6:14 PM, John Bradley wrote:
> If the AS is audience restricting the tokens then it just needs to put 
> the right audience in the token based on what the client is asking for.
So let's assuming a client sends a token audience restricted to GoodRS 
instead to EvilRS. When EvilRS replays the token at the GoodRS endpoint, 
how does GoodRS reject the token because when GoodRS sends the token to 
the AS for introspection (or does so itself) the token will be audience 
restricted to the GoodRS and it will process the token. The only way to 
prevent this is with client-authentication so that the presenter can be 
matched against who is allowed to present the token (aka PoP).

In the pure bearer token model, I don't see how this can be prevented at 
the protocol level.
> known security risk with bearer tokens.
True, but this means clients have to manage many tokens or call the 
token endpoint to get a "downscoped, audience restricted" token every 
time they need one. This is a very different model than what most people 
think of when they think of OAuth2. Not bad, just different:)
>
> A AS would probably want to have only one audience in a AT for a 
> untrusted RS, but may allow multiple if they are all trusted.
>
> John B.
>
>
>> On Mar 15, 2016, at 6:28 PM, George Fletcher <[email-masked] 
>>> user and gives the AT to the bad guy.  The confused client 
>>> mitigation by returning client_id_and issuer from the authorization 
>>> endpoint will stop the attack before the token can be given to the 
>>> token endpoint or RS.
>>> would confuse whatever protocol/API that is using OAuth about what 
>>> RS to use.
>> Yes. This is where we need to describe some use cases (preferably 
>> real vs contrived) before we propose solutions. In most cases the RS 
>> content (e.g. PortableContacts API). In this use case, the user of 
>> the client would need to enter the location of the RS they wanted to 
>> use and then the flow would start from there. In reality, most 
>> services like this would have a fixed set of RS's they work with and 
>> again it wouldn't be dynamic.
>>>
>>> If we want to del with this in OAuth then we need to tell the AS 
>>> where the token is going to be used or tel the client where the 
>>> token can be used.
>>>
>> some endpoint URL), the AS still needs to have a relationship with 
>> the RS (at a minimum as an endpointURL-to-RS map) otherwise how can 
>> it determine if it is allowed to issue an access token to the user 
>> for that RS. This map is what I want to avoid "building" into the AS. 
>> Do we need "dynamic RS registration" to support this?
>>
>>>
>>> John B.
>>>
>>>> I think Justin provided a good break down of the different aspects 
>>>> is the AS having this list of URIs to RS that is almost assuredly 
>>>> to get out of sync.
>>>>
>>>>
>>>>
>>>>> If you return the resources and let the client error if it is 
>>>>> trying to send to the wrong endpoint that make upgrading easier, 
>>>>> but gives less control to the AS.
>>>>>
>>>> I thought Justin provided a good break down of the different 
>>>> aspects a client wants to specify about the requested token. (my 
>>>> paraphrase)
>>>> server? If it's a fixed RS endpoint, then it sort of doesn't 
>>>> matter, the client isn't going to send the token to the wrong 
>>>> endpoint anyway and it can easily reference the audience by an 
>>>> abstract URI.
>>>>
>>>> Could we prescribe that the realm value of RFC 6750 error response 
>>>> be effectively a resource-service-id (like issuer for the AS). The 
>>>>>> response. I see the potential similarity to scope but not sure 
>>>>>> it's worth it.
>>>>>>
>>>>>>>         If the AT has a audience or audiences then as long as
>>>>>>>         the endpoint URI are provided as meta-data with the
>>>>>>>         token, the client can determine if it is sending the
>>>>>>>         token to the correct place.
>>>>>>>
>>>>>>>         some responsibility to not leak tokens giving them to
>>>>>>>         the wrong RS or the code to the wrong token endpoint is
>>>>>>>         leaking.
>>>>>>>
>>>>>>>         one RS and one AS will not be the majority of
>>>>>>>         deployments over time.
>>>>>>>
>>>>>>>         That however is a different problem and needs claimed
>>>>>>>         URI or attestations to prevent client spoofing.
>>>>>>>>         2. Creating a tight coupling between RS and AS such
>>>>>>>>         that RS endpoint changes must be continually
>>>>>>>>         communicated to the AS. If an RS supports multiple AS's
>>>>>>>>         then the RS has to deal with "guaranteed" delivery. The
>>>>>>>>         AS needs an endpoint to receive such communications. If
>>>>>>>>         not dynamic via APIs, then deployment of the new RS is
>>>>>>>>         bound by the associated AS's getting and deploying the
>>>>>>>>         new endpoints. Can both endpoints of the RS be
>>>>>>>>         supported within the AS for some period of time, etc.
>>>>>>>>         This is an operation nightmare and almost assuredly
>>>>>>>>         Maybe an OAuth2 "audience binding" spec is what's
>>>>>>>>         needed for those deployments that require this. I
>>>>>>>>         believe that is what John Bradley is suggesting.
>>>>>>>>
>>>>>>>>         Thanks,
>>>>>>>>         George
>>>>>>>>
>>>>>>>>>         +1, I've found the very same in OAuth deployments that
>>>>>>>>>         I was involved in; the hard part is to give names and
>>>>>>>>>>>>         How does this address the issue of whether the
>>>>>>>>>>>>         client is talking to
>>>>>>>>>>>>         the wrong endpoint?
>>>>>>>>>>>>>
>>>>>>>>>>>>>         There are also cases where a token might be good
>>>>>>>>>>>>>         at multiple RS
>>>>>>>>>>>>>         endpoints intentionally.
>>>>>>>>>>>>
>>>>>>>>>>>>         Sure. Otherwise how would it know if there is one
>>>>>>>>>>>>         AS or a pool of AS
>>>>>>>>>>>>>         With a out of band check the client would never
>>>>>>>>>>>>>         know if a RS was
>>>>>>>>>>>>>         removed/revoked.
>>>>>>>>>>>>
>>>>>>>>>>>>>>>         That however was supposed to be dealt with as
>>>>>>>>>>>>>>>         part of the mixed up

---

From: John Bradley <[email-masked]>
Date: Wed, 16 Mar 2016 11:46:06 -0300

If the client sends the uri of the resource it intends to send the token to
in the token request the bad guy would get only a token audianced to itself
and not to good RS.

You can't solve the problem of bearer tokens with multiple audiences
leaking.   That is a risk inherent in using that sort of token.
Compromise in one RS will impact all of them.

The only safe way with bearer to deal with a RS the AS dosen't trust a RS
is to only have one audianced in the token. (or by introspection)

We have always known that and left it up to clients to make sure they are
secure by not sending tokens to bad RS.

Now people want a AS check to prevent clients from being tricked if
developers are given bad info statically or dynamically.

What you are doing is safe as long as your developers don't make any
mistakes.
If you want to be safe and not have to preconfigure the AS you need to use
the refresh to get single audianced tokens, or PoP.

John B.
On Mar 16, 2016 11:27 AM, "George Fletcher" <[email-masked]> wrote:

> If the AS is audience restricting the tokens then it just needs to put the
> right audience in the token based on what the client is asking for.
> how does GoodRS reject the token because when GoodRS sends the token to the
> AS for introspection (or does so itself) the token will be audience
> True, but this means clients have to manage many tokens or call the token
> endpoint to get a "downscoped, audience restricted" token every time they
> need one. This is a very different model than what most people think of
> when they think of OAuth2. Not bad, just different:)
>
>
> A AS would probably want to have only one audience in a AT for a untrusted
> RS, but may allow multiple if they are all trusted.
>
> John B.
>
>
> I think Phil and others are concerned that a developer might get bad info
> to put in the client , some out of band discovery goes wrong or the user is
> somehow tricked into specifying a bad resource to the client.
>
> starting to wonder if we are all providing solutions to slightly different
> use cases.
>
>
> For Connect we could suppose that someone publishes a malicious discovery
> document listing themselves as the RS but all the other endpoints are at
> the good AS so the client registers, authorizes the user and gives the AT
> to the bad guy.  The confused client mitigation by returning client_id_and
> issuer from the authorization endpoint will stop the attack before the
> token can be given to the token endpoint or RS.
>
> So protecting the AT at this point is more for a unknown attack that would
> confuse whatever protocol/API that is using OAuth about what RS to use.
>
> Yes. This is where we need to describe some use cases (preferably real vs
> contrived) before we propose solutions. In most cases the RS endpoints are
> hard coded into the client or maybe pulled from a different central config
> endpoint (which is fixed).
>
> multiple RS endpoints from different providers that server the same content
> (e.g. PortableContacts API). In this use case, the user of the client would
> need to enter the location of the RS they wanted to use and then the flow
> would start from there. In reality, most services like this would have a
> fixed set of RS's they work with and again it wouldn't be dynamic.
>
>
> I guess the question is what short of PoP can we do to prevent the client
> leaking tokens to bad RS that confuse it via the application protocol.
>
> If we want to del with this in OAuth then we need to tell the AS where the
> token is going to be used or tel the client where the token can be used.
>
> having the AS construct a audience out of that is probably the best thing.
>  to get around having a pre-established relationship between the AS and RS.
>
> Even if the client tells the AS where it wants to use the token (via some
> endpoint URL), the AS still needs to have a relationship with the RS (at a
> minimum as an endpointURL-to-RS map) otherwise how can it determine if it
> is allowed to issue an access token to the user for that RS. This map is
> what I want to avoid "building" into the AS. Do we need "dynamic RS
> registration" to support this?
>
>
> John B.
>
> concerns... The AS could potentially do a webfinger on the resource URI and
> determine if it's an RS that it supports... though that requires all RS's
> to support webfinger. What I really want to avoid is the AS having this
> list of URIs to RS that is almost assuredly to get out of sync.
>
>
>
> resource/audience doesn't actually match a requested scope? Or some match
> and some don't? Is it better to send back a token with less capability? or
> error the entire request?
>
>
> I guess the question is how to transition from now to a future state.   If
> you cannot upgrade all the clients at once.
>
> requested resource , but would error out for other upgraded clients  with a
> "resource not allowed” oauth error would work and not require the return of
> the resources.
>
> If you return the resources and let the client error if it is trying to
> send to the wrong endpoint that make upgrading easier, but gives less
> control to the AS.
>
> The advantage of always sending it in the token request is that it allows
> the AS to do the mapping from a resource URI to one or more abstract
> audience for the token.
>
> The question is how does a client internally reference a resource server?
> If it's a fixed RS endpoint, then it sort of doesn't matter, the client
> isn't going to send the token to the wrong endpoint anyway and it can
> easily reference the audience by an abstract URI.
>
> that happen? Does the client get handed an endpoint to use? or does it do
> some sort of discovery to determine the endpoint? I suppose both are
> possible.
>
> would then need to do discovery on that value to find the valid endpoints
> of the RS. This could be done once and the resource-service-id could be
> used as the "abstract" RS identifier. This requires no more discovery than
> adding an AS to the client.
>
>
> concerns... The AS could potentially do a webfinger on the resource URI and
> determine if it's an RS that it supports... though that requires all RS's
> to support webfinger. What I really want to avoid is the AS having this map
> of URIs to RS that is almost assuredly to get out of sync.
>
>
> John B.
>
>
>>> check, but the client always needs to take some responsibility to not leak
>>> tokens giving them to the wrong RS or the code to the wrong token endpoint
>>> is leaking.
>>>
>>> required to know the correct AS, etc. This is pretty much the classic use
>>> case for UMA and I'd rather not re-invent the wheel.
>>>
>>> <mailto:[email-masked]> <[email-masked]> <[email-masked]>>
>>> wrote:
>>>
>>> <mailto:[email-masked]> <[email-masked]>
>>> <[email-masked]>> wrote:
>>>
>>> Inline
>>>
>>> Phil
>>>
>>> <mailto:[email-masked]> <[email-masked]> <[email-masked]>>
>>> wrote:
>>>
>>> client chooses evil.com <http://evil.com/> <http://evil.com/>
>>> <http://evil.com/> the cert can be valid and
>>> If this is
>>> ...

---

From: Brian Campbell <[email-masked]>
Date: Wed, 16 Mar 2016 09:00:46 -0600

Right, if the client asks for a token to use at https://evil.rs then the AS
can audience restrict the token to https://evil.rs so that it wouldn't be
usable at https://good.rs.

On Wed, Mar 16, 2016 at 8:46 AM, John Bradley <[email-masked]> wrote:

> If the client sends the uri of the resource it intends to send the token
> to in the token request the bad guy would get only a token audianced to
> itself and not to good RS.
>
>> would confuse whatever protocol/API that is using OAuth about what RS to
>> use.
>>
>> On Mar 15, 2016, at 2:44 PM, Brian Campbell <
>> <[email-masked]>[email-masked]> wrote:
>>
>> On Tue, Mar 15, 2016 at 11:37 AM, John Bradley < <[email-masked]>
>> [email-masked]> wrote:
>>
>>> On Mar 15, 2016, at 12:46 PM, Brian Campbell <
>>> <[email-masked]>[email-masked]> wrote:
>>>
>>> On Tue, Mar 15, 2016 at 9:37 AM, John Bradley < <[email-masked]>
>>> [email-masked]> wrote:
>>>
>>>> from passing on the AT in way way it wants.  That however is a different
>>>> problem and needs claimed URI or attestations to prevent client spoofing.
>>>> On Mar 15, 2016, at 12:09 PM, George Fletcher < <[email-masked]>
>>>> [email-masked]> wrote:
>>>>
>>>> On Mar 14, 2016, at 6:26 PM, John Bradley < <[email-masked]>
>>>> [email-masked]
>>>> <[email-masked]><mailto:[email-masked]> <[email-masked]>>
>>>> wrote:
>>>>
>>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) < <[email-masked]>
>>>> [email-masked]
>>>> <[email-masked]><mailto:[email-masked]>
>>>> On Mar 14, 2016, at 14:13, John Bradley < <[email-masked]>
>>>> [email-masked]
>>>> <[email-masked]><mailto:[email-masked]> <[email-masked]>>
>>>> wrote:
>>>>
>>>> <http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt>
>>>> client chooses evil.com  <http://evil.com/><http://evil.com/>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 16 Mar 2016 08:22:07 -0700

Your solution seems to require resourceuri = audience. 

Bound config avoids trying to require conversion or urls into aud and vice versa. 

Phil

> On Mar 16, 2016, at 07:46, John Bradley <[email-masked]> wrote:
> 
> If the client sends the uri of the resource it intends to send the token to in the token request the bad guy would get only a token audianced to itself and not to good RS. 
> 
> You can't solve the problem of bearer tokens with multiple audiences leaking.   That is a risk inherent in using that sort of token.   Compromise in one RS will impact all of them. 
> 
> The only safe way with bearer to deal with a RS the AS dosen't trust a RS is to only have one audianced in the token. (or by introspection)
> 
> We have always known that and left it up to clients to make sure they are secure by not sending tokens to bad RS. 
> 
> Now people want a AS check to prevent clients from being tricked if developers are given bad info statically or dynamically.
> 
> What you are doing is safe as long as your developers don't make any mistakes. 
> If you want to be safe and not have to preconfigure the AS you need to use the refresh to get single audianced tokens, or PoP.
> 
> John B.
> 
>> So let's assuming a client sends a token audience restricted to GoodRS instead to EvilRS. When EvilRS replays the token at the GoodRS endpoint, how does GoodRS reject the token because when GoodRS sends the token to the AS for introspection (or does so itself) the token will be audience restricted to the GoodRS and it will process the token. The only way to prevent this is with client-authentication so that the presenter can be matched against who is allowed to present the token (aka PoP).
>> 
>> In the pure bearer token model, I don't see how this can be prevented at the protocol level.
>>> 
>> True, but this means clients have to manage many tokens or call the token endpoint to get a "downscoped, audience restricted" token every time they need one. This is a very different model than what most people think of when they think of OAuth2. Not bad, just different:)
>>>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 16 Mar 2016 08:30:03 -0700

John,

Mis configured token endpoint and resource endpoint is the same client misconfiguration issue where a client is mis-informed by mistake or mis-deed. 

Why do you propose to solve token endpoint in config discovery but feel resource endpoint must be reverified each time in the core protocol? 

Phil

---

From: George Fletcher <[email-masked]>
Date: Wed, 16 Mar 2016 11:56:40 -0400

For me the difference between the /token endpoint and an RS endpoint is 
semantic. The /token endpoint is part of the AS and a critical part of 
the authorization flow.

RS endpoints are under the control of the RS.

Thanks,
George

On 3/16/16 11:30 AM, Phil Hunt (IDM) wrote:
> John,
>
> Mis configured token endpoint and resource endpoint is the same client 
> misconfiguration issue where a client is mis-informed by mistake or 
> mis-deed.
>
> Why do you propose to solve token endpoint in config discovery but 
> feel resource endpoint must be reverified each time in the core protocol?
>
> Phil
>
> On Mar 16, 2016, at 07:46, John Bradley <[email-masked] 
>> If the client sends the uri of the resource it intends to send the 
>> token to in the token request the bad guy would get only a token 
>> audianced to itself and not to good RS.
>>
>> The only safe way with bearer to deal with a RS the AS dosen't trust 
>> a RS is to only have one audianced in the token. (or by introspection)
>>
>> We have always known that and left it up to clients to make sure they 
>> are secure by not sending tokens to bad RS.
>>
>> If you want to be safe and not have to preconfigure the AS you need 
>> to use the refresh to get single audianced tokens, or PoP.
>>
>> John B.
>>
>> On Mar 16, 2016 11:27 AM, "George Fletcher" <[email-masked] 
>>>     If the AS is audience restricting the tokens then it just needs
>>>     to put the right audience in the token based on what the client
>>>     is asking for.
>>     So let's assuming a client sends a token audience restricted to
>>     GoodRS instead to EvilRS. When EvilRS replays the token at the
>>     GoodRS endpoint, how does GoodRS reject the token because when
>>     GoodRS sends the token to the AS for introspection (or does so
>>     itself) the token will be audience restricted to the GoodRS and
>>     it will process the token. The only way to prevent this is with
>>     client-authentication so that the presenter can be matched
>>     against who is allowed to present the token (aka PoP).
>>
>>>     Allowing more than one audience in a token is a convince but a
>>>     well known security risk with bearer tokens.
>>     True, but this means clients have to manage many tokens or call
>>     the token endpoint to get a "downscoped, audience restricted"
>>     token every time they need one. This is a very different model
>>     than what most people think of when they think of OAuth2. Not
>>     bad, just different:)
>>>
>>>>>     I think Phil and others are concerned that a developer might
>>>>>     get bad info to put in the client , some out of band discovery
>>>>>     goes wrong or the user is somehow tricked into specifying a
>>>>>     bad resource to the client.
>>>>>
>>>>     If we are really trying to solve this problem holistically,
>>>>     then we probably need to first describe the use cases we want
>>>>     to solve. I'm starting to wonder if we are all providing
>>>>     solutions to slightly different use cases.
>>>>>
>>>>>     For Connect we could suppose that someone publishes a
>>>>>     malicious discovery document listing themselves as the RS but
>>>>>     all the other endpoints are at the good AS so the client
>>>>>     registers, authorizes the user and gives the AT to the bad
>>>>>     guy.  The confused client mitigation by returning
>>>>>     client_id_and issuer from the authorization endpoint will stop
>>>>>     the attack before the token can be given to the token endpoint
>>>>>     or RS.
>>>>>     So protecting the AT at this point is more for a unknown
>>>>>     attack that would confuse whatever protocol/API that is using
>>>>>     OAuth about what RS to use.
>>>>     Yes. This is where we need to describe some use cases
>>>>     (preferably real vs contrived) before we propose solutions. In
>>>>     most cases the RS endpoints are hard coded into the client or
>>>>     maybe pulled from a different central config endpoint (which is
>>>>     fixed).
>>>>
>>>>     That's why the only case I could think of is a client that
>>>>     works with multiple RS endpoints from different providers that
>>>>     server the same content (e.g. PortableContacts API). In this
>>>>     use case, the user of the client would need to enter the
>>>>     location of the RS they wanted to use and then the flow would
>>>>     start from there. In reality, most services like this would
>>>>     have a fixed set of RS's they work with and again it wouldn't
>>>>     be dynamic.
>>>>>
>>>>>     I guess the question is what short of PoP can we do to prevent
>>>>>     the client leaking tokens to bad RS that confuse it via the
>>>>>     application protocol.
>>>>>
>>>>>     If we want to del with this in OAuth then we need to tell the
>>>>>     AS where the token is going to be used or tel the client where
>>>>>     the token can be used.
>>>>>
>>>>>     I think letting the client tell the AS where it wants the
>>>>>     token used having the AS construct a audience out of that is
>>>>>     probably the best thing.  to get around having a
>>>>>     pre-established relationship between the AS and RS.
>>>>     Even if the client tells the AS where it wants to use the token
>>>>     (via some endpoint URL), the AS still needs to have a
>>>>     relationship with the RS (at a minimum as an endpointURL-to-RS
>>>>     map) otherwise how can it determine if it is allowed to issue
>>>>     an access token to the user for that RS. This map is what I
>>>>     want to avoid "building" into the AS. Do we need "dynamic RS
>>>>>>     On Mar 15, 2016, at 3:14 PM, George Fletcher
>>>>>>     I think Justin provided a good break down of the different
>>>>>>     aspects a client wants to specify about the requested token.
>>>>>>     (my paraphrase)
>>>>>>     I'm not sure passing the full endpoint to the AS will help
>>>>>>     with my concerns... The AS could potentially do a webfinger
>>>>>>     on the resource URI and determine if it's an RS that it
>>>>>>     supports... though that requires all RS's to support
>>>>>>     webfinger. What I really want to avoid is the AS having this
>>>>>>>     I think it is a AS policy decision if it should error or
>>>>>>>     take the requested resource and issue a token audianced for
>>>>>>>     that resource.
>>>>>>     Actually, the error cases are interesting. What if the passed
>>>>>>     in resource/audience doesn't actually match a requested
>>>>>>     scope? Or some match and some don't? Is it better to send
>>>>>>     back a token with less capability? or error the entire request?
>>>>>>>
>>>>>>>     I guess the question is how to transition from now to a
>>>>>>>     future state.   If you cannot upgrade all the clients at once.
>>>>>>>
>>>>>>>     A processing rule on the AS that allowed some clients to not
>>>>>>>     send the requested resource , but would error out for other
>>>>>>>     upgraded clients  with a "resource not allowed” oauth error
>>>>>>>     would work and not require the return of the resources.
>>>>>>>
>>>>>>>     If you return the resources and let the client error if it
>>>>>>>     is trying to send to the wrong endpoint that make upgrading
>>>>>>>     easier, but gives less control to the AS.
>>>>>>>
>>>>>>>     The advantage of always sending it in the token request is
>>>>>>>     that it allows the AS to do the mapping from a resource URI
>>>>>>>     to one or more abstract audience for the token.
>>>>>>     aspects a client wants to specify about the requested token.
>>>>>>     (my paraphrase)
>>>>>>     The question is how does a client internally reference a
>>>>>>     resource server? If it's a fixed RS endpoint, then it sort of
>>>>>>     doesn't matter, the client isn't going to send the token to
>>>>>>     the wrong endpoint anyway and it can easily reference the
>>>>>>     audience by an abstract URI.
>>>>>>
>>>>>>     If the client can dynamically find new RS's to interact with.
>>>>>>     How does that happen? Does the client get handed an endpoint
>>>>>>     to use? or does it do some sort of discovery to determine the
>>>>>>     endpoint? I suppose both are possible.
>>>>>>
>>>>>>     Could we prescribe that the realm value of RFC 6750 error
>>>>>>     response be effectively a resource-service-id (like issuer
>>>>>>     for the AS). The client would then need to do discovery on
>>>>>>     that value to find the valid endpoints of the RS. This could
>>>>>>     be done once and the resource-service-id could be used as the
>>>>>>     "abstract" RS identifier. This requires no more discovery
>>>>>>     than adding an AS to the client.
>>>>>>>
>>>>>>     I'm not sure passing the full endpoint to the AS will help
>>>>>>     with my concerns... The AS could potentially do a webfinger
>>>>>>     on the resource URI and determine if it's an RS that it
>>>>>>     supports... though that requires all RS's to support
>>>>>>     webfinger. What I really want to avoid is the AS having this
>>>>>>     map of URIs to RS that is almost assuredly to get out of sync.
>>>>>>>
>>>>>>>     John B.
>>>>>>>
>>>>>>>
>>>>>>>>     <[email-masked]
>>>>>>>>     <mailto:[email-masked]>> wrote:
>>>>>>>>
>>>>>>>>     resource(s) weren't okay. That puts the burden of checking
>>>>>>>>     in the AS. And doesn't add anything to the token or
>>>>>>>>     authorization response. I see the potential similarity to
>>>>>>>>     scope but not sure it's worth it.
>>>>>>>>
>>>>>>>>     On Tue, Mar 15, 2016 at 11:37 AM, John
>>>>>>>>     Bradley<[email-masked] <mailto:[email-masked]>>wrote:
>>>>>>>>
>>>>>>>>         If the client specifies the resource it wants the token
>>>>>>>>         for, then the meta-data would not be required unless
>>>>>>>>         the resources the token is good at are different from
>>>>>>>>         the request.
>>>>>>>>         For backwards compatibility if the client is happy with
>>>>>>>>         the default resources based on scopes then I think it
>>>>>>>>         is a good idea to tell the client what the resources
>>>>>>>>         are in the response.
>>>>>>>>
>>>>>>>>         I suspect that it is simpler with less optionality and
>>>>>>>>         always return the resources, even if they are not required.
>>>>>>>>
>>>>>>>>         John B.
>>>>>>>>
>>>>>>>>>         <[email-masked]
>>>>>>>>>         <mailto:[email-masked]>> wrote:
>>>>>>>>>
>>>>>>>>>         If the client specifies the desired
>>>>>>>>>         audience(s)/resource(s), is that metadata to the
>>>>>>>>>         client needed? The AS can audience restrict the token
>>>>>>>>>         as needed or respond with an error if it can't or wont
>>>>>>>>>         Bradley<[email-masked]
>>>>>>>>>         <mailto:[email-masked]>>wrote:
>>>>>>>>>
>>>>>>>>>             The AS needs to infer an audience from the scopes
>>>>>>>>>             snd/or have the client specify the desired audience.
>>>>>>>>>
>>>>>>>>>             If the AT has a audience or audiences then as long
>>>>>>>>>             as the endpoint URI are provided as meta-data with
>>>>>>>>>             the token, the client can determine if it is
>>>>>>>>>             I think Phil would prefer the server rather than
>>>>>>>>>             the client do the check, but the client always
>>>>>>>>>             needs to take some responsibility to not leak
>>>>>>>>>             tokens giving them to the wrong RS or the code to
>>>>>>>>>             the wrong token endpoint is leaking.
>>>>>>>>>
>>>>>>>>>             I imagine that claims based access tokens are
>>>>>>>>>             going to become more popular and the static
>>>>>>>>>             relationship between one RS and one AS will not be
>>>>>>>>>             In any case where the client is configured up
>>>>>>>>>             front to know the RS and the AS it seems like that
>>>>>>>>>             would not require Phil’s Solution, but that is the
>>>>>>>>>             If the client itself is bad there is not much you
>>>>>>>>>             can do to stop it from passing on the AT in way
>>>>>>>>>             way it wants. That however is a different problem
>>>>>>>>>>             1. Client's accessing resources dynamically so
>>>>>>>>>>             that discovery is required to know the correct
>>>>>>>>>>             AS, etc. This is pretty much the classic use case
>>>>>>>>>>             for UMA and I'd rather not re-invent the wheel.
>>>>>>>>>>
>>>>>>>>>>             2. Creating a tight coupling between RS and AS
>>>>>>>>>>             such that RS endpoint changes must be continually
>>>>>>>>>>             communicated to the AS. If an RS supports
>>>>>>>>>>             multiple AS's then the RS has to deal with
>>>>>>>>>>             "guaranteed" delivery. The AS needs an endpoint
>>>>>>>>>>             to receive such communications. If not dynamic
>>>>>>>>>>             via APIs, then deployment of the new RS is bound
>>>>>>>>>>             by the associated AS's getting and deploying the
>>>>>>>>>>             supported within the AS for some period of time,
>>>>>>>>>>             etc. This is an operation nightmare and almost
>>>>>>>>>>>             +1, I've found the very same in OAuth
>>>>>>>>>>>             deployments that I was involved in; the hard
>>>>>>>>>>>             part is to give names and descriptions to these
>>>>>>>>>>>             concepts so that they cover all use cases and
>>>>>>>>>>>             can be applied unambiguously
>>>>>>>>>>>
>>>>>>>>>>>             Hans.
>>>>>>>>>>>
>>>>>>>>>>>>>>             How does this address the issue of whether
>>>>>>>>>>>>>>             the client is talking to
>>>>>>>>>>>>>>             the wrong endpoint?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>             There are also cases where a token might be
>>>>>>>>>>>>>>>             good at multiple RS
>>>>>>>>>>>>>>>             endpoints intentionally.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>              In your solution the client would need to
>>>>>>>>>>>>>>>             make a discovery request
>>>>>>>>>>>>>>>             for each endpoint.
>>>>>>>>>>>>>>             Sure. Otherwise how would it know if there is
>>>>>>>>>>>>>>             one AS or a pool of AS
>>>>>>>>>>>>>>             <http://evil.com/><http://evil.com/>
>>>>>>>>>>>>>>             <http://evil.com/>the cert can be valid and
>>>>>>>>>>>>>>             <http://res.example.com/><http://res.example.com/>
>>>>>>>>>>>>>>             <http://res.example.com/>?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>             If this is 
>>>>>>>>>
>>     ...
>>

---

From: John Bradley <[email-masked]>
Date: Wed, 16 Mar 2016 20:50:27 -0300

If you recall in Darmstadt, the group decided that the mix up attack needed to be addressed without requiring discovery.

That is why I keep saying the are separate issues.

The proposed fix from the group for the AS confusion was to return a issuer and client_id from the authorization endpoint, so that the client can check the authorization response and determine if the response came from the same AS that it made it’’s request to.

This is predicated on the precondition that the attacker can modify/proxy the request , but not the response from the legitimate AS.

The client checks each response and compares the request issuer with the response issuer.   It requires the client to be configured with a issuer for each AS.

As a happy coincidence the issuer string is a HTTPS URI and could be used in a discovery spec to get the meta-data for the AS.

I think that is confusing people into thinking that the IdP mixup mitigation used discovery.  It doesn’t.  

You are the one who is requiring discovery in your proposal.

I should point out that your proposal requires a trusted and validated issuer to be able to validate the RS.

If I were an attacker I could trick the client into registering with me I can give it my bad issuer-x and  it would talk to my bad web-finger and validate my bad RS at registration time.

On it’s own your discovery of the AS config and validation of the RS provides no improved security.

The client would still need to do per request validation of the issuer and client_id returned by the Authorization endpoint.

My proposal is to have the client send the RS URI to the AS and let it check with each request as well and skip the requirement for discovery.

Your proposal doesn’t remove the per authorization request check.

John B.

> On Mar 16, 2016, at 12:30 PM, Phil Hunt (IDM) <[email-masked]> wrote:
> 
> John,
> 
> On Mar 16, 2016, at 07:46, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Mar 16, 2016 11:27 AM, "George Fletcher" <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>>>> On Mar 15, 2016, at 6:28 PM, George Fletcher <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> 
>>>>>>>> On Mar 15, 2016, at 2:44 PM, Brian Campbell < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 16 Mar 2016 17:05:15 -0700

Nothing here has anything to do with mix-up. Thats another problem. 

Phil

> On Mar 16, 2016, at 16:50, John Bradley <[email-masked]> wrote:
>

---

From: "Nat Sakimura" <[email-masked]>
Date: Thu, 17 Mar 2016 15:26:11 +0900

Indeed, that’s what I suggested to Phil offline that we should draft a use case based requirement document. It looks to me that we are talking past each other with slightly different use-cases in mind. 

As far as I can tell, we do not have an agreement on the Requirements for discovery. We should first address it, then get back to the specific protocols. 

Best, 

Nat Sakimura

From: OAuth [mailto:[email-masked]] On Behalf Of George Fletcher
Sent: Wednesday, March 16, 2016 6:29 AM
To: John Bradley <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

(snip) 

(snip)

--

PLEASE READ :This e-mail is confidential and intended for the

named recipient only. If you are not an intended recipient,

please notify the sender  and delete this e-mail.

---

From: "Nat Sakimura" <[email-masked]>
Date: Thu, 17 Mar 2016 15:30:16 +0900

A disadvantage of this method is that it cannot be used in the case where concrete resource uri is unknown to the client until the user gives permission. 

Right, this is a different use case. That’s why we need a use-case driven Requirement document to start with. 

Nat

From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Wednesday, March 16, 2016 2:57 AM
To: Brian Campbell <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

(..snip..)

John B.

--

---

From: "Nat Sakimura" <[email-masked]>
Date: Thu, 17 Mar 2016 15:42:40 +0900

IMHO, list of URIs that represent the partial paths under the same authority would not be too onerous. 

e.g., if you have 

 <https://example.com/apis/v1/userinfo> https://example.com/apis/v1/userinfo

 <https://example.com/apis/v2/userinfo> https://example.com/apis/v2/userinfo

 <https://example.org/some/api/endpoint> https://example.org/some/api/endpoint

etc., then the AS may provide 

 <https://example.com/apis/> https://example.com/apis/

 <https://example.org/> https://example.org/

or something like that in the audiences. 

A completely new domain should not be trusted blindly. 

The resource should at least make sure to provide the domain as being under the same authority. 

Bearer Token is a Password. It should not be shared among different authorities. 

Best, 

Nat

From: OAuth [mailto:[email-masked]] On Behalf Of George Fletcher
Sent: Wednesday, March 16, 2016 3:15 AM
To: John Bradley <[email-masked]>; Brian Campbell <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

(..snip..) 

(..snip..)

--

---

From: Justin Richer <[email-masked]>
Date: Thu, 17 Mar 2016 08:58:23 -0400

The problem here is that the "authority" model built into the URI 
definition is completely broken by user-hosted content, as we saw in the 
attack on ESPN and several against Google+ in the last few years.

  -- Justin

On 3/17/2016 2:42 AM, Nat Sakimura wrote:
> https://example.com/apis/v1/userinfo
>
> https://example.com/apis/v2/userinfo
>
> https://example.org/some/api/endpoint
>
> https://example.com/apis/
>
> https://example.org/
>
> *From:*OAuth [mailto:[email-masked]] *On Behalf Of *George 
> Fletcher
> *Sent:* Wednesday, March 16, 2016 3:15 AM
> *To:* John Bradley <[email-masked]>; Brian Campbell 
> <[email-masked]>
> *Cc:* <[email-masked]> <[email-masked]>
> *Subject:* Re: [OAUTH-WG] New Version Notification for 
> requires all RS's to support webfinger. What I really want to avoid is 
> the AS having this list of URIs to RS that is almost assuredly to get 
> out of sync.
>
> (..snip..)
>
> --
>

---

From: George Fletcher <[email-masked]>
Date: Thu, 17 Mar 2016 10:43:19 -0400

If one of the APIs has an open-redirect problem, won't that cause the 
token to leak to the attacker? That's why we went to exact match in 
OpenID Connect. Does it not apply in this case?

Thanks,
George

---

From: George Fletcher <[email-masked]>
Date: Thu, 17 Mar 2016 10:44:18 -0400

+1 for a list of use cases :)

On 3/17/16 2:30 AM, Nat Sakimura wrote:
>
> A disadvantage of this method is that it cannot be used in the case 
> where concrete resource uri is unknown to the client until the user 
> gives permission.
>
> Right, this is a different use case. That’s why we need a use-case 
> driven Requirement document to start with.
>
> Nat
>
> *From:*OAuth [mailto:[email-masked]] *On Behalf Of *John Bradley
> *Sent:* Wednesday, March 16, 2016 2:57 AM
> *To:* Brian Campbell <[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Thu, 17 Mar 2016 12:48:31 -0300

The problem is similar to the one with redirect_uri,  if you allow user hosted content on the domain they will be able to get the token if it is sent as a query parameter, and might be able to if it is sent as a header.  

Unfortunately many OAuth clients are badly behaved and make use of the query parameter not considering the security issues.

Anything other than the AS or the client doing an exact URI match is going to leave some hole.

This is why we are working on POP that is the correct way to solve this for AS.

I think anything other than the client giving the AS the whole URI and the AS including that as a audience/destination and letting the RS figure out if it is correct is largely hopeless, as it will be to fragile or the client won’t do it.  

In the case of Phil’s proposal the discovery happens once at client setup so the AS has no idea if the client checked  before issuing the token.

I honestly think there are two viable options:
1 PoP tokens
2 Including the destination URI / RS URI (pick name) in the token in full and letting the RS decide if it has been man in the middled.

Everything else will be an endless game of wack-a-mole that increases complexity but gets little real security.

John B.

> On Mar 17, 2016, at 11:43 AM, George Fletcher <[email-masked]> wrote:
> 
> If one of the APIs has an open-redirect problem, won't that cause the token to leak to the attacker? That's why we went to exact match in OpenID Connect. Does it not apply in this case?
> 
> Thanks,
> George
> 
>> IMHO, list of URIs that represent the partial paths under the same authority would not be too onerous.  <>
>>  
>> e.g., if you have 
>>  
>> https://example.com/apis/v1/userinfo <https://example.com/apis/v1/userinfo>
>> https://example.com/apis/v2/userinfo <https://example.com/apis/v2/userinfo>
>> https://example.org/some/api/endpoint <https://example.org/some/api/endpoint>
>>  
>> https://example.com/apis/ <https://example.com/apis/>
>> https://example.org/ <https://example.org/>
>>  
>> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of George Fletcher
>> To: John Bradley <[email-masked]> <mailto:[email-masked]>; Brian Campbell <[email-masked]> <mailto:[email-masked]>
>> Cc: <[email-masked]> <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 17 Mar 2016 09:27:31 -0700

I think in the mis-configuration case, it is different form the redirect issues.

What we are concerned about is an attackers ability to convince the client to set up a connection via an attackers proxy which can even have a valid TLS enabled.  The client won’t know it has done something wrong. In fact it will confirm it has correctly connected to the attackers proxy.

I don’t believe we have to have exact-match to work here.  We need preferable an exact host match. 

I agree there can be a redirect issue pop up once we allow domain matching.  What we could ask the client to do is reconfirm discovery when it receives a redirect from a resource.  I’m not a fan of this because it depends on the client doing something that seems optional (even when it isn’t).  BUT….this might be the out for SP’s like George’s case where they don’t know the exact URL’s clients will be using.

Phil

@independentid

> On Mar 17, 2016, at 8:48 AM, John Bradley <[email-masked]> wrote:
> 
>> On Mar 17, 2016, at 11:43 AM, George Fletcher <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 17 Mar 2016 09:34:40 -0700

+1 for Nat's last few emails (avoiding generating too much traffic :-).

Re: below, this is where I was thinking of masking/filter in bound config.  The main thing that needs to be checked at 
configuration time is whether the client has a valid set of server host names to prevent a malicious proxy.

So all the examples you mention below do boil down to https://example.org or https://example.com

It’s not that the AS needs to return them. It simply needs to match them. If one of them matches, then the oauth config can be returned.

I do agree re-directs (of the ESPN scenario) can become an issue if a discovery system matches on *.example.com.  It presumes there are no open redirect servers in the example.com domain.  As I mention in another email, we should discuss what happens when any oauth connection is redirected.  Should the client re-validate the configuration?

Phil

@independentid

> On Mar 16, 2016, at 11:42 PM, Nat Sakimura <[email-masked]> wrote:
> 
> To: John Bradley <[email-masked] <mailto:[email-masked]>>; Brian Campbell <[email-masked] <mailto:[email-masked]>>
> Cc: <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>

---

From: George Fletcher <[email-masked]>
Date: Thu, 17 Mar 2016 13:14:53 -0400

If this assumption is true, then there is really no point to try and 
come up with a middle ground. If the client MUST present the full 
endpoint URL to protect against possible open-redirect flaws then we 
have the following case.

Client implements an instant messaging app. For the client to work, it 
needs to invoke 25 different APIs at the Instant Messaging service. When 
the client goes to get a token with scopes "sendIM" and "readBuddyList" 
it MUST present all 25 endpoint URLs so that the AS can determine if any 
of them are possible MITM endpoints.

This means the AS has to have a map (or be able to construct a map) of 
all 25 endpoints to the RS that implements the Instant Messaging 
service. This will be come a non-managable map quickly.

Now suppose the client also wants to show a new mail count and wants to 
add a scope of "mailCount". That might only be one additional API, but 
it's easy to extrapolate to this becoming untenable as well.

Thanks,
George

On 3/17/16 11:48 AM, John Bradley wrote:
> The problem is similar to the one with redirect_uri,  if you allow 
> user hosted content on the domain they will be able to get the token 
> if it is sent as a query parameter, and might be able to if it is sent 
> as a header.
>
> Unfortunately many OAuth clients are badly behaved and make use of the 
> query parameter not considering the security issues.
>
> I think anything other than the client giving the AS the whole URI and 
> the AS including that as a audience/destination and letting the RS 
> figure out if it is correct is largely hopeless, as it will be to 
> fragile or the client won’t do it.
>
> In the case of Phil’s proposal the discovery happens once at client 
> setup so the AS has no idea if the client checked  before issuing the 
> token.
>
> 2 Including the destination URI / RS URI (pick name) in the token in 
> full and letting the RS decide if it has been man in the middled.
>
> Everything else will be an endless game of wack-a-mole that increases 
> complexity but gets little real security.
>
> John B.
>
>
>>> *From:*OAuth [mailto:[email-masked]]*On Behalf Of*George 
>>> Fletcher
>>> *Sent:*Wednesday, March 16, 2016 3:15 AM
>>> *To:*John Bradley<[email-masked]>; Brian 
>>> Campbell<[email-masked]>
>>> *Cc:*<[email-masked]><[email-masked]>

---

From: George Fletcher <[email-masked]>
Date: Thu, 17 Mar 2016 13:17:44 -0400

From my perspective we are not trying to solve a mix-up case or any 
other attack. We are trying to solve for audience restricted tokens in 
OAuth2 without PoP. In working to solve that case, we also want to close 
any possible attacks but that is not the primary goal. I, personally, 
don't want a bunch of one-off solutions to identified attacks if we can 
design an cohesive solution that provides value and mitigates known attacks.

Thanks,
George

On 3/17/16 12:27 PM, Phil Hunt wrote:
> What we are concerned about is an attackers ability to convince the 
> client to set up a connection via an attackers proxy which can even 
> have a valid TLS enabled.  The client won’t know it has done something 
> wrong. In fact it will confirm it has correctly connected to the 
> attackers proxy.
>
> I agree there can be a redirect issue pop up once we allow domain 
> matching.  What we could ask the client to do is reconfirm discovery 
> when it receives a redirect from a resource.  I’m not a fan of this 
> because it depends on the client doing something that seems optional 
> (even when it isn’t).  BUT….this might be the out for SP’s like 
> George’s case where they don’t know the exact URL’s clients will be using.
>
>
> Phil
>
> @independentid
>> On Mar 17, 2016, at 8:48 AM, John Bradley <[email-masked] 
>> if it is sent as a query parameter, and might be able to if it is 
>> sent as a header.
>>
>> Unfortunately many OAuth clients are badly behaved and make use of 
>> the query parameter not considering the security issues.
>>
>> I think anything other than the client giving the AS the whole URI 
>> and the AS including that as a audience/destination and letting the 
>> RS figure out if it is correct is largely hopeless, as it will be to 
>>> If one of the APIs has an open-redirect problem, won't that cause 
>>> the token to leak to the attacker? That's why we went to exact match 
>>> in OpenID Connect. Does it not apply in this case?
>>>
>>> Thanks,
>>> George
>>>

---

From: George Fletcher <[email-masked]>
Date: Thu, 17 Mar 2016 13:21:21 -0400

I'm not personally convinced that it's possible to boil it down to 
"domain checking". That said, we probably should start a new thread with 
use cases:)

On 3/17/16 12:34 PM, Phil Hunt wrote:
> Re: below, this is where I was thinking of masking/filter in bound 
> config.  The main thing that needs to be checked at
> So all the examples you mention below do boil down to 
> https://example.org or https://example.com
>
> It’s not that the AS needs to return them. It simply needs to match 
> them. If one of them matches, then the oauth config can be returned.
>
> I do agree re-directs (of the ESPN scenario) can become an issue if a 
> discovery system matches on *.example.com <http://example.com>.  It 
> presumes there are no open redirect servers in the example.com 
> <http://example.com> domain.  As I mention in another email, we should 
> discuss what happens when any oauth connection is redirected.  Should 
> the client re-validate the configuration?
>
> Phil
>
> @independentid
>> On Mar 16, 2016, at 11:42 PM, Nat Sakimura <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> *From:*OAuth [mailto:[email-masked]]*On Behalf Of*George Fletcher
>> *To:*John Bradley <[email-masked] <mailto:[email-masked]>>; 
>> Brian Campbell <[email-masked] 
>> <mailto:[email-masked]>>
>> *Cc:*<[email-masked] <mailto:[email-masked]>> <[email-masked] 
>> <mailto:[email-masked]>>

---

From: John Bradley <[email-masked]>
Date: Thu, 17 Mar 2016 14:45:11 -0300

It is not just redirects that are a threat.  Any user hosted content could potentially extract an access token from a query parameter.

John B.
> On Mar 17, 2016, at 1:34 PM, Phil Hunt <[email-masked]> wrote:
> 
> So all the examples you mention below do boil down to https://example.org <https://example.org/> or https://example.com <https://example.com/>
> 
> I do agree re-directs (of the ESPN scenario) can become an issue if a discovery system matches on *.example.com <http://example.com/>.  It presumes there are no open redirect servers in the example.com <http://example.com/> domain.  As I mention in another email, we should discuss what happens when any oauth connection is redirected.  Should the client re-validate the configuration?
> 
> Phil
> 
> @independentid
>> On Mar 16, 2016, at 11:42 PM, Nat Sakimura <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: John Bradley <[email-masked]>
Date: Thu, 17 Mar 2016 15:05:00 -0300

Yes without pop the mappings become a challenge quickly.  

We don’t have any sort of API management in OAuth, and that makes trying to secure bearer tokens a real challenge if you want a single token with multiple audiences.

To have multiple audiences you need to have hight trust in all of the endpoints.   If the RS endpoints check the audience then you can have no trust in the RS as long as it has only one audience.

I do have a more basic question, and that would be how the client gets this bad RS URI. 

Without nailing that down mitigating it is turning into a circular conversation.

John B.

> On Mar 17, 2016, at 2:17 PM, George Fletcher <[email-masked]> wrote:
> 
> From my perspective we are not trying to solve a mix-up case or any other attack. We are trying to solve for audience restricted tokens in OAuth2 without PoP. In working to solve that case, we also want to close any possible attacks but that is not the primary goal. I, personally, don't want a bunch of one-off solutions to identified attacks if we can design an cohesive solution that provides value and mitigates known attacks.
> 
> Thanks,
> George
> 
>>> On Mar 17, 2016, at 8:48 AM, John Bradley < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>>> To: John Bradley  <mailto:[email-masked]><[email-masked]> <mailto:[email-masked]>; Brian Campbell  <mailto:[email-masked]><[email-masked]> <mailto:[email-masked]>
>>>>> Cc:  <mailto:[email-masked]><[email-masked]> <mailto:[email-masked]>  <mailto:[email-masked]><[email-masked]> <mailto:[email-masked]>

---

From: George Fletcher <[email-masked]>
Date: Thu, 17 Mar 2016 14:17:18 -0400

Agreed... so I started a new thread on use cases:) Here is one example.

Assume there is a client that speaks a known OAuth2 protected protocol 
(e.g. PortableContacts, or something like Jabber). A user of the client 
can enter the endpoint of their RS that speaks the protocol and the 
client "discovers" the rest. This is kind of how Thunderbird and other 
mail clients work. I would hope that OAuth2 protected application APIs 
would develop so that this is possible.

Thanks,
George

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 18 Mar 2016 02:56:08 +0000

We are talking about resource accesses here, right? There's no query
parameter from the point of view of OAuth: the access token is sent as
Authorize header over TLS, so I am a bit puzzled by your comment...

Nat

2016年3月18日(金) 2:49 John Bradley <[email-masked]>:

> It is not just redirects that are a threat.  Any user hosted content could
> potentially extract an access token from a query parameter.
>
> John B.
>
> It’s not that the AS needs to return them. It simply needs to match them.
> If one of them matches, then the oauth config can be returned.
>
> discovery system matches on *.example.com.  It presumes there are no open
> redirect servers in the example.com domain.  As I mention in another
> email, we should discuss what happens when any oauth connection is
> redirected.  Should the client re-validate the configuration?
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
>
>
>
> *From:* OAuth [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *George Fletcher
> *To:* John Bradley <[email-masked]>; Brian Campbell <
> [email-masked]>

---

From: John Bradley <[email-masked]>
Date: Fri, 18 Mar 2016 06:56:43 -0300

RFC 6750 Sec 2.3.

I wish clients used the header,   the reality is that the majority of
client developers use a query paramater because it is easy.

Form encoding is also allowed.

If the RS has user hosted content the web server may helpfully make the
headder available anyway to the web page.

Query is the worst.  In those cases the token will leak if someone gets at
the HTTP logs.

This is one of the reasons a specific audiance in the token is important to
limit the loss if a RS is compromised.

John B.
On Mar 17, 2016 11:56 PM, "Nat Sakimura" <[email-masked]> wrote:

>> It is not just redirects that are a threat.  Any user hosted content
>> could potentially extract an access token from a query parameter.
>>
>> John B.
>>
>> discovery system matches on *.example.com.  It presumes there are no
>> open redirect servers in the example.com domain.  As I mention in
>> another email, we should discuss what happens when any oauth connection is

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 18 Mar 2016 10:08:31 +0000

2.3 should be removed from RFC6750. There is no reason to do it now. When
we started the work, there was a lot of feature phones with no capability
to do header, but it has been 6 years now and they have largely
disappeared.

2016年3月18日(金) 18:56 John Bradley <[email-masked]>:

> This is one of the reasons a specific audiance in the token is important
> to limit the loss if a RS is compromised.
>
> John B.

---

From: John Bradley <[email-masked]>
Date: Fri, 18 Mar 2016 08:07:34 -0300

I agree,  but getting that horse back in the barn is not going to be an
overnight project.

We have multiple issues with bearrer tokens.  At the moment we punt the
issue to the client and count on it being configured properly to not leak
the AT.

Better tokens will never be as secure as PoP tokens ,   we can apply
various bandages to bearrer,  but the developers will as at what cost.

John B.
On Mar 18, 2016 7:08 AM, "Nat Sakimura" <[email-masked]> wrote:

>> Query is the worst.  In those cases the token will leak if someone gets
>> at the HTTP logs.
>>