Re: [OAUTH-WG] explicit/implicit signaling to reveal TB ID

[Justin Richer <[e-mail]>]

+1 to this.

I think we also need to keep in mind that it's incredibly common for an 
OAuth client to talk to multiple resource servers with a single token 
from a single authorization server that's been configured (and agreed 
upon, out of band) to protect those resource servers. The client doesn't 
know or care about the details of the deployment, it just knows that it 
can get a token to work across various parts of the API.

  -- Justin


On 9/30/2016 4:03 PM, Brian Campbell wrote:
> Sending this to both the Tokbind and OAuth lists.
>
> There is text now in HTTPSTB that says that a TB ID must only be 
> conveyed to a different server, if the associated server explicitly 
> singles to do so. Specifically these two snippets,
>
> https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section-5 
> <https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section-5> has
>
>    However, such applications MUST only convey Token Binding IDs to
>    other servers if the server associated with a Token Binding ID
>    explicitly signals to do so, e.g., by returning an Include-Referred-
>    Token-Binding-ID HTTP response header field.
>
>
> and 
> https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section-7.3 
> <https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section-7.3> has
>
>    Also, applications must take care to only reveal Token Binding IDs to
>    other endpoints if the server associated with a Token Binding ID
>    explicitly signals to do so, see Section 5
>    "Implementation Considerations".
>
>
> This seems like it might be problematic for token binding of OAuth 
> access tokens. Many/most OAuth flows don't begin at the resource sever 
> (token consumer) but at the authorization server (token provider) so 
> there's not an opportunity for such an explicit signal. And even when 
> a request is made to the resource sever (token consumer) without a 
> token or with a bad token, there isn't a redirect but rather a 40x is 
> returned (see https://tools.ietf.org/html/rfc6750#section-3 
> <https://tools.ietf.org/html/rfc6750#section-3>).
>
> The relationship between OAuth servers is much more of an implicit 
> thing in how the OAuth client application (different than a browser 
> client) interacts with those severs. And there's correlatable info 
> already flowing between the two so revealing a referred TB doesn't 
> make the privacy situation any different. But it can greatly improve 
> the security of the access tokens.
>
> Can the text in HTTPSTB be reworked slightly to allow for an implicit 
> okay or a prearrangement to reveal referred Token Binding IDs for 
> applications which are not web browsers? Otherwise OAuth clients will 
> have to ignore that MUST or a token (pun intended) but really 
> meaningless signal will have to be invented for OAuth (like maybe a 
> new auth-param with the WWW-Authenticate Response Header Field from 
> RFC 6750.
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth