Meeting minutes
SPC updates
[Expanding output states for SPC]
relates to w3c/
smcgruer_[EST]: Goal is to distinguish more clearly "cancel this payment" from "cancel this means of authentication"
… we introduce a new error state for canceling the payment.
… there is corresponding UX
Ian: Is there anything about UX in the pull request or is that left to implementation?
smcgruer_[EST]: In the spec we slightly change wording to say "you always show the confirmation UX"
(No questions or comments)
smcgruer_[EST]: I will land the pull request.
[Feedback from 3DS WG on UX]
Sameer: 3DS WG happy with seeing logos for issuer, network. Our one comment is we'd like to see the logos edge-aligned. Not a deal breaker but if logos are center-aligned, users would see different UX, which isn't great. if it's possible, it could be better to have the logos edge aligned. But it's not a deal breaker.
… any feedback from Chrome UX folks on that request?
smcgruer_[EST]: We've discussed centering v. edge-aligned; I have not heard anything back from our designers. We can continue on some other issues (e.g., low res logo, weird sizes)
Sameer: Within the 3DS Spec we only have guidelines for display (but requirements for elements to be displayed)
… we don't say what happens when logos are not provided.
… we can continue to provide input on other questions.
<smcgruer_[EST]> w3c/
Ian: Where are we on the payment system logo pull request?
smcgruer_[EST]: We added a label for accessibility
… other than that, there's just small bits of feedback to be incorporated
… we are taking the general stance that the output cryptogram will include the url of the logo if the browser showed it in some capacity. But in some error cases, there is not information about what happened (e.g., logo not provided at all, or logo had to be resized, or logo didn't download)
… we consider it is "sufficient" to know via the cryptogram whether the logo was shown or not.
Ian: Is there error handling guidance in the 3DS spec?
Sameer: We do have some guidance, but I need to take a look to see if there's error handling related to logos.
Doug: I don't think we have error guidance in 3DS re: logos
Sameer: That makes sense. We treat logos differently in browsers and SDKs.
Ian: How far is the implementation from the pull request?
smcgruer_[EST]: Not far
Add the TAG security and privacy self-review questionnaire for BBKs
See also w3c/
w3c/
Should BBKs be created on all passkeys even without the payment bit being set, so that RPs can use them in the future with SPC?
smcgruer_[EST]: If we do BBK by default for all passkeys, are we encroaching on WebAuthn space?
Ian: But the BBK is only accessible through SPC, so is it really encroaching?
Sameer: It could make sense to have BBK on passkeys without payment bit set; we are hearing from issuers that they would want to use their passkeys for authentication.
… if the issuers have passkeys for login, they do want to be able to use for SPC.
… and they would want device binding in that case.
Ian: Any negative implementation implications?
Slobodan: From tech level, probably similar...the current restriction is that we check if the bit is set.
Bjorn: Fair question to ask ... suggest you check with the WebAuthn WG
Sameer: Is the bit only set at creation?
smcgruer_[EST]: Currently only at creation. Whether an update to a passkey to make it explicitly usable for payments is possible is a good question.
Slobodan: Clarification - you get a BBK on authentication in all cases (even if bit is not set). The question is simply about creating a BBK at creation time if no payment bit set.
Sameer: If I have a passkey on the device and I use it with SPC, the BBK is created?
smcgruer_[EST]: Yes.
smcgruer_[EST]: If payment bit is not set at creation, then we don't have a way to get the BBK to the RP
… the way to make this work consistently is to use the payment bit.
smcgruer_[EST]: If you are expecting a BBK, maybe just set bit on creation
Sameer: In practice, some issuers may support login before payments
Sameer: We can put guidance in the 3DS Spec
smcgruer_[EST]: We've not come to a clear conclusion in this group that "a passkey should always have a payment bit" and more strongly separate the concepts (auth for login, auth for payments)
JL: Are we looking at being able to create a BBK for other use cases for payments?
smcgruer_[EST]: Are you always thinking of passkey use cases?
JL: Yes.
… e.g., accessing a bank account in EU requires multiple factor authentication.
… it's a sensitive operation but not payments related
Ian: It would be similar friction either way: create a new passkey with bit set v. use passkey without bit but step up user when new bbk seen
smcgruer_[EST]: There's some implementation complexity that goes away if we assume "bit needs to be set at creation time" or if there's an "upgrade path"
ACTION: smcgruer_[EST] to look into whether a passkey can be upgraded to have the payment bit set.
Ian: Would RPs like update path?
SameerT: I think that in a 3DS context, I think issuer using their own passkeys for authentication will be somewhat uncommon and ACS's are likely to be managing the passkeys.
ACTION: Ian to add an issue to the issues list about SPC passkeys always having the bit set, but with an update path.
Q Do we need to be more precise about the meaning of a "browser instance" or partitioning among user profiles?
Slobodan: We'd like the definition to include different profiles.
(No comments requesting more rigor in definition of "browser instance")
Ian: How do the change in requirements impact the Pull request to integrate BBKs in the spec?
Sloban: No changes needed if we don't generate BBKs at passkey registration time when those passkeys don't have the payment bit set.
smcgruer_[EST]: I don't think the spec needs to change
smcgruer_[EST]: We hope to merge the PR for bbks-in-SPC some time next week
[SPC feasibility on Chrome iOS]
rouslan: We are often asked about SPC on other platforms (e.g., iOS).
… payment request is available on iOS as is Web Authentication.
… we have asked the WebKit team if it's possible to implement SPC in WebKit; we've not yet received responses.
rouslan: another idea is to explore the feasibility of implementing SPC in iOS
… some options include a pull request on WebKit
… another option is a Javascript shim that overrides the PR API implementation and looks for a payment bit for that payment method; this would only work in Chrome
… an important topic would be how device binding is handled.
… we don't want the keys to be synched for example.
… we'd like to hear from the group how important they see this feasibility study, and any pitfalls people foresee
Ian: Many people tell me that they would like to see SPC on more systems.
<SameerT> +1 to Ian's comment
smcgruer_[EST]: At this point we would need to do some feasibility work first
Ian: This would also be a second implementation, which is important for our getting to Rec
Updates elsewhere at W3C
W3C published Privacy Principles as a W3C Statement. W3C also announced publication of version 2 of a family of Verifiable Credentials Recommendations.
Next meeting
5 June
Meeting time
Ian: We received a request to move this meeting 1 hour later to align with WPSIG meeting time.
… please think about that possibility and we'll talk about it again at the next meeting