UCANs + WebAuthN / “PassKey” support

[bmann]

We’ve started looking at how we can use WebAuthN and Apple / Google / Microsoft’s upcoming passwordless support and connect it into UCANs.

If you’re interested in this, please follow this thread. Feel free to add links and resources.

[dholms]

I want this so so bad

[fo-rk]

@MasterKale confirmed that largeBlob extension support was little-to-none across browsers, which confirmed my own testing on Mac. That seemed to me the most logical place for UCAN data to live in current WebAuthn spec, but I'd love to hear from anyone about where implementation is heading.

[cdata]

I spent a little bit of time looking into this today.

It seems like there is an opportunity to use the challenge / response flow of WebAuthn as an ad-hoc signing mechanism. When performing a creation or assertion operation against a credential, the challenge is supposed to be a buffer of high-entropy random values. But, it could be a buffer of data that we want to sign (if we were to bend the rules a bit), such as the candidate UCAN token data.

The main obstacle I can anticipate to using this approach to sign a UCAN is that what you get back from these operations is not a signature of the challenge, but a signature of the concatenation of the challenge and other metadata related to the operation.

A secondary concern is (optionally) supporting more credential types in order to improve coverage of candidate authenticators.

This is a fairly naive reading of the spec and its capabilities - am I interpreting it correctly? Have y'all spent additional time exploring this path?

[MasterKale]

I don't advertise this functionality much because it goes against the "simple" in SimpleWebAuthn, but both its verifyRegistrationResponse() and verifyAuthenticationResponse() support using WebAuthn ceremonies to sign arbitrary data.

Check out the release notes from v4.3.0, it shows you how to use it:

https://github.com/MasterKale/SimpleWebAuthn/releases/tag/v4.3.0

So long as you're up-to-date on your @simplewebauthn/server then both methods will support this creative use of challenges.

[MasterKale]

I forgot this is a spec repo, so I'll add that you might reference my implementation as inspiration on how to offer a straightforward API for others to leverage this aspect of WebAuthn 😛

[cdata]

Thank you for that validation @MasterKale .

If we assume for a second that it is within operating parameters (if not intended usage) for the challenge to be arbitrary data to be signed, it seems like UCAN would need to deviate from JWS in order to make use of it.

Roughly speaking, JWS is header + payload + sign(header + payload), while WebAuthn gives us back the challenge, some auth_data and a separate signature that is sign(challenge + auth_data). This means that verifying the signature from WebAuthn depends on having knowledge of auth_data. So, if we used WebAuthn to sign a UCAN, then auth_data needs to move around with the UCAN somehow in order for it to be verified.

[cdata]

Thank you for the good discussion in the UCAN-WG on the WebAuthn topic today. To recap what I gleaned: for UCAN-IPLD there is already a need for customized signature verification (https://github.com/ucan-wg/ucan-ipld/#25-signature), so I can assume that this is on the table for rs-ucan and may add experimental key support for WebAuthn signatures on that basis.

I did a quick test in Chrome and was able to generate an ed25519 credential (!) and sign data with it using the WebAuthn "PublicKeyCredential" path (no server required, not even a service worker, although the credential is scoped to the secure origin of the page), so that's really exciting. I was even able to use my phone as the authenticator for my desktop, which was kind of neat. I guess that means the phone holds the credential?

Also, there was some discussion on the perils of mixing authn/authz. It does seem like the UX of using WebAuthn to sign UCANs warrants careful consideration. The UX to sign a value in Chrome is just a box that says, "Verify your identity with [origin]," which really tells the user very little about why they are doing it. Maybe there is a missing complementary-to-UCAN authn primitive? Or maybe it's just a matter of holding UCANs in a way that doesn't confuse the user.