Comments (11)
Would the note be embedded in the resident key itself though? How will this work for yubikeys?
Feels a lot more like this is a specific notes field for passkeys that are managed by platforms.
from webauthn.
Would the note be embedded in the resident key itself though?
Perhaps it's more of a "client note", and leave it up to clients to handle maintaining a note for a given credential ID? The spec could add the value and suggest how clients might benefit from it, then leave the synchronization up to the clients like how we do with passkeys backup.
How will this work for yubikeys?
A "client note" model would potentially work for Yubikeys too.
from webauthn.
We have two fields now, and from the looks of it only one is being displayed.
We should try to get some consistency with what RP are sending and User agents are displaying before adding another field that won't be displayed.
If what is currently displayed is displayname then having the name be "mmiler@beta_environment" would be what was originally intended. The name field is the name of the account to display to the user in whatever format the RP wants.
I suspect this is an education problem along with the platforms not showing the info.
from webauthn.
Yeah by my reading of the following section this is the intent of the displayName
: https://www.w3.org/TR/webauthn-2/#dom-publickeycredentialuserentity-displayname
A human-palatable name for the user account, intended only for display. For example, "Alex Müller" or "田中倫". The Relying Party SHOULD let the user choose this, and SHOULD NOT restrict the choice more than necessary.
from webauthn.
If what is currently displayed is displayname then having the name be "mmiler@beta_environment" would be what was originally intended.
displayName
doesn't read like the kind of value that'd look like "mmiller@beta_environment". The name examples in the spec constrains thoughts of what are appropriate values for this field to "full name" representations of the user. Perhaps there's a chance here to expand the examples to denote this could be used for my "Beta Environment" example.
A human-palatable name for the user account, intended only for display. For example, "Alex Müller" or "田中倫". The Relying Party SHOULD let the user choose this, and SHOULD NOT restrict the choice more than necessary.
PublicKeyCredentialUserEntity's name
property seems similar, too - this field seems like it'd be where the user's email address might go:
The name field is the name of the account to display to the user in whatever format the RP wants.
So if we wanted to encourage full use of PublicKeyCredentialUserEntity
, perhaps we can clarify these two further with example use cases to satisfy my proposal.
from webauthn.
It turns out both Chrome and Safari use user.name
when displaying passkeys:
Android (uses user.displayName
too):
from webauthn.
I would be in favour of adding a few examples showing these use cases for user.displayName
and/or user.name
. There's no reason user.name
would have to be the account's primary email address (if any), it could easily accommodate something like mmiller (FooBank via AcmeIAM)
if the RP has several distinct namespaces (like some IAM services do). I guess we just hadn't considered that use case much, so the examples are a bit lacking.
Maybe we should also add a symmetric mention of "determining the difference" to displayName
- the name
description currently reads:
[...] It is intended only for display, i.e., aiding the user in determining the difference between user accounts with similar displayNames. [...]
but displayName
does not have a similar mention of disambiguating similar name
s. There's really not much reason either should be more or less likely to be similar between credentials.
from webauthn.
I think clarifying several of these parameters and their use cases may be helpful. For example another similar attribute that may be used is the PublicKeyCredentialEntity's name
value: https://w3c.github.io/webauthn/#dom-publickeycredentialentity-name
It also is meant to be human-palatable and may be chosen by the end user. In the context of this issue maybe this one mentioned is more applicable as it's more closely related to the actual credential itself?
from webauthn.
I think clarifying several of these parameters and their use cases may be helpful. For example another similar attribute that may be used is the PublicKeyCredentialEntity's
name
value: https://w3c.github.io/webauthn/#dom-publickeycredentialentity-name
In the screenshots above this is what I meant by "user.name
", it's this property that is currently used to help convey information about who a credential belongs to.
from webauthn.
Yeah I've completely misunderstood the spec in this area, both user.name
and user.displayName
are specific to the WebAuthn User Account, not the individual credential itself. It actually makes quite a lot of sense that a specific WebAuthn User Account may have multiple credentials and that something exists to clearly differentiate them in those circumstances.
from webauthn.
There's been clarification that user.name
can be arbitrary strings, not necessarily only email or user name. user.displayName
may be supported in certain clients and OS's, but by and large RP's should only count on user.name
being regularly shown to users.
from webauthn.
Related Issues (20)
- CredentialCreationOptions/mediation not yet defined in CredMan HOT 1
- Authenticator Attestation Response's [[transports]] should be an attribute rather than an internal slot. HOT 4
- Align the order of fields in PublicKeyCredentialDescriptorJSON with PublicKeyCredentialDescriptor HOT 2
- Dictionary members should be ordered lexicographically per Web IDL Standard HOT 3
- Allow conditional mediation flow without username or password field, I.E. from button press HOT 4
- Add support for hinting at verbiage other than "sign in" during authentication HOT 5
- Add support for IDNs and display domain names in Unicode for a more user friendly UX HOT 4
- Add examples for PRF extension HOT 3
- Passkey - Disable authentication with another device HOT 3
- Proposal for password-only authentication using ES256 HOT 10
- [[Create]] should not access the global object directly HOT 1
- Define `TypeError` behavior during `.get()` HOT 2
- Return more nuanced errors HOT 3
- Does Related Origins introduce a need for "Related RP IDs" support in `.get()`? HOT 1
- UTF-8 decode should not be required for response.clientDataJSON and cData HOT 2
- CollectedClientData fields are not ordered correctly and crossOrigin should be required
- Add `topOrigin` to the limited verification algorithm HOT 2
- Use URI instead of URL for related origins HOT 2
- Add `publicKey` and `publicKeyAlgorithm` to `AuthenticatorAssertionResponseJSON` HOT 3
- Make `AuthenticatorAttestationResponseJSON.publicKeyAlgorithm` optional HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webauthn.