Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

The threat that RFC6819 4.6.4 describes is when a client obtains an AT and then sends it to a counterfeit RS, which then uses the AT to access resources from a legitimate RS, on the end-user's behalf. The suggested countermeasure is a bit difficult to interpret: "Associate the endpoint URL of

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

Providing an “aud” doesn’t really secure the use of the token by the client at the RS. It really only helps the RS to know “is this token for me?” If the RS is bad, it doesn’t care because it knows it plans to use the “acquired” token with the legit RS anyway. That said, by having the client p

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

You could do that, but it is probably safer for the AS to know what RS it can issue tokens for and refuse to issue a token for RS A to a client asking for a token with RS X as the aud. John B. > On Mar 16, 2015, at 8:27 PM, Dixie Baker > wrote: > > The threat that RFC6819 4.6.4 describes is w

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

This may have been hashed out already and I missed it, but "aud" just becomes another kind of scope, correct? On Tuesday, March 17, 2015 8:50 AM, John Bradley wrote: You could do that, but it is probably safer for the AS to know what RS it can issue tokens for and refuse to issue

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

People have been overloading scope names to create implicit audience. The problem is that clients need to know via some magic method that you need to ask for scope "purple" to get write access to RS 2. Having an explicit "aud" parameter gives clients a way to communicate to the AS what RS th

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

I don't think it's "overloading scope names" to use them that way.  The aud value(s) could as easily be carried in scope as anywhere.  Nothing says a scope can't be "https://foo.com";, and that Foo.com requires that scope to be present for a token to be accepted.  I would not make it foo.com-rea

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

Yes but it is custom. People are inventing structured scopes like "aud:https://foo.com";, and that potentially doesn't solve the security issue if a client just passes on the scopes it receives in the error response, the bad RS just adds a scope for the good RS. The client then potentially nee

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

"Yes but it is custom.  People are inventing structured scopes like "aud:https://foo.com";, and that potentially doesn't solve the security issue if a client just passes on the scopes it receives in the error response, the bad RS just adds a scope for the good RS." This isn't solved by "aud", it

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

Or by OAuth 2 PoP. > On Mar 17, 2015, at 6:00 PM, Bill Mills wrote: > > "Yes but it is custom. People are inventing structured scopes like > "aud:https://foo.com ", and that potentially doesn't solve > the security issue if a client just passes on the scopes it receives

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

Yes.  There's still the open question of whether/how PoP tokens can be proxied internally within a site though.  If they can be proxied then it goes back to unsolved. On Tuesday, March 17, 2015 2:12 PM, John Bradley wrote: Or by OAuth 2 PoP.     On Mar 17, 2015, at 6:00 PM, Bill

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

PoP tokens need to be presented with a proof the presenter knows the secret. That is the same principal as in OAuth 1.0a with needing to show knowledge of the "token secret". I don't know what you mean by proxies internally. If the RS needs another token to access a resource it should use th

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

In practice one of the drawbacks of the Oauth 1.0a tokens was that they were not proxyable and so a connection to the edge then means you have to unwrap that and make a new internal token to be usedwhich isn't as good as the actual user credential.  On Tuesday, March 17, 2015 2:26 PM, Jo

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

This is fun:) I might ask what part of a OAuth 1.0a token is the user credential. That is a slippery idea in itself. The token is a reference to some notion of identity (in some cases) that needs to be dereferenced anyway. So in the same way a POP JWT access token in OAuth 2 that may indeed

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

STS? On Tuesday, March 17, 2015 2:40 PM, John Bradley wrote: This is fun:) I might ask what part of a OAuth 1.0a token is the user credential.   That is a slippery idea in itself.  The token is a reference to some notion of identity (in some cases) that needs to be dereferenced any

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

Security Token Service (STS) Sorry it is WS-* speak http://en.wikipedia.org/wiki/Security_token_service You can emulate some of it with the assertions extension. The WG has a document as a starting position for a more general approach. https://tools.ietf.org/html/draft-ietf-oauth-token-exchan

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

I also drafted a more generalized mechanism (that was much less WS-*-y) for doing an arbitrary token swap: https://tools.ietf.org/html/draft-richer-oauth-chain-00 Phil had pretty much the same idea separately. Personally, I still think