- From: kpaulh via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Feb 2018 23:04:50 +0000
- To: public-webauthn@w3.org
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 supports token binding but did not negotiate it with the server because the server does not support it [reasonable situation]
- the client supports token binding but did not negotiate it with the server because there is a MITM and the server was tricked into believe the client didn't want token binding [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!
--
GitHub Notification of comment by kpaulh
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/798#issuecomment-365093833 using your GitHub account
Received on Monday, 12 February 2018 23:04:57 UTC