{"action":"opened","issue":{"url":"https://api.github.com/repos/TokenBinding/Internet-Drafts/issues/35","repository_url":"https://api.github.com/repos/TokenBinding/Internet-Drafts","labels_url":"https://api.github.com/repos/TokenBinding/Internet-Drafts/issues/35/labels{/name}","comments_url":"https://api.github.com/repos/TokenBinding/Internet-Drafts/issues/35/comments","events_url":"https://api.github.com/repos/TokenBinding/Internet-Drafts/issues/35/events","html_url":"https://github.com/TokenBinding/Internet-Drafts/issues/35","id":155112135,"number":35,"title":"HTTPSTB: distinct header for the referred Token Binding","user":{"login":"b---c","id":3516573,"avatar_url":"https://avatars.githubusercontent.com/u/3516573?v=3","gravatar_id":"","url":"https://api.github.com/users/b---c","html_url":"https://github.com/b---c","followers_url":"https://api.github.com/users/b---c/followers","following_url":"https://api.github.com/users/b---c/following{/other_user}","gists_url":"https://api.github.com/users/b---c/gists{/gist_id}","starred_url":"https://api.github.com/users/b---c/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/b---c/subscriptions","organizations_url":"https://api.github.com/users/b---c/orgs","repos_url":"https://api.github.com/users/b---c/repos","events_url":"https://api.github.com/users/b---c/events{/privacy}","received_events_url":"https://api.github.com/users/b---c/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-05-16T20:17:00Z","updated_at":"2016-05-16T20:17:00Z","closed_at":null,"body":"As mentioned [at IETF 95](https://datatracker.ietf.org/doc/minutes-95-tokbind/) I propose that the referred Token Binding be sent via a separate header (say Sec-Referred-Token-Binding) rather than as part of the Sec-Token-Binding header. \r\n\r\nAt the HTTP layer separate headers will make it much more clear what is going on. Just looking for the presence or absence of the Sec-Referred-Token-Binding header will indicate if a referred TB was sent, which is very easy. Rather than having to decode the Sec-Token-Binding header value and process the binary content, which is possible but much more involved. \r\n\r\nHaving a separate header for the referred TB allows the client/user agent to always send the provided TB via Sec-Token-Binding and not have to build a new TB message on the redirect request and then go back to the provided TB on subsequent requests. Also not having the value of Sec-Token-Binding change (other then a new TLS session with new EKM) should make it nicely efficient with HTTP/2 header compression. \r\n\r\nI also believe it will be easier to covey the concepts in the text of the spec. Talking about when the Sec-Referred-Token-Binding is sent or not sent rather than talking about when the referred TB is included as part of the TB message that is sent with Sec-Token-Binding seems much more straightforward. \r\n\r\nAnecdotally, there's been some discussion about using TB in OpenID Connect and and in talking about it people often say \"the referred token binding header\", which isn't accurate relative to HTTPSTB-03 but belies the fact that federation folks already think about it as separate header. And I think that's a natural way think about it so it's not terribly surprising. I won't name any names but one of the chairs of the WG is among those who said \"the referred token binding header.\"\r\n\r\nI realize this is not an insignificant change but I strongly believe it'd be a simplification and improvement for HTTPS TB. There's not yet (that I'm aware of anyway) any profiling of TB for federation like protocols such OpenID Connect, OAuth or SAML so this would be an opportune time to change how the referred Token Binding is conveyed. \r\n\r\n\r\n\r\n"}}