Meeting minutes
Chrome SPC Origin trial end date
Mweksler: Airbnb and Adyen are going to do a pilot with SPC. Want to do this as part of the origin trial, and to see if we have any flexibility on the end date.
Stephen: The origin trial is from 91-93. I think this is through mid-September
… we extend origin trials for 2 reasons
… if there's a browser bug (invalidating the origin trial)
… more commonly, when partners need more time!
… sometimes we can extend 1 or more release cycles
mweksler: It would be great to chat with you more about the pilot idea. When would we need to request the extension and to whom?
Stephen: File the request with me
… how about aiming for mid-July? (But there is flexibility.)
michel: Noted!
User stories
Scope document and in particular pull request 60 which adds use stories, first draft.
1) Out of band enrollment
Stephen: +1 to this use case. Captures the important of "enrolling all your payment instruments"
2) In-transaction enrollment, authentication same merchant
3) Authentication different merchant
4) Enrollment for both payment authentication and account login
mweksler: The details are for discussion but the general idea is to do one-step login plus payment authentication
… it would be great if, during a guest checkout, the user pays and the merchant can use the authentication step both for payment and to create an account
Gerhard_: When I look at this use case from a banking perspective, we definitely see the use case.
… are you thinking about this from banking or merchant perspective?
mweksler: Merchant perspective. Want to use credentials for future login
… user perspective is "just authenticate once; allow multiple usage"
stephen: In the use case it talks about using this credential on a "different" merchant.
<Gerhard_> Just note Michel: This sounds more like Delegated Auth use-cases.
michel: I was not thinking about cross-merchant login
Ian: My understanding of the idea was that the issuer is the RP, and gives the merchant the info required to re-use the credential for login. But it's not clear how the merchant could trigger the authentication if they are not the RP (and login would happen outside of SPC).
<SameerT> +1 to what Gerhard mentioned, owner (RP) of the credentials will drive use-cases differently
smcgruer_[EST]: Sharing creds is a FIDO problem, not an SPC problem
5) Lower Friction
(Brought to us by Entersekt)
https://
Gerhard: Low friction to me is "transaction display but just "verify" button"
… you still get cryptographic signature
… this is not a frictionless flow (e.g., based on previous consent by the user)
… if there is a frictionless flow, then the signed data would need to say so
Ian: I think we've been talking about 3 levels:
1) display and user verification
… there is a multi-factor event
2) display and user presence
3) display and possession, but no user presence check
4) no display and no user presence check
(but previous consent)
JeffH: Silent authentication is not supported in WebAuthn but technically can be done at CTAP layer
… authenticators might have displays
… authenticators that are discrete components that have display in the authenticator boundary are rare.
mweksler: I suggest that if we feel like the use case is useful, we can still add it
… as a merchant, this is very useful (with user consent) to do something with silent authentication
… but we don't want to create a security hole
Action: To split these use cases into the 4 experiences we described here.
Regular meeting time
PROPOSED: Move this 30 mins to 1 hour every other week on thursday call
<Gerhard_> +1 for moving to WPWG group
<mweksler> +1 to move to an hour, -1 to 7 am pacific
Christian: We (EMVCo) have a conflict then
<Ian> No resolution yet to move the meeting, though we heard support by email from Anne Pouillard and from Gerhard here. Next meeting: 10 May