What ensures any semblance of interop for WebAuthnExtensions?

[bzbarsky]

As far as I can tell, absolutely nothing. Why are we introducing a mechanism for people to create various non-interoperable things here?

[bzbarsky]

And in particular, how does this allow authenticators to roam among clients?

[equalsJeffH]

This comment by @arshadnoor on issue #311 really should be moved over here to this issue.

[equalsJeffH]

This comment by @arshadnoor on issue #311 really should be moved over here to this issue.

uh...that's a not-so-subtle hint that @arshadnoor really oughta copy-n-paste that comment over to here and delete it from #311 ....

[arshadnoor]

(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.

[equalsJeffH]

@arshadnoor: thx :)

[jcjones]

After consideration, I agree with @arshadnoor's point that the extensions section is a painful (but avoidable!) source of fracture. I feel that we need to inline and make mandatory all extensions we're intending to have universal support, and move all others into a different document.

[leshi]

I agree with @jcjones and @arshadnoor

[AngeloKai]

I agree with @jcjones and @leshi. The extension section is painful and difficult to keep interop.

[selfissued]

As we discussed in the F2F, it's a business decision which extensions to support. They're extensions because supporting them is optional.

Also, for context, the working group made a decision very early on to merge all the technical specifications into a single document, both to make it easier to keep the content in sync, and so that we're not having to go for W3C approvals for multiple documents, with risk of delays and getting things out of sync that that entails. All the content, including the initially defined extensions, are in the same document for good reasons.

FYI, PR #386 should make it a lot clearer how to define and register new extensions. It makes it clear that the initially defined ones are not somehow "special".

[selfissued]

Now that #386 is done, I believe that the spec accurately reflects the intent of the extensions mechanism. I don't see an actual request for a specific change in this issue. Therefore, I believe we should close it. New issues could be filed with specific proposed changes, if desired, and we could evaluate them on their merits at that time.

[equalsJeffH]

Agree w/ @selfissued - closing.