Meeting minutes
SRC and SPC
[Jonathan Grossar presentation. Note: the slides were edited slightly as a result of meeting discussion.]
Jonathan: Really great to have this discussion this week and to see Stripe results.
… and great to see lots of people interested in authentication
… auth + tokenization will improve approval rates
… happy to see use of FIDO for this
... FIDO can help in two ways with SRC (1) recognize returning consumer prior to display of card metadata (2) transaction authentication
… today we'll focus on the transaction authentication part of SRC and the use of SPC
… use cases and some initial requirement ideas
... Let's review the use case space for enrollment first, then transaction use cases.
… we imagine in most cases that the SRC System will be the Relying Party
… SPC credentials would be associated with a card after some ID&V process to the SRC system
… in a second use case, the issuing bank is the relying party. After ID & V, and with user consent, the bank can share the relevant credentials with the SRC System.
... in a third use cases, the merchant is the relying party. After ID&V with the bank, and with user consent, the merchant can share the relevant credentials with the SRC system
<Zakim> nicktr, you wanted to ask if the DCF *has* to be the network/SRC system or if it can be a third party?
nicktr: These are all great use cases. Is there a second flavor of the SRC-is-RP use case where some other entity (e.g., a wallet) is the RP on top of the SRC system?
Jonathan: Maybe there is a fourth use case. [But we don't spend time on it here.]
... Let's look at some flow diagrams where the SRC system validates the assertion (distinct from the 3DS flow)
… we need the browser to store the payment credential (and as we discussed, a FIDO credential could be updated to an SPC credential in the future).
... One question to explore; where does merchant identification come from in the transaction confirmation dialog (when there is a PSP, not the merchant, initiating the SPC request)
[Jonathan describes a flow where the SRC system stores the credential ids with cards, and provides nonce to SPC. And validates the assertion]
mhofman: When you say SRCi/DCF retrieves the card profile...how does it do that?
Jonathan: This happens via cookies today but that could change. We are not focused on that functionality today.
tomasz: After ID&V the SRCi / DPA can use an SDK to retrieve a profile
[Flow diagram walk through by Tomasz]
Tomasz: ID&V can happen in a variety of ways (out of scope here)
… the merchant loads the SRC SDK, which is used to get aggregated card data for display to the user.
… selection of the payment instrument happens within the merchant domain. [May be a future discussion for the WG as AdrianHB described on Monday]
… user selects a card
… SRC SDK reaches out to the SRC system to get a list of credential IDs and a FIDO challenge
… the SRC SDK then initiates SPC
… the browser looks for a matching payment credential.
… transaction confirmation dialog is displayed
… after authentication, the SRC SDK sends the assertion to the SRC system for validation
… checkout results returned
[SRC with SPC requirements slide]
Jonathan: Want to know whether the browser supports SPC
… (2) Non-RP origins can call FIDO and retrieve assertion data
… (3) At enrollment, RP creates FIDO credential needs to be able to store card metadata in the browser
… (4) At enrollment, need transaction confirmation dialog, first matching credential applied, with support for fallback URL if no matching credential id
… (5) Signed transaction data. Ideally the transaction confirmation dialog and ideally errors are harmonized across browsers.
... (6) FIDO challenge is not necessarily generated by the RP. In our use case, the SRC system (validator of the assertion) generates it
<Zakim> ChrisD_, you wanted to ask if the browser must support the SRC API or would this be merchant javascript that cycles through the list of potential FIDO credentials?
ChrisD: At the point where the browser requests authentication, is there an assumption that the browser has any "SRC capability"?
… or is this just vanilla SPC?
Jonathan: Vanilla.
Tomasz: In case SPC cannot be triggered and there is no URL provided, we want silent failure.
… to allow for graceful fallback
SameerT: In one of the flows we've talked about for 3DS is for the ACS to store a credential, and for the browser also to store them for matching.
Jonathan: Agree there are two authentication schemes possible: 3DS or SRC system
Tomasz: The list of credential ids could enable the browser to display stored instruments. But today we are only looking at flows that follow instrument selection.
… it's important to us to be able to pass a list of credential ids to SPC
... regarding steps 6 and 7 on the flow diagram...they are more or less equivalent to an AReq being used to get credential ids in the 3DS flows.
... and steps 12-13 are similar to the verification step of 3DS
… I think SPC should be network protocol agnostic, and this flow diagram shows we are able to do so
Ian: Do you need something besides an out-of-band agreement to share challenge?
Jonathan: The goal is not for the browser to generate the challenge.
… rather the SRC system would generate it and share as part of the data sent back to the party that calls SPC (along with credential ids)
Tomasz: we do not anticipate that SRC will forward assertions to issuers.
… SRC will validate the assertions. They may generate their own bespoke cryptogram. But does not mean that assertions will be forwarded to issuers.
... the party that validates the credential should generate the challenge, even if they do not "own" the credential.
Danyao: What is your though on payment handlers used for solutions?
Jonathan: The focus here is on authentication. We wanted to make sure we go into the details of the authentication use case by leveraging existing SRC implementations. We've not spent a lot of time on payment handler considerations.
Danyao: I ask because if you want to use SPC in a payment handler, that is likely to generate different requirements for the design/implementation
<Gerhard> +1 for SPC being able to be used within Payment Handler
Jonathan: We can leave open for now the question of SPC-in-payment-handlers
<Zakim> danyao, you wanted to ask about payment handlers
ChristianA: I think you mentioned that there are potentially 3 RPs. How does the relationship work if the SRC system is not the RP? How is data transported?
Jonathan: I think that will be out of scope for the Web API
ChristianA: I'm mostly curious about the merchant relationship. We can carry FIDO data in an AReq, but we don't have a mechanism to share the public key
… at the end of the day, it's the responsibility of the bank to ensure that SCA happens
Jonathan: The merchant is not required to be trusted; it's the SRC system that does so. I agree with you that more investigation is needed to ensure that merchant enrollment data is shared securely with the SRC system.
… but this model does not rely on the merchant to do the validation.
James: A card may be registered on multiple devices. Does that open a new tracking mechanism?
… that you can tell what devices the user has?
Tomasz: I don't think so because it is not done silently.
Jonathan: The credential id does not say what kind of device it is.
<Zakim> danyao, you wanted to clarify "ownership" vs. "verification"
Danyao: It seems like a critical question: "ownership" v. "verification". What does ownership mean?
Tomasz: The credentials are bound to the RP domain. That's what I think of as the "owner" of the credential.
… but then the public key can be shared with the SRC system, which can then use it to trigger SPC and then verify the assertion.
Ian: Are there WebAuthn terms we should use her for clarity?
John_Bradley: WebAuthn effectively enforces that "ownership" and "validation" are the same party.
… the SPC FIDO needs to include the RPID of the RP
… so we may need to consider how the credential id and RPID are passed to SPC
Jonathan: Does Chrome use RPID (of RP) during FIDO authentication?
Tomasz: In our flow, we can also pass the RPID information; that's unfortunately missing from our diagram.
John_Bradley: If you are sending a list of credential ids, you need to bind to a single RPID, and the authenticator needs to know the RPID
AdrianHB: For SPC, what I heard Danyao say yesterday is that, because there is some additional metadata, instead of providing the RPID, there is selection of a payment credential, and the BROWSER provides the correct RPID to the authenticator
… the browser knows "this credential id is associated with this RPID"
Danyao: I think so. Our intent was that the caller does not need to know a lot of detailed parameters.
btidor: I think there's one thing that's different in the pilot. We have the list of credential IDs...in the pilot we used "SPC instrument IDs" and the browser has in persistent storage information about that ... and can look up RPID and other private metadata and credential ids
tomasz: That's what I wanted to say. If we could have some kind of indirection that is not the credential id itself but is more about the "stored metadata" that would be even better.
<AdrianHB> +1
<AdrianHB> We do need that concept validated by WebAuthn folks for possible security or privacy issues
Ian: We might be able to use an indirection for even more privacy (e.g., origin-bound opaque identifiers all of which are available in a browser-stored lookup table)
John_Bradley: Down side of storing in the browser is per-browser enrollment
btidor: Relates to roaming authenticators....
John_Bradley: But even with platform authenticators, I have lots of browsers and would have to enroll multiple times
btidor: Could be simplified at OS level perhaps
John_Bradley: There might be some possibility with Large Blob.
… could store in a browser-portable way to reduce enrollment overhead
Manoj: During the enrollment flow, can the credential be shared across payment instruments?
Jonathan: The consumer is authenticated for a specific instrument.
… if you have several cards with the same bank, and you enroll them all with SRC, the bank might choose to reuse the Payment / FIDO Credential with the SRC system.
Jonathan: Thanks all!
WebAuthentication WG update
<AdrianHB> If the same Relying Party enrolls multiple payment instruments in the same browser it may choose to use a single PublicKeyCredential
IJ: Please tell us what SPC evokes for you, notably around silent auth.
Tony: We are wrapping up Web Authentication Level 2. We are waiting some test coverage that needs to be explained.
… the two platforms that have implemented are Windows and Google. They share the same code base. We want to prove that a common code base constitutes two distinct implementations
... We hope to get Level 2 to Rec in a couple of weeks. Then we will recharter to work on Level 3
… some of the things coming in Level 2:
* Enterprise attestations
* Cross-origin iframe get()
* Discoverable credentials
* Large Blob
* App ID exclusion
Tony: In Level 3, we are going to cover some new things in the charter
… we plan to take on some topics like possibly new crypto agility
… some metrics generation
… backup and recovery
… multiple keys...which might be a solution for backup and recovery
… not sure what (if anything) is needed for payments
… but the charter will support that work.
… our target for level 3 is probably about a year from now
Ian: What is deployment of Level 2 today?
Tony: I believe Google has implemented Level 2 features. Edge has picked them up from chromium, but they also have to add support onto Windows (Hello).
… I am not sure about status on WebKit
… nor about Mozilla status
… regarding authenticators, others can speak for their support.
John_Bradley: It's useful to think of this as 2 pieces: WebAuthn and CTAP
… the WebAuthn API L2 is available in Edge and Chrome and is pretty complete.
… on Windows, WebAuthn.dll is in the process of being updated to support new CTAP that matches Level 2 features
… there are hardware keys that support CTAP 2.1
… until CTAP 2.1 is formally approved by FIDO we cannot make them available.
... Look for new keys in June time frame
... For resident credentials ("discoverable credentials") there are two things: Cred Blob and Large Blob. Intended originally for certificate storage for SSH deployments.
… but they could in principle be used for other deployments.
… those places might be possible for storing additional metadata for a Payment Credential
Tony: So the RP should push opaque data to the authenticator
… that would facilitate portability across browsers.
John_Bradley: In SSH use cases there may not be a browser, so needed some more storage
… in the payments use case we might be able to use this to enable the user not to be forced to recreate every payment credential in every browser.
IJ: what about in SPC having "no presence check"?
John: That ability is in CTAP 2.0 but WebAuthn does not use it.
… platform authenticators may have a hard time handing such a request, depending on the platform integration.
… this is supported by all the roaming authenticators.
SameerT: Can you say more about discoverable credentials?
John_Bradley: You make a request with no "allow list" and the browser will present a "pick list" to the user to pick one, which is given to the RP
Ian: Is that from credential management API?
John_Bradley: It's from WebAuthn
Ian: Could that be used for instrument selection?
John_Bradley: Chrome and Edge have implemented one. Safari has implemented one. There might be some differences; not sure how closely related they are from a spec POV. But perhaps some of the implementation could be reused. Depends on the implementation of the chooser whether they could extend to instruments.
… there is a chooser everywhere but Android for discoverable credentials.
… the anticipated use case is "passwordless flow". You see a list of identities and pick one to log in
<Zakim> AdrianHB, you wanted to ask what is required to invoke this flow?
John_Bradley: The browser formulates a list of credentials for the RP by polling authenticators, prompts the user, and the user picks an identity
AdrianHB: What are the prerequisites for that flow? Is it multiple credentials for the same origin of the RP?
John_Bradley: Yes
… and works across browsers...so you see registered credentials first time you encounter a new browser.
… on enrollment user can say whether resident credential is preferred, required, ...
… we are now calling them "Discoverable Credentials" now
… in the case of 0 credentials, there is notification to the user (but no action)
… in the case of 1 credential, there is still a user gesture
… in the case of > 1, there is a user selection
<AdrianHB> ian: if we wanted to sub-class PublicKeyCredential this would still work?
John_Bradley: The user id could also be used for display that could go back to the RP. This could be used for card instrument data
<AdrianHB> ian: I think what's missing is an instrument identifier
<AdrianHB> ... if you return something to the merchant you want it to be different for each merchant
John_Bradley: Username etc. is not returned to the RP...just displayed to the user
… things that could come back to the RP are: (1) user id (2) cred blob (3) large blob
… so there are some arbitrary things that could to back to RP in assertion and some things that are not sent back
Gavin: Does this help us with the identifying problem with cookies going away?
<AdrianHB> ian: what other storage mechanisms could be used to get a user id in a 3rd party context
John_Bradley: You can get the identifier, but only after a FIDO authentication.
… given that you have additional information to store with resident credentials, you could decide that for payment credentials there was structured information within that
… the instrument type could be stored in the user id...and SPC could let you say "Give me all the PSD2 credentials" or whatever structured information you have. In theory you could get the browser to do some filtering based on creation-time info
Ian: What about a credential picker for SRC identity?
Gavin: We should explore further the credential management API for identity management
John_Bradley: In Level 2, merchant can open an iframe to the bank and do a get() flow in an iframe. But it would require that the RP does the request and verification.
btidor: We should discuss whether we should bring @@ into SPC
<AdrianHB> +1 to exploring use of discoverable credentials for SPC
SameerT: If the issuer could access credential from 3rd party iframe to do verification, we'd like to learn more about that.
John_Bradley: In Level 2 you can do the verification in the iframe. (but not the credential creation)
SameerT: So credential credential happens in a 1p context after redirect?
John_Bradley: Yes, you can redirect for creation and use it in 3p iframe.
Sameer: Today in 3DS flows, the RP or the issuer or ACS collects a lot of data.
John_Bradley: You can use discoverable credentials and user chooses one. Web Authn does not have a way to say "give me all the credentials for all the RPIDs"
… in SPC we'd have to figure out how to scope that in some way
Sameer: My question is "is there no user action"?
… is there a discoverable credential mechanism without a user action?
John_Bradley: No, that's not in Level 2 and probably won't be in Level 3
... Tony mentioned something about the non-modal dialog to get that sort of effect: the RP would trigger the browser "if there are any credentials for this RPID challenge the user, otherwise don't show the dialog"
… so the RP doesn't find out what credentials are in the browser, but the user can select one to log in.
btidor: I think in 3DS we already have the card number, so the issuer knows which credentials to give to the browser
Misc and wrap-up
[NickTR summarizes the meeting]
NickTR: Next steps involve this kind of work -- what gaps are needed in any of the specifications?
... It's been a successful and engaging 4 days. Thanks to all the presenters!
… it feels like we have an idea that (through trials) delivers benefits to users. We are looking hard at privacy and security considerations
AdrianHB: I'm excited to kick off the SPC task force
… I think instrument selection will have a strong impact on the SPC design but we'll figure that out.
<nicktr> ian: next steps - we'll set up a task force - regular meeting, github repo
<nicktr> ...there may be other deliverables like implementation guides, FAQs, explainers as well as a spec
<nicktr> ...the next meeting is 15th April where we will talk about i18n of Payment Request
<nicktr> ian: where are we on Payment Request v1?
<nicktr> ...we had a patent advisory group that closed
<nicktr> ...we have a privacy issue to resolve
<nicktr> ...we need to close out the internationalisation issues
<nicktr> ...then we will be done
<benoit_> thanks to all who presented... amazing updates
NickTR: Thanks to all for doing the work, presenting, attending, etc.
Please go back into your organizations and talk up SPC
… this is for me a real opportunity to shift the needle for multiple payment methods...but there's lots of work to do. If you think there's something here please rustle up some engineering resources.
<AdrianHB> +1