Meeting minutes
Early draft of SPC API
smcgruer_[EST]: There is a first draft link of the spec. It does 2 things:
1) Somewhat encodes the origin trial where SPC is a payment method
… one discussion is "don't attach this to PR API"
2) The other part of the spec is about how to connect to the WebAuthn backend
… so the spec defines an extension to WebAuthn
… these changes (from "payment credential" to WebAuthn extension) came from discussions internally with WebAuthn folks
smcgruer_[EST]: We are moving the Chrome code in the direction described by the specification.
… work still to do on use cases, security/privacy sections
… one challenge is to specify what is shown to the user since usually specs don't describe UX
… so this spec is unusual in that regard.
IJ: Any hot topics where you need input?
smcgruer_[EST]: One big issue I just wrote up
<Zakim> nicktr, you wanted to ask how webauthn handles the question of ui and to ask about being a payment method
nicktr: A few things struck me as I read through the spec
… you mention the challenge of how/whether to define the UX
… how does WebAuthn address that challenge?
smcgruer_[EST]: I believe the WebAuthn spec takes a hands-off approach
… WebAuthn slightly gets away with this because much of the UX is from the platform
... I think we can take a similar approach of saying that the user agent will communicate the following information to the user...
Nick: It does seem that UI guidance is minimal in WebAuthn. Second part of my question, regarding SPC-as-Payment method...if we are using SPC as the payment method, how does that interact with calls where multiple payment methods are referenced?
[Ian thinks the answer is: if you want to use PR API for payment credentials, do that first, then call PR API for SPC...and without other payment method ids..and if this is accurate, we should say this in the spec.]
smcgruer_[EST]: I agree SPC is not a payment method. SPC assumes the payment instrument has been selected
JeanLuc: Regarding the additional data dictionary...I see you have amount (for dynamic linking)
… can we also add a timestamp?
… from the RP
… for 3DS, for example, let's assume that the ACS is the RP
… the banks may wish to know how much time has elapsed between when credential requested and when authentication happened
… subscription use case may also be interesting
<Gerhard> +1 for timestamp.
<jonathan> +1
smcgruer_[EST]: I would like to meet industry needs but also minimize features.
… is there a concrete use cases for embedding the time stamp?
JeanLuc: Right, the same comes from the RP.
smcgruer_[EST]: You can put time stamp in the challenge
Gerhard: We need something to prevent replay attack.
smcgruer_[EST]: We already include a field for random information to prevent replay attack. You can encode whatever you want in the challenge, and then extract it if you want.
JeanLuc: Time stamp may be useful in risk assessment.
smcgruer_[EST]: Please do file a GitHub issue with use cases described.
… RP controls the challenge. You can record time on RP server; and compare when you get assertion back...don't need SPC feature
Gerhard: If I look at Example 2...the instrument object
… if the instrument information is presented at auth-only, it might be useful to provide a reference in the signature provided by the RP
… like an instrument identifier that can be signed
smcgruer_[EST]: the reference doesn't prove anything.
… the browser doesn't do anything but sign it
… the display name and icon are important for dynamic linking
IJ: How do people speak to the "if you trust the browser" comment?
[IJ mentions WPSIG conversation about trusting the browser]
Ian: We may want a FAQ outside the spec
Nick: I don't think "who calls the API" is material to the "trust the browser" issue
clinton: From my perspective, any one of these components solves a small segment of a big problem.
… the browser's security properties doesn't seem to be relevant;
… is it a browser issue or a broader "end-to-end system" issue so examined per payment method?
Ian: I think questions are on (1) how to trust browser displays properly what is provided in the API and (2) CTAP implementation quality
Werner: I noticed currency amount in SPC...in 3DS there are a few other things that are required.
… does that go here?
Ian: SPC will be designed to be integrated into a variety of end-to-end systems, so the data requirements should be minimal to allow reuse. I think the extra fields will be carried by 3DS; see the EMVCo 3DS WG discussions for more details.
Action: Ian to raise an issue about localizing browser UX cf PR API
Ian: I will bring the question of "when to start the Call for Consensus to make SPC a FPWD" to the SPC task force.
Next meeting
5 August