Normalize CredentialsContainer.get() #35255
Conversation
wbamberg
requested review from
sideshowbarker and
pepelsbey
and removed request for
a team
wbamberg
requested review from
hamishwillee
and removed request for
sideshowbarker
Preview URLs (7 pages)
External URLs (4)URL:
URL:
(comment last updated: 2024-08-06 00:46:05) |
| - : An array of strings representing the credentials' federated identity providers (for example `"https://www.facebook.com"` or `"https://accounts.google.com"`). | ||
|
|
||
| ### `password` boolean value | ||
| - `federated` {{optional_inline}} |
There was a problem hiding this comment.
FYI only - a bit of a pity this isn't in BCD so it could be marked as deprecated by our system.s
There was a problem hiding this comment.
I would like to understand the situation regarding federated versus identity better, and generally improve our messaging on it.
AFAIK FedCM (which adds identity) is part of Google's efforts to deprecate third party cookies - so the big issue with federated is that it depends on third-party cookies. So I know that Google (at least) would like people not to use federated. But noone else even supports FedCM. So is it even right to talk about federated as deprecated? To what extent do web developers use identity versus federated? And how is this affected by Google's recent announcement that third-party cookies are not after all going away?
Perhaps @chrisdavidmills knows?
But anyway that's surely for a later PR.
There was a problem hiding this comment.
Yes. This is resolved since we don't know enough and it shouldn't be blocking. However leaving discussion open for @chrisdavidmills to comment if desired.
files/en-us/web/api/publickeycredential/parserequestoptionsfromjson_static/index.md
Outdated
Show resolved
Hide resolved
| status: | ||
| - experimental | ||
| spec-urls: https://w3c.github.io/webauthn/#dictdef-publickeycredentialrequestoptions |
There was a problem hiding this comment.
Same comment as https://github.com/mdn/content/pull/35255/files#r1703549848 - we need the spec url, but not sure whether we should have status (because we can't automate it) and whether we should have browser compat data for the associated get() option.
|
@wbamberg Yes, structure makes |
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
…mjson_static/index.md Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
… credentials-management-get * origin/credentials-management-get: Update files/en-us/web/api/identitycredentialrequestoptions/index.md
|
All right, I think I have addressed or argued with everything. Thank you for the review @hamishwillee , much appreciated as always! |
|
|
||
| {{GlossarySidebar}} | ||
|
|
||
| An **authenticator** is an entity that is inside or attached to the user's device, and that can perform the cryptographic operations needed to register and authenticate users, and securely store the cryptographic keys used in these operations. |
There was a problem hiding this comment.
This sentence is a bit of a mouthful, and should ideally be chopped up. We might remove how it is attached/integrated in the first sentence because this is covered in the second. Also answer the question "can this be software based"? That may be why you used the term "entity"?
Anyway, something like
| An **authenticator** is an entity that is inside or attached to the user's device, and that can perform the cryptographic operations needed to register and authenticate users, and securely store the cryptographic keys used in these operations. | |
| An **authenticator** is a device that that can perform the cryptographic operations needed to register and authenticate users, and securely store the cryptographic keys used in these operations. |
There was a problem hiding this comment.
Also answer the question "can this be software based"? That may be why you used the term "entity"?
Yes and yes. I agree about "attached to or inside" being covered well enough in paragraph 2, and I don't like "entity" very much either. But, I don't think we can use "device" here unless we also change "device" in paragraph 2. I think it is worth being clear about the hardware/software thing though.
Will make a suggestion.
There was a problem hiding this comment.
@wbamberg Looks great. Yes you have addressed my issues. Two left, but approving so you can merge when you have looked at them:
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
Co-authored-by: wbamberg <will@bootbonnet.ca>
|
Thanks for the reviews Hamish! |
This is a companion to #33360, doing the same thing for
CredentialsContainer.get()that #33360 did forCredentialsContainer.create().It's also some kind of step towards https://github.com/orgs/mdn/discussions/683.
I've created new dictionary pages for
PublicKeyCredentialRequestOptionsandIdentityCredentialRequestOptionsto give us space for the complex options for these credential types. The other, simpler, options I've continued to document inline.I've fixed some errors (e.g. ISTM that attestation options are not given to
get()when using WebAuth, they are only used forcreate()) and various misleading things (e.g. the implication thatAbortErroris only thrown when you're requesting an OTP credential). I've factored the parts on different credential types into a common format. It's very helpful to have a "credential types" guide we can refer to, to provide context for the API.I haven't done a lot of work on the detailed prose, in the interests of keeping this PR mostly focused on structural issues. I'd prefer to tackle things like that in follow-ups, unless I've actually regressed anything here.