Does the browser receive credential IDs or instrument IDs?

[w3c]

Does the browser receive credential IDs or instrument IDs?

[adrianhopebailie]

I think it needs to be credentials since we have heard a requirement from @btidor-stripe that the merchant is able to verify the assertion itself which means it MUST get back the credential ids and public keys from the issuer before invoking SPC.

Further...

I worry about the browser-side mapping of instruments to credentials and the high likelihood that the data gets stale.

Why is it necessary for the browser to keep this mapping if it's possible for the issuer to simply return the credential IDs?

Taking that thinking a little further, why do we even need a special credential type for this use case?

Is it enough to simply use existing PublicKeyCredentials but only allow them to be used for assertions from non-RP origins if it's done in the context of a payment.

I.e. After the merchant/PISP has gone to the ACS they will have a challenge and set of credentials and public keys that can be used for the SPC.

Why not simply let the merchant provide the instrument label and icon?

const securePaymentConfirmationRequest = {
  instrument: {
    displayName: 'Mastercard····4444',
    icon: 'icon.png'
  },
  allowCredentials: [{
    id: Uint8Array.from(credentialId, c => c.charCodeAt(0)),
    type,
    transports,
  }],
  challenge,
  timeout,
  fallbackUrl: "https://fallback.example/url"
};

[btidor-stripe]

Hey @adrianhopebailie, the browser needs to store the list of instruments, with names and icons, in order to show the card selector for the combined flow, right? I imagine they'll be kept in persistent, long-term storage, but that users will be able to view and delete instruments in some sort of browser settings page (which could be a nice kind of control to offer).

For the authentication-only flow, I think it could be possible to do away with the instrument and use only a PublicKeyCredential, though I'm not sure if the browser should trust the merchant to display text and an icon in this particular surface.

[adrianhopebailie]

the browser needs to store the list of instruments, with names and icons, in order to show the card selector for the combined flow, right?

Yes, but not bound to a credential. The mapping of an instrument to a credential is set by the issuer and will be maintained on the issuer's systems. Asking issuers to also store this in all of a user's browsers is a recipe for chaos IMO.

I'm not sure if the browser should trust the merchant to display text and an icon in this particular surface.

I think we need to look at this carefully. I couldn't think of any threats that this would present.

[danyao]

Great questions!

Why not simply let the merchant provide the instrument label and icon?

Because browser doesn't trust the merchant. If the merchant is able to provide the label and icon, then it'll be possible for a malicious merchant to provide a misleading icon and label to phish the user's credential. It's critical that the label and icon are supplied by the original RP.

Technically, the instrument label and icon don't need to be saved in the browser. Since the browser knows the RP, it can use some kind of discovery mechanism to find the instrument label and credential. But this gets complicated... It's much simpler for the browser to cache a string and an icon during credential enrollment.

I worry about the browser-side mapping of instruments to credentials and the high likelihood that the data gets stale.

Great point. The simplest approach is for the issuer to update an existing credential with a new label and icon when the user visits the issuer's website. But I wonder if a user cannot be guaranteed to revisit. Perhaps some kind of push mechanism for the RP to update the instrument label and icon would be helpful. Filed https://github.com/rsolomakhin/secure-payment-confirmation/issues/14 to track this separately.

Taking that thinking a little further, why do we even need a special credential type for this use case?

Is it enough to simply use existing PublicKeyCredentials but only allow them to be used for assertions from non-RP origins if it's done in the context of a payment.

The extra metadata associated with the credential is one reason for a special credential type. Another reason is developer ergonomics. PublicKeyCredentialCreationOptions contains a lot of options that don't make sense for Secure Payment Confirmation (e.g. attestation, user). Creating a new credential type allows us to create a payments specific creation option that's simpler and easier to understand by payments developers. It also simplifies input validation.

The new type also enables us to build payments specific features, such as the aforementioned push update of instrument label and icon.

---

Going back to the original question, I'm leaning towards instrument ID over credential ID because the added layer of abstraction allows loose coupling.

instrumentId can be a payment-network layer concept and can have any meaning the network wants to have. A possible future use case is that this can become the new routable ID that replaces the 16-digit card number. To the browser, instrumentId is just an opaque string that a bank wants to bind to a PublicKeyCredential. This also allows the network to switch to some newer / different authentication mechanism in the future if they choose to.

[tblachowicz]

If a single PublicKeyCredential would be linked to multiple instruments as described here: https://github.com/rsolomakhin/secure-payment-confirmation/issues/39#issuecomment-779912450, then the SPC should be invoked with the identifier of the instrument instead of the identifier of the credential.

[ianbjacobs]

@rsolomakhin and @stephenmcgruer, I think we can answer "credential ID" in light of the draft and close this.

[stephenmcgruer]

@rsolomakhin and @stephenmcgruer, I think we can answer "credential ID" in light of the draft and close this.

I agree.

[ianbjacobs]

Closed after confirming with @rsolomakhin.