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

Impact of passkeys on SPC (formerly synced credentials) #174

Open
ianbjacobs opened this issue Feb 14, 2022 · 6 comments
Open

Impact of passkeys on SPC (formerly synced credentials) #174

ianbjacobs opened this issue Feb 14, 2022 · 6 comments

Comments

@ianbjacobs
Copy link
Collaborator

At today's SPC task force call [1] we discussed progress in the Web Authentication WG around the issue of synced credentials [2]. (I note from [2] that terminology for this feature may change.)

This issue is about the impact of those changes on SPC. From today's discussion, my initial sense is that:

  • The API surface may not need to change (inputs or outputs).
  • The API should take the new extension into account in the extensions member of SecurePaymentConfirmationRequest and any algorithms that touch on extensions.

Under section 8 Relying Party Operations we will likely want to either enhance 8.1 (Verifying an Authentication Assertion) or introduce new good practice about interpreting the output. In particular: what should an RP do when the extension includes a new device public key that the RP has never seen before (e.g., in terms of risk assessment, recording information on the server, etc.)?

Ian

cc @ve7jtb, @rlin1, @equalsJeffH

[1] https://www.w3.org/2022/02/14-wpwg-spc-minutes
[2] w3c/webauthn#1665
[3] https://w3c.github.io/secure-payment-confirmation/#sctn-securepaymentconfirmationrequest-dictionary

@ljharb
Copy link
Member

ljharb commented Mar 17, 2022

As a forewarning, I likely have close to zero context here, including understanding of proper terms, but this is the scenario that popped into my head when trying to understand this:

I have a relationship with, for example, Visa. I use my Visa card in a ton of places. I often might want to sever my relationship with an individual merchant - cellphone, TV, gym, or something - and literally never would I want to accidentally sever my relationship with Visa in that context, thus stopping payments on my electricity, water, childcare, home internet, etc. Doing so would be an unmitigated disaster.

In other words, if I've used a provider (stripe, etc) via "store A", and then later, go to use "store B" which also happens to use the same provider - I very much might want to exert GDPR rights and/or sever my relationship with store B, but under no circumstances would i want that to accidentally sever my relationship with store A.

@ianbjacobs
Copy link
Collaborator Author

See FIDO white paper related to multi-device credentials:
https://fidoalliance.org/white-paper-multi-device-fido-credentials/

@ianbjacobs
Copy link
Collaborator Author

Based on discussion about:
#183 (comment)

For future discussion: SPC talks about "the current device." Based on CABLE and synched credentials we may wish to revisit that phrase in the specification to talk about context or environment.

@rlin1
Copy link
Collaborator

rlin1 commented Jun 9, 2022

Since WebAuthn is considering handling the multi-device credential/single-device key distinction in WebAuthn (see w3c/webauthn/pull/1663 and w3c/webauthn/pull/1695), we might just leverage that - without having the need to change the SPC spec.
However, adding that topic to considerations would be good.

@ianbjacobs ianbjacobs changed the title Impact of synced credentials on SPC Impact of passkeys on SPC (formerly synced credentials) Sep 14, 2022
@ianbjacobs
Copy link
Collaborator Author

Discussed today with WebAuthn WG [1]. Things are still in flux so no concrete suggestions at this time.

[1] https://www.w3.org/2023/05/03-webauthn-irc

@ianbjacobs
Copy link
Collaborator Author

Keeping tabs here on the relationship of this pull request to SPC:
w3c/webauthn#1957

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants