Re: [webauthn] Provide request deserialization, response serialization (#1683)

> As I'm reading this, you are expressing an opinion that WASM is a "demo" or a "toy" language, and not something you need to seriously consider in the surface area of webauthn and how it interacts with a browser.

I'm sorry if my message was interpreted that way. I'm trying to verify any requirements you may have.

If it helps, WASM instructions *or* Javascript code consuming authentication assertions within the browser has limited utility. You are making an authentication assertion into a locally held and easily user introspectable box. Whether you are protecting e.g. an IndexedDB database by a locally prompted password or WebAuthn, the data is still a local database, exposed one pane over via developer tools.

Remote infrastructure, whether running on top of WASM or a virtual or native machine architecture would be normally where you would produce challenges and verify the assertion.  The choice of execution architecture here should not have an impact over say, the choice of programming language.

There have been proposals to add e.g. a way to unlock a symmetric key with WebAuthn, which changes this equation significantly - but I'd argue serializing this symmetric key (or making it exportable in general) is probably a bad idea.

> I am extremely confused by what you are asking here, because I think you are confused about what I'm requesting.

To ask tersely - you asked for considerations. I asked for what those considerations would be.

> Both of which would be "breaking" changes to what a browser provides, and are desperately needed both so that RP's no longer need JS/WASM to mangle incoming requests so that nav.cred can understand it, but also because a large number of parameters in Webauthn an unsigned which opens the door to a number of potential security issues which extensions poorly defend from.

There are five buckets of information, somewhat blended together

1. The unprotected request from the relying party
2. Client collected data, such as the origin requesting WebAuthn, and client-specified authenticator extensions like CredProtect
3. The response to the unprotected request by the authenticator, signed by the previously negotiated public credential (on get) or potentially signed by attestation (on create), containing some of the information from 1 & 2.
4. Non-integrity-protected client information on the response. This includes getTransport() and getClientExtensionResults()
5. Helper information and Helper API for extracting some information returned from 3 in a non-integrity-protected manner. This includes the credential [[identifier]], getAttestationObject(), and getPublicKey().

These pieces represent multiple actors and multiple sets of security considerations/attacker models. That is why I hope the helper information (like getPublicKey and getAuthenticatorData) are not serialized as part of responses, as correct validation becomes that much harder if someone does part of their processing on e.g. the non-integrity-verified copy authenticator data. I'd much rather tooling like Webauthn-RS generate their own Helper API as appropriate from the serialized responses.



-- 
GitHub Notification of comment by dwaite
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1683#issuecomment-1017187750 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 20 January 2022 07:23:20 UTC