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.

Sign up for GitHub

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

Jump to bottom

Using PaymentCredential for vanilla WebAuthn authentication. #39

Closed
tblachowicz opened this issue Feb 16, 2021 · 13 comments
Closed

Using PaymentCredential for vanilla WebAuthn authentication. #39

tblachowicz opened this issue Feb 16, 2021 · 13 comments

Comments

@tblachowicz
Copy link
Contributor

The explainer says that PaymentCredential is new type of credential used with Credential Management API. The credential is PublicKeyCredential with special features. Can the same credential be used for SPC flow and authentication with vanilla WebAuthn?

The use-case I have in mind is this:

  1. End-user registers a `PaymentCredetnial' to the RP e.g. issuer.com. The credentials include the payment instrument meta-data.
  2. Merchant triggers authentication with SPC as described in the explainer.
  3. The same credential can be used by the RP outside of the SPC flow to authenticate the end-user and get the regular WebAuthn assertion.

Can you please confirm SPC allows such a use-case?
@tblachowicz tblachowicz changed the title Using Using PaymentCredential for vanilla WebAuthn authentication. Feb 16, 2021
@kenrb
Copy link
Collaborator

kenrb commented Feb 16, 2021

That usage is currently in the explainer: https://github.com/rsolomakhin/secure-payment-confirmation#querying-a-credential

@tblachowicz
Copy link
Contributor Author

@kenrb I do understand how to use the PaymentCredential in the SPC flow. I'm backing about using the underlying WebAuthn credentials for non-SPC authentication e.g. navigator.credentials.get.

@Goosth
Copy link
Collaborator

Goosth commented Feb 16, 2021 via email

@tblachowicz
Copy link
Contributor Author

@Goosth: Thanks!

I think it's important to be able to use the enrolled credentials through navigator.credentials.get and SPC. I'd like the avoid RP i.e. issuer.com to enroll two separate credentials.

Thinking further, I wonder if an existing PublicKeyCredential can be linked to the new payment instrument. Can the PublicKeyCredential be linked to multiple instruments?

The use-case I have in mind:

  • End-User enrolls for webAuthn on the Issuer website.
  • Later end-user gives consent to link a card to a PK credential.
  • Repeat the above.
    The end result is: single PublicKeyCredential enrolled for the Issuer and linked to multiple payment instruments e.g. cards.

@kenrb
Copy link
Collaborator

kenrb commented Feb 16, 2021

@tblachowicz The section I linked to says:

The creator of a PaymentCredential can query it through the navigator.credentials.get() API, as if it is a vanilla PublicKeyCredential.

That is exercising it through WebAuthn rather than SPC. Is that different from what you are asking about?

@tblachowicz
Copy link
Contributor Author

@kenrb: Right. That answers my original question, then. Thanks for pointing it out!

Would you also know about the other question I asked in response to @Goosth: https://github.com/rsolomakhin/secure-payment-confirmation/issues/39#issuecomment-779912450?

@btidor-stripe
Copy link

Hi @tblachowicz, that's definitely something the spec aims to support! The idea is, an issuer should be able to "upgrade" a vanilla PublicKeyCredential to a PaymentCredential by simply passing the extra payment-related metadata (display name, icon, etc.). This might be useful if an issuer who already uses Web Authentication to secure their online banking portal wants to reconfigure those credentials to support SPC.

I also don't see any reason why a single PublicKeyCredential couldn't be associated with multiple PaymentCredentials (which might make sense if a user has multiple cards linked to the same online banking account, for instance) — although it might be worth discussing this with the Task Force in case there are any hardware limitations that could pose a problem.

From https://github.com/rsolomakhin/secure-payment-confirmation#future-register-an-existing-publickeycredential-for-secure-payment-confirmation:

The relying party of an existing PublicKeyCredential can bind it for use in Secure Payment Confirmation.
...

const securePaymentConfirmationCredentialCreationOptions = {
  instrument: {
    displayName: 'Mastercard····4444',
    icon: 'icon.png'
  },
  existingCredential: {
    type: "public-key",
    id: Uint8Array.from(credentialId, c => c.charCodeAt(0))
  },
  challenge,
  rp,
  pubKeyCredParams,
  timeout
};

@tblachowicz
Copy link
Contributor Author

Thanks for the precise answer @btidor-stripe! It looks that the use-case I have in mind will be feasible in the future.

@tblachowicz tblachowicz mentioned this issue Feb 17, 2021
Closed
@SensibleWood
Copy link

Hi @tblachowicz, that's definitely something the spec aims to support! The idea is, an issuer should be able to "upgrade" a vanilla PublicKeyCredential to a PaymentCredential by simply passing the extra payment-related metadata (display name, icon, etc.). This might be useful if an issuer who already uses Web Authentication to secure their online banking portal wants to reconfigure those credentials to support SPC.

FWIW - and this is just my opinion - I would say that whilst reuse of a credential across online banking and SPC is very practical it is unlikely. Security policies at the majority of banks would dictate there should be a separation of concerns between logging into online banking and making a payment at a merchant, regardless of how the Payment Request API "firewalls" the usage of the credential.

On adoption of SPC banks are therefore more likely to require a separate credential is minted dedicated to SPC and managed from within online banking. To the user once the extra step of creating this credential is done the fact there is an online banking credential and an SPC credential should be transparent - they'll get a prompt at payment time and present the right appendage without being overly concerned which one of the credentials it is.

Cool idea though, and obviously can be adopted by banks if their policies allow. Would make an incredible amount of sense.

@mountainhippo
Copy link
Collaborator

mountainhippo commented Feb 17, 2021 via email

@SensibleWood
Copy link

SensibleWood commented Feb 17, 2021 •
edited
Loading

Chris - I think you're right that it feels safer/preferable to have separate credentials for logging in to online banking and for using payment instruments. But in practice, with an open banking style payment in the UK (for example), it is your log in credentials that you're using to make a direct credit transfer from your bank account - because you're essentially logging in to online banking to authenticate and authorise the payment. So I wonder if it could be argued that Tomasz's use case (single re-usable credential) is merely a continuation of that situation?

Yes you're absolutely correct Nick, I don't dispute it - but the use of online banking as a means to authenticate the user in (for example, payment initiation) is driven by the interpretation of PSD2 in local law, countless opinions by the EBA (including around mobile banking as an authentication factor) and constructs around Consent which aren't according to lawyers allowed to be called authorisation even though a security practitioner would call them just that.

Implementation by banks with Payment Request/SPC is likely to be an entirely different beast IMHO. My comments are a cautionary note and not a dismissal of the idea.

@tblachowicz
Copy link
Contributor Author

I was thinking about a generic concept where a single credential can be linked to multiple payment instruments e.g. cards, so the same credential can be used to confirm the payment with any of those. I didn't necessarily mean the credential used to login to the bank, however, the concept does not permit that too.

I've been looking at the SPC through the lens of the primary use-case of 3-D Secure, however, I see other use-cases where the RP does not have to be the issuer, but also another party such as wallet for example.

@ianbjacobs
Copy link
Collaborator

Closing this issue because the current API direction should allow SPC credentials to be used with vanilla WebAuthn operations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@tblachowicz @SensibleWood @ianbjacobs @kenrb @mountainhippo @btidor-stripe @Goosth