Integrating SPC with Open Banking

[cyberphone]

Discussion for the coming SPC specification.

Integrating SPC with Open Banking is a complex matter. The most intricate part of the puzzle is where exactly a PISP fits into such a schema. Dirk Balfanz's presentation highlights the problem:
https://www.w3.org/2020/02/3p-creds-20200219.pdf#page=5
In this slide the User is supposed to authorize a payment to his/her PISP. This introduces several obstacles:

• The PISP concept (unlike AISP) does not presume that the User is known by the PISP making "Your PISP" a less useful term
• The interest by Merchants and Banks adding a new User-facing service is low

Chris Wood's recent F2F presentation shows the consequences:
https://docs.google.com/document/d/1qjBPa6l0EM9A3sLl9neccq_8UPHe90jXTGXqcbge2vQ

---

Note that this example concentrates on Confidential Clients, but it could equally apply to Public Clients with the right tweaks.

The initial consent will incorporate the SPC Credential ID as an additional property, named SPCCredentialId:_

{
  "Data": {
    "ReadRefundAccount": "Yes",
    "Initiation": {
      "InstructionIdentification": "ACME412",
      "EndToEndIdentification": "FRESCO.21302.GFX.20",
      "InstructedAmount": {
        "Amount": "99.99",
        "Currency": "GBP"
      },
      "CreditorAccount": {
        "SchemeName": "UK.OBIE.SortCodeAccountNumber",
        "Identification": "08080021325698",
        "Name": "ACME Inc"
      },
      "RemittanceInformation": {
        "Reference": "FRESCO-101",
        "Unstructured": "Internal ops code 5120101"
      }
    },
    "SCASupportData": {
      "SPCCredentialId": "8bbea266-921b-4015-9bc9-a5017b310b54"
    }
  },
  "Risk": {
    "PaymentContextCode": "EcommerceServices",
    "MerchantCategoryCode": "5967",
    "MerchantCustomerIdentification": "053598653254"
  }
}

On success the bank will return an identifier for the newly created Consent entity in the property ConsentId:

{
  "Data": {
    "ConsentId": "f73ff601-e969-43d1-961e-fdfcbd1b170d",
    "Status": "AwaitingAuthorisation",
    "CreationDateTime": "2017-06-05T15:15:13+00:00",
    "StatusUpdateDateTime": "2017-06-05T15:15:13+00:00",
    "ReadRefundAccount": "Yes",
    "Initiation": {
      "InstructionIdentification": "ACME412",
      "EndToEndIdentification": "FRESCO.21302.GFX.20",
      "InstructedAmount": {
        "Amount": "99.99",
        "Currency": "GBP"
      },
      "CreditorAccount": {
        "SchemeName": "UK.OBIE.SortCodeAccountNumber",
        "Identification": "08080021325698",
        "Name": "ACME Inc"
      },
      "RemittanceInformation": {
        "Reference": "FRESCO-101",
        "Unstructured": "Internal ops code 5120101"
      }
    },
    "SCASupportData": {
      "SPCCredentialId": "8bbea266-921b-4015-9bc9-a5017b310b54"
    }
  },
  "Risk": {
    "PaymentContextCode": "EcommerceServices",
    "MerchantCategoryCode": "5967",
    "MerchantCustomerIdentification": "053598653254"
  },
  "Links": {
    "Self": "https://api.alphabank.com/open-banking/v3.1/pisp/domestic-payment-consents/58923"
  },
  "Meta": {}
}

The Relying Party will use this value to populate the challenge property of the PaymentRequest call. The following snippet uses the existing example from the SPC proposal, amended to include the challenge property:

const securePaymentConfirmationRequest = {
  action: 'authenticate',
  challenge: 'f73ff601-e969-43d1-961e-fdfcbd1b170d',
  credentialIds: [Uint8Array.from(atob('8bbea266-921b-4015-9bc9-a5017b310b54'), c => c.charCodeAt(0))],
  networkData,
  timeout,
  fallbackUrl: "https://fallback.example/url"
};

const request = new PaymentRequest([{
    supportedMethods: 'secure-payment-confirmation',
    data: securePaymentConfirmationRequest
  }],
  {
    total: {
      label: 'total', 
      amount: {
        currency: 'GBP', 
        value: '99.99'
      }
    }
  });
const response = await request.show();
await response.complete('success');

Once the request is made and an Authentication Assertion successfully elicited by the Payment Handler it is sent to the bank using an authentication flow supported under FAPI

