W3C home > Mailing lists > Public > public-webauthn@w3.org > December 2021

Re: [webauthn] Cross origin authentication without iframes (accommodating SPC in WebAuthn) (#1667)

From: Akshay Kumar via GitHub <sysbot+gh@w3.org>
Date: Wed, 15 Dec 2021 09:03:35 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-994532143-1639559013-sysbot+gh@w3.org>
> 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.

If an RP selects to be in this use case where they want both login as well as 3P payment credentials, then RP can choose to verify 3P namespaced RPID even for login all the time. I don't see any issue in that, except for UI.  

> 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?)

Conditional UX is a optional enhancement. You are only thinking about platform credentials for conditional UX. Any solution has to work with all kind of authenticators. Conditional UX has unsolved complications for security keys. Potentially unsolvable if we consider roamability nature of security keys and untrusted platform. In that case, we may have to fallback on RP making a explicit call with specific intent. 

With potential new use cases, we haven't gone through pros and cons yet on having overloading single credential vs having different credentials for different use cases. Overloading multiple use cases on same credential is not that simple. 

Anyway, overall it looks like if WPWG sees complications in namespace proposal, then I am afraid, we have to pause this discussion in WebAuthn WG and see what we can do in FIDO TWG which handles authenticators specific changes. This is a new requirement which will take sometime to find the right solution given the desire of multiple intents in the future. Which is fine. 

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 December 2021 09:03:37 UTC

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