- From: Arshad Noor via GitHub <sysbot+gh@w3.org>
- Date: Thu, 29 Dec 2016 23:44:44 +0000
- To: public-webauthn@w3.org
_(Feels like I'm being asked to rearrange deck chairs....but, so be it)._ > 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 https://github.com/w3c/webauthn/issues/290#issuecomment-269711212 using your GitHub account
Received on Thursday, 29 December 2016 23:44:50 UTC