Web Payments Working Group

SPC issue review

https://github.com/w3c/secure-payment-confirmation/issues

See the WebAuthn proposal for using a prefix to identify an SPC credential.

Stephen: This question is how can we make SPC even more of a real WebAuth thing.
… first thing is to indicate using WebAuthn that "This is an SPC credential"
… there are two functionalities associated with that: (1) cross-origin ceremony and (2) transaction dialog
… there's another functionality associated: cross-origin creation
… the folks at Yubico have proposed a solution that works for all types of authenticators:

<prefix><rpid>
… for example: spc:bank.com
… this works with remote authenticators - creates a new namespace for the RPID. The authenticator doesn't care what the RPID is
… the main consequences of this proposal:

1) SPC credentials cannot be used for login and vice versa.
… that's because the prefix is established at creation [and cannot be changed]

2) This solution binds "cross-origin" and "transaction UX" capability, so that would prevent the separation of those powers as requested by Entersekt

NickTR: I like the proposal in the sense that I like the specialization of the credential.
… I think that risks (e.g., privacy leaks) go up as credential usage is more flexible

smcgruer_[EST]: The reason this proposal precludes the separation of powers, is that the browser only has one bit "SPC-or-NOT"
… the browser doesn't have a second bit that says 'ONLY-ALLOW-ON-MY-DOMAIN"

smcgruer_[EST]: Part of me wonders if what we should be namespacing is the cross-origin part.
… the payment transaction screen should always be available.
… the namespace could refer only to the cross-origin usage.
… all credentials could be used for payments.
… it might also suggest "cross-origin login" but user agents could manage that.
… I think the cross-origin bit is not likely to be loved by the WebAuthn folks.

Jean-Luc: Would it be possible for have two registrations in this scenario (where there's a ns prefix)?

smcgruer_[EST]: Yes, you could have two registrations. And they are considered two distinct relying parties

<nicktr> ian: To summarise the proposal: Here's how to a bit that doesn't break things

<nicktr> ...in practice, could you have a list of enumerated things (e.g. public key, payment, log in...)

<nicktr> ...and can you ever change those things once it's been minted?

smcgruer_[EST]: We need to decide in this WG whether the proposal works.
… so we need to hear from people who are planning to use SPC (and, e.g., Entersekt who raised the point on separation of powers)

ACTION: Nick to work with Ian to draw more WG attention to the concrete proposal.

smcgruer_[EST]: One question - if we do this, does it preclude us from trying something else in the future?
… the way it would work today to manage "new" credentials it to prepend "SPC:"..but i expect over time the waters might be muddied.

NickTR: If credentials are immutable, you could either (1) recredential in a new namespace or (2) implementations would change behavior.
… in short, this proposal seems reasonable to me.
… I have the feeling reissuing the credential is a likely thing people will be done (for credential hygiene if nothing else)

https://github.com/w3c/secure-payment-confirmation/issues/77

<nicktr> ian: explores use case

<nicktr> ...bank account holder with multiple accounts with the same bank

<nicktr> ...if they share a credential, then conceivably they can be linked by third parties

<nicktr> ...creating a potential privacy issue

<nicktr> ian: observation 1: users should be aware, and manage things separately

<nicktr> ian: we need a solution that lets banks do the right thing (individual credentials per instrument) with the user experience of single registration

smcgruer_[EST]: PING asks for a solution that even a malicious bank could not cause a problem, but Ian points out that we can't prevent this anyway.

<smcgruer_[EST]> https://www.w3.org/2021/10/28-wpwg-minutes.html#t01

<nicktr> ian: I'm trying to describe the problem space.

<nicktr> ...I don't think we can prevent multiple accounts per user

<nicktr> ...malicious banks could always broadcast those links

<nicktr> ...I think we should help banks do the right thing

<nicktr> smcgruer_[EST]: this is exactly section 11.3

<nicktr> ian: so I believe that we want one credential per user on registration, but one credential per instrument on API call

Ian: We want "N-to-1" on the server side but "1-to-1" on the browser side.

smcgruer_[EST]: If you define a public method, the merchant can do it, too

<nicktr> ian: what would be good is a way of passing origin plus hash of credential into the authenticator (but this isn't current functionality)

smcgruer_[EST]: whatever we come up with has to be done in the authenticator in order to preserve "cross-browser'

<nicktr> ian: so I think we've found a use case that is worth WebAuthn investigating.

Ian: Can you register N credentials with 1 registration gesture? Is there some way on the server side (e.g., at registration time) to create N derived credential IDs known to the browser?

(Stephen shakes head "no")

Upcoming priorities for discussion

<nicktr> https://github.com/w3c/webpayments/wiki/Agenda-20211118#upcoming-priorities-for-discussion

NickTR: Please have a look at those

Meeting schedule

<nicktr> ian: update on process:

<nicktr> ...1) the AC review of Payment request ended a couple of weeks ago. We are working through two formal objections. I am in discussions with reviewers about any changes that might satisfy concerns.

<nicktr> ...2) rechartering continues and I anticipate member review to start soon.

9 Dec is next call

after that: 6 Jan 2022