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

[Brian Campbell <[e-mail]>]

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 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 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).

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.