W3C home > Mailing lists > Public > public-webauthn@w3.org > January 2022

Re: [webauthn] devciePubKey extension MUST be supported if passkey is supported (#1691)

From: John Bradley via GitHub <sysbot+gh@w3.org>
Date: Fri, 21 Jan 2022 22:47:54 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-1018920000-1642805273-sysbot+gh@w3.org>
I think the whitepaper that Dirk has been editing in the Fido2 TWG now defines passkey as a synonym for a Fido credential.

That probably should be a CTAP1 or CTAP2 Fido credential to be precise as there are still UAF Fido credentials that would not be covered.

Given that platform authenticators from Apple and Microsoft make all credentials as discoverable (I expect that Android will as well at some point) it may be easy to forget that passkeys should also include non discoverable credentials.  from existing authenticators.  Non Discoverable credentials may also have the property of being multi device.  Alexei from Google proposed several ways that could be done several years ago now.  

I admit that in the proposed new UI flow non-discoverable credentials are less useful, but that should be a separate issue from credential backup/syncing.

I expect that we will have RP with a range of usecases
1 want to be able to remove all passwords  multi-device in some synced state is required, may reject single device credentials
2 Don't care will take anything, won't bother with attestation  Probably 80%
3 Will take single and multi-device credentials but will require the devicePublicKey extension for high risk transactions.  
4 High risk Will always require attestation require single device only or multidevice with known devicePublicKey

3 will probably be the most complicated for the RP.  We are a long way from having out of the box solutions for that at the moment.

The idea of reusing some of the unused bits in the assertion is interesting.   
We would however need to take 2 bits.
1 Single Device 0 / multi-device capable 1
2 Not backed up 0 / backed up 1

Conveniently current authenticators setting  00 would be the correct thing by default.

I think we have two undefined bits but would need to double-check.

That could also be an extension but then the RP needs to ask each time.
It may be possible some platforms might toggle state between backed up and not depending on if the user has multiple devices or other factors.  Probably only sophisticated RP would look at it ongoing in the assertion but I think it should be included.    

That could also all be a separate extension if we want to give RP the option of asking for it or not. 
I sort of prefer to always return the info even if it is not solicited, I think that is cleaner.   
The other problem with extensions is that they have a longer lead time for platform API to implement, but I could go either way.

I don't like having multiple AAGUIDS that is nasty, I have put the most entries in the MDS, so have some experience. 

A single AAGUID for the authenticator that has appropriate flags in the assertion and makeCredential response is a better way to go.

The other thing to consider is that WebAuthn really has no say in how the authenticators behave.   That would be the Fido2 TWG and the Fido SPWG who would define what extensions would be mandatory for Fido certified authenticators.

Assuming that Authenticators that support multi-device passkeys can get Fido level 1 certified then it would be up to one for both of those groups to say that certain bit flags or extensions need to be supported for certification.

A current example of that is the security requirements require the credprotect extension be supported in any authenticator that supports discoverable credentials (Unless only level 3 is supported or UV is always done) 

I would leave it to the Fido SPWG to define the certification requirements and not try to add it to the WebAuthn specification where it would not really be validated in implementations. 

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 21 January 2022 22:47:56 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:45 UTC