Meeting minutes
Payments/login use cases
https://
John_Bradley: Do we need to differentiate between vanilla webauthn and spa-enabled; any reason to do this in the browser?
… is there a requirement to do something *in the browser*?
smcgruer_[EST]: My understanding is that we don't need something in the browser, but we've heard some people say "don't allow this to be used for payments unless RP has explicitly set it."
John_Bradley: RP has total control for 1p use cases.
… they can use two different RPID's
doug: Would be great if RP is tasked with deciding which RPIDs to provide to merchants
… but because merchant is invoking API, could it not add to the credential list?
… I'm hearing that the RP could not be assured that no other credential IDs are used by the merchant.
John_Bradley: We need to separate how to solve 1p context before we start ....
… looking at 3p
… if we can agree that 1p uses are ok, then we can focus on a "3p capable" flag.
smcgruer_[EST]: From my view, I don't hear a disagreement. I think the 1p use cases are fine.
John_Bradley: Regarding prefix / postfix to RPID...I think akshay leaning to "postfix" such as "#payment"
… if we can agree that it's a different namespace.
… so if RP wants to enable SPC for both get() and create(), then they can set a new RPID
Ian: How to use same credential for 1p login authentication?
John_Bradley: Could involve a change in the browser to recognize postfix
John_Bradley: As an RP if you want to use SPC in regular auth, then you will only get the 3p type (not a mix of 3p and 1p credentials)
smcgruer_[EST]: that is one of two reasons that I think we should not do a namespace.
… the first reason is the one John just cited
… second reason is the need to query credentials for their existence
… if we introduce a namespace to solve the first problem, we'd still need to keep the cache around
… to fix that, we'd need a platform level API
John_Bradley: What does "is valid" to you?
Stephen_McGruer: We have a conditional UI sort of behavior: if authenticator is available, do X; Otherwise do Y
<smcgruer_[EST]> https://
<smcgruer_[EST]> s/is authenticator is available/if credential is present for this authenticator/
John_Bradley: you can use credential management to find credentials based on their RPs. The biggest problem with credential management is that you need to do some sort of authentication for privacy reasons before you can get at the credentials.
… you can either do credential management or an allow list (with user presence = 0)
… the latter works for both platform and remote authenticators if you have the credential IDs
… more complicated on Windows
… that would work with namespaced credentials
Ian: What needs to change on an RP server?
JOhn_Bradley: Nothing should change for the 1p other than how to recognize the typed credentials.
John_Bradley: If we can flag credentials without touching RPID, then we can not touch WebAuthn at all.
… if we are not using RPID then "3p ok" is only necessary to be known by the SPC API.
Ian: How do we get the bit in the credential?
John_Bradley: A Webauthn extension.
<smcgruer_[EST]> 'A WebAuthn extension' is just the mechanism for a developer to say 'I want this to happen'. It is not the bit itself.
John_Bradley: Platforms would have to know how to set bit / or authenticator would have to do it.
John_Bradley: People expect to be using fields for different things. To be backwards compatible we need to step on somebody's usage of something (userid, Cred blob, something else)
<smcgruer_[EST]> But we don't *have* to be backwards compatible!
John_Bradley: ...there may be sensitivities about stepping on existing usage.
… if we want to use something other than the RPID to flag this.
John_Bradley: Having it's own data element ideal. But shy of that, re-using existing fields. If changes have to happen in the platform as opposed to the browser, the deployment lag for some platforms will need to be taken into consideration.
… one advantage of using the RPID is that could be manipulated by the browser and passed through the DLL.
Ian: Why would RP need RPID?
JohN_Bradley: RP doesn't read the credential.
Stephen: RP's can separate credentials if they want (via RPID)
John_Bradley: I'm ok with long term approach, as long as you understand the consequences.
Tim: +1 to doing this the "right way for the long term"
… John's right that the devil's in the details. But +1 to "doing it the right way."
Stephen: Credentials will work in short term in 3p context due to per-browser caching.
John_Bradley: You can go cross browser in 1p on the same device
<smcgruer_[EST]> I don't believe that's true due to https://
<smcgruer_[EST]> (Still need a cache to do conditional showing ==> still per-browser)
Tim: There are other use cases where an extra bit would be valuable (e.g., a "type" field for sync in to the cloud)
ACTION: Stephen to work with Ian to write this up
<Ian> Next meeting: 10 Jan