Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify cardinality between PaymentCredential and payment instruments #13

Closed
danyao opened this issue Jul 31, 2020 · 5 comments
Closed
Labels
question Further information is requested
Milestone

Comments

@danyao
Copy link
Contributor

danyao commented Jul 31, 2020

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.

@danyao danyao added this to the TAG Review milestone Jul 31, 2020
@danyao danyao added the question Further information is requested label Jul 31, 2020
@adrianhopebailie
Copy link
Collaborator

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
Copy link

erhardbrand commented Sep 21, 2020

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
Copy link
Collaborator

@ianbjacobs
Copy link
Collaborator

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
Copy link
Collaborator

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants