RE: SPC Scope.md Comments

Hi Stephen,

Thanks. Comments below in blue to make tracking easier.

> Add Secure Remote Commerce (ClickToPay) to this list

This may come from my general caution around this section or at least how it's named ('Protocols and Systems Helping to Guide Requirements'), but do you propose adding SRC here because you believe it represents a use-case that SPC should support (a proxy to 'digital wallets'?), or because it explicitly has representatives in the SPC task force and/or WPWG?

Secure Remote Commerce (EMVCo standard) introduces a new 'actor' in between the merchant and Account Provider (Bank) during check-out. I foresee that SPC may therefore in future be invoked by the SRC System with the Issuer as the relying party,
(See my longer note below for some more context )

> Browser Behaviour / Enrollment
> Browser Behaviour / Transaction

I think these are fantastic questions, but I don't think we have an answer to them yet to put in the scope document. Perhaps just adding a TODO is enough, not sure.

Alternatively I can make some suggestions here, and then we can mark them as 'for review'.

> In authentication and Enrollment, we should Indicate the extra auth step for Fido Auth

Can you clarify 'the extra auth step'?

I was referring to the browser invoking the Fido Authenticator (outside of the browser) that enables a selection of fido tokens, and then the request for the user to authenticate.
(If we were to allow the browser based consent we would have a flow where the user would not be required to fulfil this extra step.  Important the account provider should decide what level of authentication is required.)

> Should we be specific about the fields and structure of the cryptogram?

I would suggest that we do make a recommendation, since this needs to be consistent across different browsers for issuers and merchants to adopt this.

> If SPC runs inside Iframes, which permissions will be required to allow this?

I think this level of detail for both of these belong in the explainer (and eventually the spec), not the scope document?

Fair point. Perhaps we should just then mention that permissions would control this.

> Preferences
> Who determines what is allowed? Or is that browser & customer permission?
> If we have preferences the assertion should include it?

I'm not really sure what these comments mean; can you elaborate?

This links into
* Requirements & Design Considerations \ General and the sentence
  "The API should support different sources of preferences"

> Who determines what is allowed? Or is that browser & customer permission?
It hints that various preferences from stakeholders such as merchants and Users and relying parties should be supported.
Just wanted to indicate that preferences does have security and other implications. E.g. If merchants could state their preferences they may want frictionless flows for every transaction. But this might not be desirable for every transaction. So we need to ensure we're clear about how preferences are implemented (how are conflicting preferences resolved)
> If we have preferences the assertion should include it?
Let's say a Relying party indicates they are ok with a non-fido-authenticated flow, and the merchant is also fine with it, then our 'assertion/signature' should include these preferences were used, by defining them as fields in the cryptographic assertion. E.g. a field in that assertion should state that the user did not perform fido authentication.

----
Some extra notes around how SPC enables roles to be mixed. (and this is why SRC should probably be referenced)

Perhaps for explanation, it might be useful to understand the following context as well:

In SPC we're talking about payment consent.  This touches on two topics

  *   Who shows the consent?
  *   Which Identity is used to gather that consent (The relying party, where is the user registered)
We have two traditional participants

  *   Merchant
  *   Account Provider (aka Bank or Wallet provider or Card Issuer)

Traditionally the identity and consent pieces had to both be done by the Relying party (e.g. via Oauth2 in Open Banking, and via 3D Secure in eCommerce card payments).

So traditionally, the identity and consent pieces was done by the Account Provider. Payment handlers would redirect to the Account provider for this purpose.
In Delegated Auth (rolling out in Europe) the identity and consent sits with in the Merchant domain (they are the relying party and the party that gets consent).

SPC allows the separation of these two. So we're enabling the Merchant to do the consent with an identity belonging to the Account Provider. In my view, this is what brings the excitement.

Now, Secure Remote Commerce introduces in a new participant into the payment ecosystem. The Card Network (aka SRC System). They also setup and manage an identity and have a process for consent. And they could use SPC to perform consent while using an Account Provider/Bank identity.

Hope that helps.
Gerhard