- From: Arshad Noor via GitHub <sysbot+gh@w3.org>
- Date: Mon, 26 Dec 2016 23:39:42 +0000
- To: public-webauthn@w3.org
> 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 go down the well-trodden path of PKI. The authentication part of the spec is "mandatory", but even though [transaction authorization](https://www.w3.org/TR/2016/WD-webauthn-20160531/#extension-txauth) 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/311#issuecomment-269249348 using your GitHub account
Received on Monday, 26 December 2016 23:39:49 UTC