[Unbearable] clarifying Include-Referred-Token-Binding-ID (was Adam Roach's Yes on draft-ietf-tokbind-https-14: (with COMMENT))

[Brian Campbell <[e-mail]>]

On Tue, May 8, 2018 at 12:06 AM, Adam Roach <[e-mail]> wrote:

> §5.3:
>
> >  When a client receives the Include-Referred-Token-Binding-ID header,
> >  it includes the referred token binding even if both the Token
> >  Provider and the Token Consumer fall under the same eTLD+1 and the
> >  provided and referred token binding IDs are the same.  Note that the
> >  referred token binding is sent only on the request resulting from the
> >  redirect and not on any subsequent requests to the Token Provider.
>
> I think this needs some clarification about handling of multiple
> redirections of
> the transaction. E.g.: Token Consumer sends a 3xx to redirect the user to a
> Token Provider (using, perhaps, an endpoint that is in the process of being
> migrated), and then the Token Provider sends an additional 3xx to get the
> client to the correct server.  Presumably, the inclusion of the referred
> token
> binding should survive both redirections, but this text might be read as
> preventing that.



To the best of my recollection and understanding the intent of the document
and WG is that that first referred token binding does not in fact survive
multiple redirections.

In the example you have, when the Token Provider sends an additional 3xx to
get the
client to the correct server, if it includes the
Include-Referred-Token-Binding-ID response header, then the resulting
request to that correct server would include a referred token binding but
with the token binding ID used by client with the Token Provider. And if
that additional 3xx did not have the response header, then the resulting
request to that correct server wouldn't include a referred token binding at
all.

The Include-Referred-Token-Binding-ID response header informs the clients
to send the referred token binding only on the request resulting
immediately from the redirect that had the header. That's the complete
scope of its effect. If the next response has a
Include-Referred-Token-Binding-ID response header, then the process repeats
itself but does so independently from any previous requests/responses.

§5.3 in general is meant to specify this behavior. The text you quoted, I
think, is just meant to clarify that both provided and referred are sent
even when they are the same token binding ID because both servers fall
under the same eTLD+1. And that the referred is only sent on that first
request resulting from the 3xx.

It seems there's some ambiguity in the draft around this behavior that
should be clarified. I'm honestly not sure what text or changes to propose
to do that, however, as my rambling above probably demonstrates. Perhaps
the authors can step in here...

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._