Arguing on the internet is usually about this effective in swaying one
viewpoint or the other.

I appreciate the discourse though and, short of a mad rush of support, I
concede on the proposal.

On Tue, May 17, 2016 at 4:35 PM, Andrei Popov <Andrei.Popov@microsoft.com>
wrote:

> Ø  The HTTP layer does need to know about TB for TB to be of any value -
> that's where the signature(s) get verified and where cookies and other
> tokens are actually bound.
>
> With the current TB message structure, the HTTP layer can simply pass the
> contents of the header to the TB library, get back verified bindings and
> act on the ones that the HTTP layer understands. And I like the fact that
> currently the TB library gets all available TB information at one time and
> in one piece.
>
>
>
> Ø  But my point isn't that it can't be done. It's that it's really useful
> to be able to look at HTTP and tell whats going on without having to use a
> protocol analyzer or TB parser.
>
> Understood. I’m merely pointing out that e.g. when debugging an issue,
> it’s usually not enough to see what types of bindings were sent, so
> generally one can’t avoid parsing TokenBinding messages anyway, and parsing
> tools will likely become available.
>
>
>
> Ø  It's not an optimization but rather just a simplification where the
> provided TB is always sent the same way no matter what and the
> referrer/referred is processed independently
>
> Provided and referred bindings can’t be processed entirely independently:
> e.g. referred binding cannot be used if the provided one fails
> verification. A TB library can only ensure this if it has access to all
> available bindings.
>
>
>
> Ø  But I was looking the share the viewpoint of what seems simpler at the
> HTTP layer from someone who works primarily at the HTTP layer.
>
> To be clear, I highly value your viewpoint, although I disagree with it.
> Bringing it up on the mailing list is certainly the right thing to do.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Brian Campbell [mailto:bcampbell@pingidentity.com]
> *Sent:* Tuesday, May 17, 2016 1:57 PM
> *To:* Andrei Popov <Andrei.Popov@microsoft.com>
> *Cc:* IETF Tokbind WG <unbearable@ietf.org>
> *Subject:* Re: [Unbearable] HTTPSTB: distinct header for the referred
> Token Binding (issue #35)
>
>
>
> Despite my lack of agreement, Andrei, I appreciate the reply. My replies
> inline below...
>
>
>
> On Tue, May 17, 2016 at 11:21 AM, Andrei Popov <Andrei.Popov@microsoft.com>
> wrote:
>
> Hi Brian,
>
>
>
> The current format, where all Token Bindings are contained in one Token
> Binding message, provides useful encapsulation. The HTTP layer does not
> need to know the details of the Token Binding protocol, which can be
> implemented in a separate library. If tomorrow we define a new Token
> Binding type, an existing HTTP implementation can carry it in the
> Sec-Token-Binding header without modification. Only the Token Binding
> library would need to be updated.
>
>
>
> The HTTP layer does need to know about TB for TB to be of any value -
> that's where the signature(s) get verified and where cookies and other
> tokens are actually bound.  If a new Token Binding type is defined (which
> honestly seems unlikely), yes it could be carried in the current format but
> the HTTP layer would also need to be updated to do anything useful with it.
> I don't see the benefit of this encapsulation.
>
> Ø  At 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.
>
> This can be solved by including a TB parser in the protocol analyzer.
> Which would also provide further useful insights into TB key parameters,
> etc.
>
>
>
> But my point isn't that it can't be done. It's that it's really useful to
> be able to look at HTTP and tell whats going on without having to use a
> protocol analyzer or TB parser.
>
>
> Ø  Having 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.
>
> I don’t think there’s an optimization an HTTP stack can do WRT building TB
> messages that a Token Binding library can’t, and the Token Binding library
> is where such optimizations belong.
>
>
>
> It's not an optimization but rather just a simplification where the
> provided TB is always sent the same way no matter what and the
> referrer/referred is processed independently. To my eye, that's better
> cohesion and less coupling.
>
> HTTP/2 header compression, however, is an optimization in the HTTP layer
> that would be helped by having the provided TB header not change.
>
>
>
>
>
> For the above reasons, I would prefer to keep all Token Bindings in one
> Token Binding message.
>
>
>
>
> I got a pretty good idea of your preference when I first mentioned
> separate headers in BA :) My preference is obviously different and I wanted
> to voice that on the list/github. But I guess ultimately it's an aesthetics
> or eye of the beholder kind of thing. I won't fight about it too hard. And
> I'm just a guy, not an editor. But I was looking the share the viewpoint of
> what seems simpler at the HTTP layer from someone who works primarily at
> the HTTP layer. I hope that viewpoint can be considered even though two
> headers is different than what's already done.
>
> I'd also be interested in knowing if others in the WG have opinions here
> or if I'm the outlier?
>
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *Brian
> Campbell
> *Sent:* Monday, May 16, 2016 1:22 PM
> *To:* IETF Tokbind WG <unbearable@ietf.org>
> *Subject:* [Unbearable] HTTPSTB: distinct header for the referred Token
> Binding (issue #35)
>
>
>
> It seems like github recently started sending some notifications to the WG
> list but it's not clear how reliable that is so I'm gonna double post
> anyway. The text from
> https://github.com/TokenBinding/Internet-Drafts/issues/35 follows.
>
> 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.
>
> At 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.
>
> Having 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.
>
> I 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.
>
> Anecdotally, 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."
>
> I 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.
>
>
>
>
>