Meeting minutes
Charter update
Ian: One more week for AC reviews; please have your organization respond. I have reached out to two organizations that have indicated they want changes or are not supportive. I will keep you posted.
Next meeting
17 July
SPC issues
Ian: To help build shared understanding around a roadmap for v1 of SPC (assuming we get a second implementation, e.g., a polyfill on iOS) I would like to start labeling issues and working through ones deemed important for v1. Here's a draft categorization scheme of SPC issues:
====
* API features (#56, #65, #157, #274, #287, #288, #290, #300)
* Dependency on Web Authentication (#12, #98, #124, #174, #187, #253, #260, #273, #278, #299)
* New use cases (#34, #185, #186, #276)
* Detailed specification issues (#269, #302)
* Other (#266)
====
IJ: Would something like this be helpful?
Bjorn: Good first step
Doug: Yes
ACTION: Ian to start to label SPC issues in terms of topics
w3c/
IJ: If passkey without extension is used, will they get a BBK at authentication time?
Slobodan: Yes
Ian: That raises the 2-step-up issue
John: But that's up to the RP; they only step up if they care.
… you can do trust on first use with other analytics
John: It's up to the bank to decide what they want to do with the credential.
Gerhard; The BBK might be extra in some places, but might be considered more important from a regulatory perspective in Europe.
John: Banks are going to be prepared to do some sort of step-up anyway.
… you can't assume there will only be one BBK ever
<smcgruer_[EST]> +1
(We discuss the function of the "cross origin" flag)
John: Reiterating...we conflate payments and cross-origin.
Stephen: John is correct; the web authentication extension is called "payment" which has a boolean that says 'for payments". But at the FIDO CTAP level, there's only a "3p usage" bit, but not a boolean for payments.
… today those are conflated.
… on certain platforms, they are also used for "can you do SPC at all"?
Stephen: If we introduce a bit that is just about "payments" (not 3p usage) that implies that a credential without that bit should not be allowed with SPC.
… that means there's not path for an RP to use a passkey without the bit with SPC.
… today we are in a split world. But if move to a world that you have to opt-in to SPC when you create your passkey, that will change what can be done.
John: And it would mean breaking CTAP.
… so for hybrid, you are out of luck
John: We had originally imagined that all credentials would be usable within SPC, and only the ones with the CTAP bit would be usable by 3ps.
Gerhard: The bank can still decide whether it accepts the credential.
smcgruer_[EST]: To my knowledge, the original motivation for the 3p bit being opt-in was that RPs (not payment RPs) that they didn't want their credentials being used with SPC EVEN IF you can't do anything with them.
… so we made the CTAP bit opt-in
… the hope (long ago) was that the credential listing API make it possible to do this in a 1p context. (Immediate mediation)
… secondly, we assumed platform authenticators would be able to store the CTAP bit.
… but the world we are currently in is complicated:
* On Android google password manager offers both, but
* The General password provider ecosystem does not.
John: That's because they haven't been able to use the 3p bit
smcgruer_[EST]: Yes, for the bit, but the other bit is the credential liaising API.
Rene: I think it's more the architecture on Android rather than permissions.
John: On Windows, there is an API just for doing this. On Android, need to discuss getting the list both for autofill and SPC.
… it sounds like there's a general Android API issue
… and then the payment bit would ride along with that solution.
smcgruer_[EST]: Windows Hello today does have credential listing API and 3p bit; it's up to us to use them.
<smcgruer_[EST]> ... but in the near future they're adding third-party payment providers, and we don't know if they will support credential listing and 3p bit
John: At the WebAuthn layer, the bit controls whether a credential is available to a 3p
Ian: Question is whether SPC supports 1p usage of credentials without payment extension set.
(We look in detail at merchant-initiated and issuer-initiated SPC with credentials with/without bit set)
Gerhard: Bank has a 2x2 matrix:
* Can it be used for payments?
* Can it be used cross origin?
Ian propose:
* SPC supports credentials without bit set by RPs
* When no bit set, BBK is returned only at authentication time (not registration time)
<smcgruer_[EST]> https://
smcgruer_[EST]: We need the credential listing list API for that to work.
smcgruer_[EST]: We need to determine whether a credential is immediately available.
Rene: The current listing Apis at least on Android leave the decision of showing credentials to the authenticator. Today all these use cases work for 1p (even if the payment bit is not passed)
… theoretically we could support SPC today without much work if it's a 1p flow
Rene: ...the issue for us would be cross origin
smcgruer_[EST]: I do not know the cred management ecosystem in detail. But there are two steps in SPC (1) Are any credentials passed in available? (2) Signing
… the first step is where SPC decides to take the user through authentication flow or the fallback flow.
… my understanding is that in today's credential management ecosystem, passkey providers might not respond even if they have the credential.
Rene: That's part of the larger discussion. When cred man receives a request, it will fire it off to all the configured passkey providers (including built-in) and each authenticator decides which credentials it has stored that meet the requirements of that authentication request.
… in the case for SPC where you are listing the credentials, it's essentially the same thing. We will see the WebAuthn request (depending on 1p, bit set, etc.).
… and we can return credential id and metadata.
… and the browser would see that list and present it.
John: The problem is that SPC kind of developed without a deep understanding of how the API was implemented on iOS and Android
… in theory what should be happening is part of the "do you have credential for my needs?" request that goes to the passkey provider
… the Web Authn client knows whether this is a cross-origin context.
… the way it works on Windows (for autofill UX)...you have webauthn.dll give back a list of credentials for the RPID.
… since SPC is currently bypassing (I think) the Windows API...Chrome is likely skipping the step the other passkey providers are doing (a pre-query)
… we'd have to adjust the impedance mismatch between the way SPC is currently implemented on Android and how the passkey providers are implemented on Android.
… if we were to do that, the passkey providers would need to understand the extension, be able to set the bit, and do the computation
… the current flow is (I think): SPC gets list of all credentials, and the browser does the filtering.
… but the way Android and iOS APIs work, some of the filtering logic is done by the passkey providers.
… from a privacy POV you probably want the authenticator doing the filtering.
John: Immediate mediation is also coming up
… assuming it happens, it will have the same problem as SPC
smcgruer_[EST]: You can have an SPC payment extension "give me a BBK even if payment bit is not sent"
… this would be "normal passkey but BBK set at registration time" option.
Ian: And that key would only be available through SPC and ONLY through 1p use cases.
<smcgruer_[EST]> { payment: { isPayment: true, forThirdPartyPayment: false } }
Rene: My understanding is that something like that would only work in a 1p case (issuer-initiated)
<smcgruer_[EST]> this would give you a 'normal' WebAuthn credential, but with a BBK created+associated+passed-back
Rene: I suggest Chrome talk to the Android Team!