Open timcappalli opened 1 month ago
Meaning is that if the RP is willing to display provider name, RP should rely on some sources of record, Map<aaguid, providerName>?
Meaning is that if the RP is willing to display provider name, RP should rely on some sources of record, Map<aaguid, providerName>?
Whatever you do for create to lookup the name/icon, you'd do for get.
Will the credProps
input and processing be changed too? If not, then that would suggest the practice of scrubbing the AAGUID during attestation when the "none"
AttestationConveyancePreference
is sent should be removed since now AAGUID can always be retrieved by an RP even for roaming authenticators.
Perhaps change the input from a boolean
to an enum
that allows an RP to still fetch rk
without the AAGUID and directing user agents to remove AAGUID when a particular enum
value is sent. User agents should be directed to receive user consent when AAGUID is queried the way some browsers do when something other than "none"
attestation is requested.
If we add it to credProps
on .get()
when how about we add it to credProps
for .create()
too? That way there becomes a single place to get unattested AAGUID for RPs that want it just for nicknaming, etc...
2024-10-09 call: consensus on option 2 (adding a new credProps option)
@agl had an important point that we overlooked. How does the client get the AAGUID in the first place (as credProps is populated by the client)? I suppose on create
, the client could copy it from the authData if provided, but that doesn't help on get
.
For security keys, the client can get it via getInfo
, but for passkey providers, this would require changes to platform WebAuthn APIs.
In the TPAC discussions, there was a desire to rely solely on AAGUID for passkey provider / authenticator naming, and to remove authenticatorDisplayName from credProps.
The challenge is that authenticatorDisplayName is available on .get and the AAGUID is not. AAGUID on .get allows an RP to update the user visible name if a passkey is migrated between providers.
Proposed Change
Potential options:
I think option 2 was the preferred path from the discussion?