Hybrid Transport (caBLE): State-assisted Transactions

[AlfioEmanueleFresta]

Tracking implementation of State-assisted Transactions (STs).

Includes:

• Implementing State-assisted Transactions from the FIDO v2.2 specification.
• Storage of liking information to known authenticators to be delegated to the application, by asking them to provide an implementation to a storage-provider interface.
• Applications that do not require state-assisted transactions may choose not to provide a storage backend.

Context:

• See Epic: caBLE authenticator support #259 (comment).
• Particularly relevant for Linux portal APIs. Passkeys stored on phones, accessed via hybrid transport, are likely to become the de-facto roaming credentials - equivalent to moving a HW key across devices.

[micolous]

Sounds like a plan, but isn't on my own radar at the moment (AFAIK Android is still the only one to implement state-assisted transactions). 😄

In addition to Chromium, I think webauthn.dll in Windows 11 might implement state-assisted transactions as a client, but it's been a while since I've poked at the Windows side of things.

The spec describes the linking data schema as:

type linkData struct {
	ContactID              []byte   `cbor:"1"`
	LinkID                 [8]byte  `cbor:"2"`
	LinkSecret             [32]byte `cbor:"3"`
	AuthenticatorPublicKey [65]byte `cbor:"4"`
	AuthenticatorName      string   `cbor:"5"`
	Signature              [32]byte `cbor:"6"`

// Unmarshalled AuthenticatorPublicKey, can ignore this
	authPublicKey      *ecdsa.PublicKey
// Tunnel server from the advertisement; could also be stored as a u16
	tunnelServerDomain string
}

On a storage layer, I think the operations webauthn-rs needs are:

• get linking data for all paired authenticators
  • selection could be through the existing Ui trait
• create or update linkage (if the pubkey exists, then it's an "update")
• delete linkage by pubkey (on tunnel server returning HTTP 410, on user requested deletion)

I'm not sure whether the API an application provides should be:

• webauthn-rs expects the application store or return an opaque blob.

  This makes things simple for an application, but means it's less flexible. Also means we need to handle any schema migrations in the library, and provide an interface for an application to manipulate it.

  Theoretically, if we defined the schema, then an application could store it in a well-known location, then it can be shared between applications on the same host.

• webauthn-rs expects the application to provide a higher-level API with the operations it needs, and then the application is responsible for implementing it.

  This makes things flexible for an application, but more work to provide it. Applications would need to figure out link management themselves.

With either storage option, the state could be synced between computers running the same application (through some other side-channel the app provides).

The actual blob would be pretty small (< 1 KiB) even if everything were encoded in JSON and you had many links, so I think there's limited need for "creativity" in how that's actually serialised.