Meeting minutes
Welcome
Scope
Q. Should frictionless (data-based risk assessment) be part of SPC?
AdrianHB: We want an authentication API
… the back end can be "anything"; what authentication means is context-specific.
… eg., I found a cookie and I'm satisfied
… or "I have a FIDO authenticator and get a signed credential for transaction confirmation"
Gerhard: I think we need to be careful about scope
… 2 factor
… 1 factor
… risk based
… the moment you say "how is the risk based " done
… or how is 2-factor achieved?
… it explode
… I think we should pick 1 or 2 or at most 5 flows and try to optimize those
… we can stick to use cases ; and give optionality but within limits
smcgruer_[EST]: +1 to Gerhard. We are interested in SPC-as-it-is...we are worried about the overall user journey
… I think we should remain tightly scoped in v1
<Gerhard> +1 to that.
AdrianHB: I don't want SPC to assume only fido-based auth
AdrianHB: The API should say "I am authenticating the payer" but what happens should not only be hardware-based crypto
AdrianHB: ...e.g., software crypto should be an option
… so there's an API and a user interaction
Gerhard: +1 to AHB. Risk-based auth should support some options
back bt
AdrianHB: So perhaps in scope is:
1) Authentication API
2) Merchant calls API
3) Transaction confirmation piece (optional?)
btidor: I can imagine zero-interaction flows.
… so maybe the ultimate definition is the "payment assertion" format.
<Gerhard> Proposal: "A Consent Page" with customer ability to 'skip-the-sheet' based on consent. But it needs 'proof' since it crosses domain'
btidor: Either a hardware token generates the format, or a software authenticator generates the format
Rolf: What is the unique value proposition of SPC? I can do a lot of things with iframes, JS, etc.
… I agree it is what btidor described:
1) Browser display not subject to x-site attacks
2) Assertion format
… how the user was verified plays a secondary role
AdrianHB: I would like us to consider the possibility that the "UI" is not per-transaction.
… user should be able to pre-load consent.
<btidor> +1
<Gerhard> +1
mweksler: Regarding priorities, Adrian's comment about pre-load consent is a lower priority.
… I'd like to define an MVP
… once we have that, it will be easier to take the next step, and I agree with Adrian's point
<smcgruer_[EST]> +1
<AdrianHB> Proposal: Assertion format as priority 1.
SameerT: +1 to Michel. Issuers can already do some things today. I would say "look at what you have in SPC today and don't re-invent things people can already do."
<AdrianHB> That will include data on how the assertion was generated
<AdrianHB> With scope to evolve
SameerT: So define SPC as a bundle (e.g., data, modal, FIDO) that will help
<AdrianHB> (assumption is that assertion is a public key signature over tx data)
Gerhard: One way we can perhaps do that is to not define certain flows.
… we could require explicit consent and define the assertion
… and allow the browser to drive the UX further if they deem it of value of users
Rolf: Two more extension proposals I'd like to mention
1) Especially where mobile phone is used as an authenticator, it would be helpful if the authenticator itself could be the entity that displays the details, and ties it to the assertion
… from a security perspective this is yet another level
<mweksler> +1
<smcgruer_[EST]> +1 (but does the spec need to say that?)
Rolf: 2) This is for me not only about payments. E.g., "Do you want to share this data with a hospital?"
Rolf: ...the user agrees to a certain "transaction"...this is unsolved in the browser world...x-site scripting is a major attack vector
… we'd need some flexibility to set the "CONTEXT"
… whether payment or other data sharing
… the high-security pieces of these use cases would be very relevant
<Zakim> AdrianHB, you wanted to comment on non-payment use cases
AdrianHB: I am a big advocate of the other use cases. One piece of this is important is that these are not "open data fields"
… so other use cases may need strong structure around the data
… my guess is that could enable more traction.
<Zakim> smcgruer_[EST], you wanted to note we have 5 minutes left and I'd like to discuss next steps
Rolf: Session auth would be out of scope
… logged in use case
… but there are other non-payment transactions and that's all I had in mind
mweksler: I like the suggestion re: authenticator display
… however, I think auth display is lower priority
… I think non-payments use cases should be out of scope
<mweksler> I can start the doc
<Ian> Next Meeting: 26 April. I expect we'll meet weekly while we get up to speed.
Action: Michel to work with Ian on the beginnings of a scoping / requirements doc
Stephen: We want to be sure to get to the following deliverables quickly:
a) User journeys
b) Spec
c) FAQ