Webauthn signature support

[chunningham]

UCANs are intended to be able to be created by 'regular end users' and also to be 'regular JWTs' (more or less). Webauthn (and/or FIDO2/CTAP) is rapidly gaining adoption as the standard/most ergonomic way for 'regular end users' to create signatures using authenticators. The signatures created by Webauthn/CTAP are unfortunately not at all compatible with JWT signature creation/verification as they are made over data which is supplied by the relying party and the user's authenticator (together called the assertion), however the JWT data can be included in the relying party data as the cryptographic challenge. Is some form of support for Webauthn a desirable feature of UCAN?

In CACAO it is possible in principle by encoding the data necessary to reconstruct the assertion in varsig format, could UCAN support something similar by embedding the data in the header? In any case, this would break the 'regular JWT' intent as signature verification would require extra data transformation steps, but IMO it could be worth it for ergonomic and adoption potential.

[bmann]

@chunningham we have proof of concept at https://passkeys.fission.app/ of making Passkeys work with UCAN

@hugomrdias @expede can weigh in with more details.

[expede]

@hugomrdias did the actual implementation so is the right person to ask. I'll do my best here though!

@chunningham We had a theory for a long time that we would have to add a alg: "passkey" signature algorithm as you roughly describe. I actually think that there's nothing wrong with that approach. Ethereum prepends data to signature payloads to namespace them, and this is along those lines.

However, I believe that we're able to sign directly with the Passkey using standard crypto using the PRF extension. It's not yet broadly available, but is expected to be "soon". I believe an example of generating such a key is shown on this line. Using this technique, we didn't have to change anything in the UCAN cryptosuite.

[expede]

🤔 we really should document this stuff in https://github.com/ucan-wg/ucan-fido (and maybe rename the stub spec to ucan-passkey or similar)

[chunningham]

That's really good to know, thanks! I had until now only considered prf for encryption keys. I agree there's nothing wrong with changing the data a little before signing/verification, I just prefer avoiding 'platform' specifics if possible to keep things straightforward. We will try this out sometime soon 😁

[hugomrdias]

@chunningham There's 3 approaches to this

1. what you described create a new signature type and embed the webauthn client and authenticator data in the ucan so a validator can verify the signature
2. use the prf extension to generate a seed for a keypair
3. use the largeBlob extension to save/store a seed created outside the webauthn setup

Several pros and cons depending on your use case and treat model the main one IMO is that option 1. keeps the secrets in the secure context of the passkey the others DO NOT. For now we are using option 2 (or 3 depending on env support) and just use it to bootstrap a delegation chain to the local "Agent" and DO NOT keep the secret around in memory for subsequent signatures.

Please feel free to ping me for a chat im hugomrdias everywhere in the webs, gmail and cal . com included.