Meeting minutes
Web Authentication Update
John: Changes are happening to WebAuthn and authenticators about device public key
… and synchronizing credentials; see issue 1665 Synced Credentials. There are two pull requests (device public key extension, and backup states in authenticator data). Default behavior would be "can be synced"
… so want to air this change of expectation here.
Rolf: You have to look into the assertion to understand whether the key cannot leave the device. You say "I want a credential" and you might get two (one synchronizable and one not)
… you can look into the non-synchronizable one to get more security.
… you can distinguish first use and subsequent use.
John: The SPC API is going to have to essentially default the device public key extension to "True"
Rolf: Agreed
John: If the authenticator supports multi-device credentials, the additional security information would always come back for multi-device credentials.
… note that not all authenticators are likely to support this extension.
… but it's probably a good idea to always ask for it.
… at registration time you get a primary registration, and in the extension you get a secondary attestation (over the device key)
… if you send the extension during get() you would also get back the signature over the public key. These credentials roam devices, so every get() assertion, the assertion contains new registration information for the device public key.
… this means the complexity of the back end goes up.
… but this also means "way more risk information"; people can say whether it's the same person based on their account and whether it's a previously used device
… model is that for a given credential ID, there are potentially N public keys that are specific to each device.
… so there is a "group" public key and N "device-specific" public keys.
Ian: Any changes to SPC inputs?
John: Given that we may have situations where there's a 3p intermediary, I think the spec should always add the moral equivalent of the extension when talking to WebAuthn. API input would still be a list of credential IDs. If you want to get back both the signature for the sync key and the device-specific key, you want to have the extension turned on in SPC
Ian: What about outputs? Does the assertion change shape?
John: It will still be "one thing," but the extension would be part of the blob. There would potentially be a new attestation.
… might double the size of the response.
Sameer: if I break it down, sounds like no changes in what credential IDs are returned
ACTION: Ian to add to the SPC issues list the question of default extension on in SPC
John_Bradley: When evaluating the assertion, you'll need to look at the assertion to see whether this is (1) a synced credential and (2) whether this is a device I've seen before.
Sameer: What should issuer do if authentication is successful but device has not been seen before?
John: You won't get anything back if authentication is unsuccessful. If it's a valid group key, someone who controls the account is authenticating. So you need to look at the extension to see if you've seen this specific device before or not.
… and you can look at each attestation to see whether you trust the new device (public key) for future transactions.
… so you can add the new device public key to the back end
… let's use Apple just as an example.
… say you register once on the iPhone; the registration can be synchronized to iPad and laptop.
… when I do 3DS from my laptop, the assertion would tell you that the user of the credential ID has authenticated but it's a new device.
… and you can decide whether more ID&V is required before enrolling the new public key.
John: These are different biometrics possibly (since those are device-specific).
Ian: I am hearing that the new work is evaluating the new attestation (and whether to proceed silently or do more ID&V)
John: The default security is "the default security of the fabric."
… it's a good signal having the same credential from multiple devices. But not the same level of assurance that "this is the same device for the user."Look for a white paper from FIDO on this.
RPID as input
https://
Nick: We are looking for a response before closing
Next meeting
- No meeting 21 Feb
- Next meeting 28 Feb