w3c
Need to have authenticator-only extensions
In Section 9 of the specification (WebAuthn Extensions), it is stated that "Every extension is a client extension, meaning that the extension involves communication with and processing by the client." Such a definition is not conducive to experimentation through the extension mechanism, thus limiting innovations within the framework of WebAuthn. With every extension being a client extension, the client is free to discard any unknown extension, which most clients choose to do in reality. This makes it impossible to experiment with custom extensions between RPs and their accompanying authenticators before the custom extension is widely adopted by clients. Snice such experiments are needed to gauge the effectiveness of the new mechanism, having clients as the gatekeeper on what extensions can be used practically makes the extension mechanism useless in facilitating experimentations.
Instead, we should define a category of extensions that are authenticator-only. Clients should pass these extensions through to authenticators even if they do not recognize them.
This is not a security or privacy concern. For those authenticators that do not recognize the custom extension, they will ignore the extension and thus no effect whatsoever. For those authenticators that are prepared to process the custom extension, the client really should not get in the way to intercept such end-to-end interactions.
The argument that the client should reject unknown extension for fear of security and privacy concerns is unjustified. It's just like an internet service provider should not disrupt communication to end user's computers based on the fact that it does not recognize the communication type. Otherwise, it would be breaking the end-to-end principle of the Internet in the name of user protection.
Therefore, we need a category of authenticator-only extensions and avoid clients' arbitrary dropping of such extensions.
Proposed Change
Extensions are divided into client extensions and authenticator extension...
In my experience, browser clients filter out extensions that they do not recognised and will not pass them along to authenticators. I'm not arguing for or against the idea, just stating the observed current behaviour.
This is not a spec concern as the spec does not dictate that clients filter extensions.
Each client and user agent has their own security and privacy policies. I recommend you open issues with them.
This is not a spec concern as the spec does not dictate that clients filter extensions.
Each client and user agent has their own security and privacy policies. I recommend you open issues with them.
It could be a spec concern, if the spec were to say that a client MUST NOT filter out extensions it does not recognise. Of course it doesn't say that - at least not at the moment.
In my experience, browser clients filter out extensions that they do not recognised and will not pass them along to authenticators. I'm not arguing for or against the idea, just stating the observed current behaviour.
Yes, that's my observation too. This is precisely the reason why I'm making the proposal. Because the spec states that every extension is for clients, the clients are of course free to deal with them as they see fit. I'm arguing that we should not let clients be the gatekeepers for extensions meant for authenticators only.
It could be a spec concern, if the spec were to say that a client MUST NOT filter out extensions it does not recognise. Of course it doesn't say that - at least not at the moment.
Yes, I think this is the key point - browsers are currently making a choice because the spec has a hole in it. That hole should be clarified and explicit in what the behaviour is.
Though on the other hand, it's unlikely browsers will change their behaviour even if the spec were clarified.
This is not a spec concern as the spec does not dictate that clients filter extensions. Each client and user agent has their own security and privacy policies. I recommend you open issues with them.
It could be a spec concern, if the spec were to say that a client MUST NOT filter out extensions it does not recognise. Of course it doesn't say that - at least not at the moment.
I totally agree. The spec should spell out the correct behavior instead of leaving it to each client implementation to decide as it sees fit. In fact, there are plenty of specifications that dictate the pass-through behavior for unknown extensions on intermediates.
It could be a spec concern, if the spec were to say that a client MUST NOT filter out extensions it does not recognise. Of course it doesn't say that - at least not at the moment.
Yes, I think this is the key point - browsers are currently making a choice because the spec has a hole in it. That hole should be clarified and explicit in what the behaviour is.
Though on the other hand, it's unlikely browsers will change their behaviour even if the spec were clarified.
If browser vendors ignore what's in the specification, they shouldn't claim that their companies are behind the passkeys :-) I thought that all alliance members should make sure their implementations are complaint with the published specifications, no?
WebAuthn Level 2 had a provision for this (though optional):
Clients wishing to support the widest possible range of extensions MAY choose to pass through any extensions that they do not recognize to authenticators, generating the authenticator extension input by simply encoding the client extension input in CBOR. All WebAuthn Extensions MUST be defined in such a way that this implementation choice does not endanger the user’s security or privacy.
We dropped this in #1737 after discussions in #1730 and #1703 in order to make way for the new fromJSON methods, since no client in practice had implemented this generic pass-through.
Unfortunately I think this and the fromJSON methods mutually exclude each other, since there's no feasible way for clients to know which string inputs need to be converted to BufferSource for unknown extensions. As much as I agree with the proposal, I don't think there's any chance of reversing direction on this since RPs are already starting to depend on the fromJSON methods.
And even though it also makes my own job harder, I think it's actually better in the end for the Web that there's a fairly steep barrier to entry for deploying extensions. We've decided against many popularly requested features (see for example #1688 and many similar discussions) for the sake of not fragmenting the ecosystem with compliant-but-incompatible implementations, and a proliferation of extensions would encourage more fragmentation as RPs grow to rely on extensions supported only by some authenticators.
Thank @emlun for sharing the background behind this issue! Very helpful for someone like me who is familiar with WebAuthn in general but not so much in its detailed history.
I agree that permanently relying on extensions to modify the protocol behavior leads to fragmentation, which should not be encouraged. However, I see at least two legitimate uses of authenticator-only extensions. One, enterprises may use their own custom extensions with their own authenticators for their unique needs. The other, extensions are utilized to experiment with protocol enhancements before they are accepted into the main specification. Without such a pass-through property on intermediaries, it's impossible to run any such experiments, which is detrimental to evolve the protocol forward quickly.
I can understand that client browser vendors may not be so interested in supporting such a pass-through. However, a specification should spell out the best-practice behaviors of all participants in the system rather than merely collective wishes of existing players. This is for the long-term success of the protocol, which is the goal of all participants, I suppose. Unless we are content with the protocol being bogged down in supporting the most basic usage cases by small tweaks to the protocol, we must enable more experimentation. The extension mechanism is the powerful tool for this purpose.
Finally, I am surprised to learn that the utility method fromJSON was part of the reason for dropping pass-through processing. Isn't this in the implementation realm? While protocol design should take implementation easiness into consideration, letting implementation determine how the protocol should be specified sounds very backward to me. Simply separating the extensions into two parts, client and authenticator-only, should side-step the conflict with the utility method, even if we wish to use such a utility. Unless I am missing something here, it shouldn't be an issue as long as we do not mix the two types of extensions.
Passkeys in the context of WebAuthn is a great step in the right direction. I really wish this would have its rightful impact in the real world. I strongly suggest that we reconsider the necessity of the pass-through processing on clients.
Browsers also cannot make any guarantees to their users about the privacy & security of WebAuthn if they allow unvetted extensions.
If browser vendors ignore what's in the specification, they shouldn't claim that their companies are behind the passkeys :-) I thought that all alliance members should make sure their implementations are complaint with the published specifications, no?
This understanding of web standards is incorrect: the specification needs a browser implementation to become a standard, not the other way around. If no browser implements a certain feature, it's removed from the specification (or more commonly, never added in the first place).
There are other mechanisms to enable hardware experimentation & innovation on the web, e.g. WebUSB and WebBluetooth.
Unvetted extensions are not the right path as privacy and security of WebAuthn can be harmed with this approach. If people want certain functionality to be included in WebAuthn, please propose it formally so that WebAuthn WG can debate and build a consensus around it.
@nsatragno / @timcappalli , I would also say that current way of forking a browser to test something is also too much of burden for the developers. We should think of some way to lessen that burden. May be via flags in local environment or something.
Browsers also cannot make any guarantees to their users about the privacy & security of WebAuthn if they allow unvetted extensions.
If browser vendors ignore what's in the specification, they shouldn't claim that their companies are behind the passkeys :-) I thought that all alliance members should make sure their implementations are complaint with the published specifications, no?
This understanding of web standards is incorrect: the specification needs a browser implementation to become a standard, not the other way around. If no browser implements a certain feature, it's removed from the specification (or more commonly, never added in the first place).
If there is no support from browser vendors any specification involving a client component would essentially be meaningless. I understand that the platform vendors do have such power. The question is: is blocking unknown extensions the right thing to do? Is this in the best interest of this ecosystem?
As I stated earlier, I don't think there is a real security and privacy concern for allowing extensions clearly marked as intended only for authenticators to pass through. If an authenticator willingly choose to participate in processing the custom extensions, such a behavior won't jeopardize those unsuspecting authenticators in any way. There are plenty of precedences on the Internet where intermediaries refrain from intercepting such end-to-end communication.
I strongly believe that it is not advisable for intermediaries to block all traffic that is unknown to them. Extensions are there for the precise reason we may not known all their uses ahead of time.
Unvetted extensions are not the right path as privacy and security of WebAuthn can be harmed with this approach. If people want certain functionality to be included in WebAuthn, please propose it formally so that WebAuthn WG can debate and build a consensus around it.
Ideally, we should debate and build a consensus on the best solution. In reality, you need evidence to convince people and that requires experiments to collect data. Requiring practitioners to fork their browser implementations (or just set custom flags in browser settings) will never enable any meaningful experimentation beyond developers' own devices. That is the reason why such blocking behavior on the browsers or platforms is really detrimental to the advancement of FIDO.