Re: [webauthn] What ensures any semblance of interop for WebAuthnExtensions?

_(Feels like I'm being asked to rearrange deck chairs....but, so be 

>  On #311 @nadalin said: This API is strictly about Web 
Authentication the implementations may or may not implement 
transaction confirmation, so that is out of scope

It seems to me that this is starting to go down the well-trodden path 
of PKI.

The authentication part of the spec is "mandatory", but even though 
transaction authorization is part of the same spec, it is optional? 
So, between Authenticators that can choose to implement what they 
want, servers that can choose to implement what they want and 
platforms/browsers in-between that can choose to implement what they 
want, WebAuthn Relying Parties are going to be in the same pickle that
 PKI RPs are in - different parts of the ecosystem that will not 
interoperate unless you buy/choose everything from the same or an 
extremely limited set of manufacturers. So, what would be the point of
 the standard? We had RFC 5280 as a standard for two decades; do you 
see many people using TLS ClientAuth - just ClientAuth and not any of 
the extensions - to solve authentication problems? (Arguing that 
hundreds of millions of Client digital certificates have been issued 
worldwide is not the right answer).

It would seem to me that we should learn from past PKI mistakes and 
correct course for the future. For nearly three years, I had argued 
for keeping all extensions out of the [FIDO] spec; since that is not 
to be, I will now argue that defined extensions be made mandatory so 
RPs will have the assurance that all parts of the ecosystem will work 
together regardless of whose component they choose. Anything less will
 only lead RPs down the PKI garden-path again.

GitHub Notification of comment by arshadnoor
Please view or discuss this issue at 
using your GitHub account

Received on Thursday, 29 December 2016 23:44:50 UTC