---

ALTERNATIVE

By putting the PISP in the same position as a payment gateway, none of the peculiarities of Open Banking payments need to trickle down to the User layer (and SPC), giving a simpler solution and as well as a better UX. The impact on Open Banking APIs would be marginal; the big job is the unavoidable Access Server/FIDO which in all variants becomes a special purpose system with its own API.

@danyao

[SensibleWood]

@cyberphone

The PISP concept (unlike AISP) does not presume that the User is known by the PISP making "Your PISP" a less useful term

Under PSD2 I don't believe this is true. The PISP is the regulated entity and the legal contract is between the PSU and PISP. It therefore not only presume, in relies absolutely on the PSU and PISP knowing each other.

[cyberphone]

@SensibleWood This sounds a bit strange. A user has no way of selecting "Your PISP"; it is done by Merchant who have a commercial contract with the PISP. The user (PSU) is usually anonymous with respect to the PISP.

May I ask how and where the PISP would manifest itself in your proposal? Does it presume PISP login as well?

[SensibleWood]

@cyberphone in the paper I wrote there is no concept of "your PISP" so I find it strange you have read this from the paper.

I dispute what you say when you consider PSD2. The PSU will absolutely know - or be made aware of - who the PISP is as there are obligations the PISP has to fulfil. For example, look at the UK open banking customer experience guidelines: https://standards.openbanking.org.uk/customer-experience-guidelines/pis-core-journeys/single-domestic-payments-acc-selection-pisp/latest/ PISP splattered all over it.

As far as PSD2 is concerned there is no "putting the PISP in the same position as a payment gateway" as that is simply not possible in the construct of the regulations and, for that matter the implementation in most territories. I get the merits from the perspective of a ubiquitous, one-size-fits-all solution but that ain't going to cut it when it comes to working in regulated markets like the EU. SPC must make accommodations for these facts otherwise it is less likely to succeed as a proposal.

[cyberphone]

@SensibleWood There is indeed no "Your PISP" in your paper but from what you write there must be something of that kind, and I'm curious to know how and where in an SPC context. In the sequence diagram you make Merchant=PISP which hides the rather awkward "Ménage à trois" I'm referring to.

FWIW, I was recently a member of an Ad-hoc WG "to make payments better" associated with the Berlin Group NextGenPSD2 effort. One the proposals which nobody objected to was based on existing EMV terminals and cards used in a PISP/GW scenario. I believe the resulting standard proposal (Signed Payment Request) is still under serious consideration.

I will perform some private research on this topic.

[ianbjacobs]

Closing this for now. I anticipate we will open more specific issues once we work more closely on integration of SPC into particular open banking rails.

[janaka]

Hi all, wondering what the latest status is on open banking integration? Issues #185 and #186 seem to be it? any other issues or places to follow progress?

[ianbjacobs]

@janaka, thanks for checking in. We continue to have conversations with our open banking colleagues (e.g., Berlin Group) about integration of SPC. I don't have any pointers to concrete change requests at this time.

[SensibleWood]

Hi all, wondering what the latest status is on open banking integration? Issues #185 and #186 seem to be it? any other issues or places to follow progress?

Hello @janaka. I think the key to SPC adoption in open banking largely lays in the standards that implement FAPI - UK, CDR, Brazil, etc. - creating a profile that allows the Payment Assertion to be sent to the ASPSP under the covers of an OpenID Connect flow. In my head the flow looks like this:

• SPC Relying Party contacts ASPSP for challenge to seed SPC. This could be done during consent/grant management interaction that typically happens prior to authentication/authorisation.
• With challenge in-hand SPC can be invoked. Based on successful authorisation a Payment Assertion is minted.
• The Relying Party can then use - ideally - CIBA to send an Authorisation Request to the ASPSP, with the Payment Assertion used to set the value of login_hint. The ASPSPs can then validate the Payment Assertion using the public key they hold.

For many markets SPC therefore snuggles up nicely with existing protocols. However, adoption will require buy-in to Webauthn and then SPC as alternative to app-to-app or web-to-app authentication which is prevalent in all markets. The onus here is on ASPSPs to adopt, and given the high level of investment to date by ASPSPs for functionality that is largely for regulatory compliance in many markets cutting in a new authentication standard may be a stretch. My fingers are, however crossed given the recent fanfare around Passkeys and the how that might force things along.