TokenBindingId value doesn't permit the U2F "unused" value

[kpaulh]

Currently the WebAuthn spec defines the TB ID as just a base64url value. This does not allow for a sentinel value that indicates that the "client supports token binding, but did not use it because server claimed no support". This value was called "unused" in U2F.

Working on a PR to rectify this.

I'm sorry this went unnoticed until now. I don't think anyone else supports TokenBinding yet (?) and I think it will be a small change.

[kpaulh]

To expound some more:

The presence of the TokenBindingId indicates that the client and server negotiated and is using Token Binding, and the RP can use the ID to detect a MITM.

The absence of the TokenBindingId, however, doesn't permit the RP to distinguish between these two cases:

• The client does not support token binding [reasonable situation
• The client does support TB, but is masked by a MiTM that tells the server they don't [bad situation]

To distinguish between the three total states, we're proposing something along the lines of replacing
"DOMString TokenBindingID" in the CollectedClientData with

dictionary TokenBinding {
TokenBindingStatus status;
DOMString tokenBindingId;
};

enum TokenBIndingStatus { "present", "supported", "not supported" };

Open to suggestions, of course!

[emlun]

Seems reasonable to me. I agree with making it a separate property instead of a magic value.

If we rename the CollectedClientData property from tokenBindingId to tokenBinding, we could call the TokenBinding property just id instead of tokenBindingId.

status: "present" seems a bit redundant, since that would be implied if the tokenBindingId property exists. So perhaps it could even be reduced to this?

dictionary TokenBinding {
  optional boolean supported;
  optional DOMString id;
};

Then we would have the cases

• { "tokenBinding": { "id": "abcd" } }: supported and used;
• { "tokenBinding": { "supported": true } }: supported but not used;
• {}, { "tokenBinding": {} }, { "tokenBinding": { "supported": false } }: not supported.

But perhaps this makes the logic too convoluted. @kpaulh's proposal does look good to me as is.

[kpaulh]

We did consider that reduction of the status, but were thinking that the discrete states would be clearer and reduce misunderstanding. I think tokenBindingId -> id is a good change, though. Thanks!

[agl]

Kim is out at the moment so I did something that I hope is correct in #802.

[kpaulh]

+1 Thanks, Adam!