Clarify cardinality between PaymentCredential and payment instruments

[danyao]

Arguments for 1 credential for many instruments:

• The bank really only wants to authenticate the person. Having 1 credential that works across multiple instruments and possibly even the bank account login is more convenient for the user, as they only need to enroll once.

Arguments for 1 credential for 1 instrument:

• Sharing a credential mixes security domains. This is especially true when sharing between login and payment.

Next step is to try to enumerate attack vectors for sharing credential.

[adrianhopebailie]

Also, a single user may have multiple credentials (one on each authenticator/end user device). In reality we'd need to support a many-to-many relationship between credentials and instruments.

[erhardbrand]

Supporting multiple instruments per credential would definitely be beneficial.

This does bring to mind cases where a single instrument has to be removed from an existing credential (e.g. card lost, card expired).

While the current WebAuthn convention is for the RP to simply delete the user<->credentials link server side to remove the entire credential, the ability to remove a single instrument from an existing credential could help prevent re-registration if a single instrument is no longer active.

Unfortunately I cannot think of an elegant way of doing this with the available navigator.credentials.get() and navigator.credentials.create() API's, other than perhaps also requiring a list of instruments to be passed in during credentials.get().
From: https://github.com/rsolomakhin/secure-payment-confirmation#querying-a-credential

Querying a credential

const publicKeyCredentialRequestOptions = {
  challenge,
  allowCredentials: [{
    id: Uint8Array.from(credentialId, c => c.charCodeAt(0)),
    type,
    transports,
    instruments // Array of instruments to use
  }],
  timeout,
};

const credential = await navigator.credentials.get({
  publicKey: publicKeyCredentialRequestOptions
});

[ianbjacobs]

See related email:
https://lists.w3.org/Archives/Public/public-payments-wg/2021May/0016.html

[ianbjacobs]

See discussion from 27 May:
https://www.w3.org/2021/05/27-wpwg-minutes#t04

@stephenmcgruer raised an interesting point about "late binding". We will work on a proposal for the requirements document that the API support "late binding" which I currently undersatnd to mean that the RP can decide the concrete funding source at authentication time, and is not required to determine it at enrollment time (though that case must also be supported).

[ianbjacobs]

The API now allows the RP (or other party) to provide instrument display information at authentication time. I believe this approach renders the current issue moot, so I am going to close it. (We can reopen if I'm wrong.)