- From: Stephen McGruer via GitHub <sysbot+gh@w3.org>
- Date: Tue, 14 Dec 2021 22:48:07 +0000
- To: public-webauthn@w3.org
> I am curious about what is not straightforward in addressing use case 1? Doesn't that use case just amounts to RP always have to look for namespaced-RPID while doing the validation instead of standard RPID. This assumes that WebAuthn WG considers authentication on cross-origin to namespaced-RPID (which is also not ratified). I think (but welcome input from others) that it is largely a question of developer ergonomics and whether one thinks they are acceptable or not. If a given RP only ever creates 1p-only **xor** 3p-enabled credentials, it is probably quite simple (either always pass a flag or always don't). However if they have both types (which seems feasible to me?) the RP now needs to keep track of which are which, make sure to pass the right flag for which credential they're trying to use, and (perhaps most importantly) I'm not clear how Discoverable Credentials with an empty `allowList` (for login) works in that case - I presume the RP can only select one namespace at a time. In a world where we didn't need additional authenticator powers for the conditionally-shown transaction UX, I think I would agree that the namespace solution would have enough benefits (works today, backwards compatible) to be the right pick. But given the desire for some authenticator API **anyway** (for conditional UX support), I think the 'bake the metadata bits into FIDO' makes more sense. It also allows us to expand to other metadata bits in the future (I believe we heard from @timcappalli that that might be of interest?) -- GitHub Notification of comment by stephenmcgruer Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1667#issuecomment-994113412 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 14 December 2021 22:48:08 UTC