Ian: Any questions from WPWG meeting?
Tomasz: The important part from
our perspective is to be able to leverage SPC within the
payment handler
... how can we make the primitives invokable
independently
... the payment handler will support a URL-based PMI
... we'd like the PH to be able to trigger WebAuthn without the
PH having to open a window
... and to be able to leverage the additional data being
displayed by SPC
IJ: Is that last requirement a PSD2 requirement specifically?
Tomasz: PSD2 is a big component,
but also we just think it's a superior user experience
... one less click and one less window is a much better
experience.
<Gerhard_> +1
IJ: What about the idea of SPC registration on behalf of another party?
Tomasz: Starting question is
whether SRC system or issuer should be RP.
... but we can envision a scenario where the issuer registers
credentials _for_ the SRC system.
... so the issuer can nominate an alternative RP
... the alternative RP later does the validation (not the
issuer)
Ian: Has WebAuthn encountered this type of use case.
JeffH: There are use cases in
WebAuthn / proposals that sound like this.
... there are some privacy concerns potentially
IJ: Does the third party delegated authentication have traction at this time? (See previous slides from Dirk Balfanz about third party delegated authentication.)
JeffH: It is not actively under discussion. This kind of use case has the potential to push it to the foreground again.
IJ: Would the issuer credential need to be share with more than one SRC system?
Tomasz: I think it would not need to be shared with more than on SRC system.
clinton_: Is the mastercard
presentation available (from last week)?
... If the issuer is issuing for multiple SRC systems, would it
need to create multiple credentials?
tomasz: One could delegate for
each card separately.
... Is there a limit in the browser for number of credentials
enrolled for a user?
... would we run out of slots?
... is there a limit of WebAuthn credentials enrolled for a
given origin?
JeffH: There is not a limit in
the client platform.
... platform authenticators (e.g., phone or desktop), I would
not anticipate running out of storage
... on a roaming security key, there would ultimately be
storage limitations
... there were some behaviors that might limit keys for an
origin (in CTAP) but I believe we are relaxing those
constraints
... ultimately what an RP wants for a long-term happy path
(where the user re-authenticates)
... the relying party should have had the user register a
platform authenticator for that situation
... in the happy path future, that should be a discoverable
credential and it should "just work"
tomasz: There was a discussion about the challenge generated by the client platform. What is the status of that discussion?
Ian: I am aware of these issues in the SPC repo: issue 28 and issue 26
<scribe> ACTION: Ian to communicate this discussion to the SPC task force
Gerhard: We'd like to enable a
frictionless flow in association with SPC.
... a number of industry people I have spoken with have
indicated this is important to them.
... I am wondering whether the same SPC model could be used
with a credential that does not require a user gesture
(Summary)
- The RP would generate the key based on customer consent. They would then link to SPC in the same way that an existing WebAuthn credential could be bound.
- At transaction time, it's just SPC with a desire to have a frictionless flow:
- If one of the frictionless keys are on the browser, they would be used.
- If not, the browser would aim to use one of the Fido Keys from the list.
- If none, the same failback flow would execute for the current flow.
====
Gerhard: In other words, the
browser could start with frictionless (if that's expressed by
some parts), then WebAuthn, the fallback
... so the SPC could include a frictionless flow if the issuer
allows
IJ: Is key pair generated by browser or RP?
Gerhard: By the browser
IJ: How do you manage the privacy implications of that?
Gerhard: The user needs to
consent to the storage (like password storage)
... the RP cannot ask for a list of keys, the RP has to provide
a key
IJ: Who can call SPC with this key? Only the RP?
Gerhard: No, merchants could also
call it
... the merchant would not know about the credential id unless
it was given to them
IJ: How do you avoid an origin calling SPC silently to confirm usage of the key?
Gerhard: One way is to have the user explicitly consent to the first time the key is used by an origin other than the creating origin
Ian: And you could have a checkbox 'don't ask me again'
Gerhard: This would be useful in contexts where 2-factor authentication is not mandated
IJ: there has also been explicit instrument selection in some contexts.
Gerhard: Another perspective - the browser itself is treated like a possession factor
IJ: how do you see this fitting into the 3DS discussion?
Gerhard: I'm still a proponent of
being able to use the 3DS method URL to determine (by the
issuer) what's on the browser, and being able to instruct the
merchant what credentials are available. If that includes
frictionless credentials, the merchant could then include an
assertion in the AReq.
... there are two proposals on the table for how the issuer
gets info to the merchant (1) FReq or (2) method URL
IJ: Would decoupling help or hurt?
Gerhard: Probably hurt; would
require more state management
... I'm concerned about requiring more changes to 3DS due to
deployment
IJ: For more information on Gerhard's proposal, see his SPC issue 34 and WebAppSec issue
Not scheduled
IJ: Tomasz, do we need to revise the proposed architecture for SRC with PR API based on the Mastercard practical experience?
Tomasz: Yes
IJ: Do you think we need to work on a payment method definition for SRC?
Tomasz: I don't think we need to define a payment method under the W3C umbrella.
<scribe> ACTION: Ian to follow up with Tomasz on revisiting the proposal architecture for SRC with PR API.