Meeting minutes
<plh> me zakim, who's present?
Payments Working Group
Stephen Mcgruer and Ian Jacobs from the Secure Payments Working Group checking in
Register SPC-related WebAuthn extensions in IANA registry
A Payments extension and bit addition in CTAP
<Ian> w3c/
Topic number 1: Wanted to discuss how to implement this webauthn extension with the working group
<plh>
<Ian> smcgruer_[EST]: The 'payment' extension is "client-side"
Tony: is Apple planning to implement?
Ian: Apple has expressed growing interest in SPC and has requested a charter change that would allow Apple to join the group, this would give us a clearer answer to this question
Tony: Has FIDO has already implemented this extension?
Ian: The CTAP revision has an addition of the cross-origin bit, and this is partly implemented in android and chromium
John Bradley: Contained in CTAP 2.2 Draft
Ian: There may be multiple ways to answer this- there may be multiple ways to declare and extension "registered". Interested in "registering" this bit with IANA, and interested in hearing anyone who's gone through IANA registration
Tony & John: This is the first extension (outside of CTAP) that defines a WebAuthn extension not in these other specs
AGL: The IANA registry is an open standard and you can email the secretary and say "please register this"
PHL: Is this the step? There's no additional steps for review and registration?
<Ian> https://
<plh> Registration requests can be made by following the instructions located there or by sending an email to the webauthn-reg-review@ietf.org mailing list.
AGL + John: It says that Mike Jones and another expert are the experts for IANA, they may contact these experts to "sanity check" a registration request. They have an expert review classification but that's not what is needed here
Ian discussing the IANA registry page for WebAuthn (URL linked above)
Topic 2: Does the reference specification need to be a certain status before registration? Before CR?
PLH: I recommend CR before registration
ACTION: John Bradley to put Ian Jacobs in touch with Mike Jones
<Ian> https://
<plh>
Tony: Are you looking for additions/documentations in our spec?
to Ian
Ian: we wanted to coordinate as to now "run afoul" of the working group. Mostly wanted to figure out if there was best practices here.
PLH: You don't need us to register this
John Bradley: There's more coordination in the CTAP working group regarding this. The bit documentation should happen in CTAP
… Once you register this, there needs to be additional documentation on requesting responding with this bit, most likely in CTAP
Ian and Stephen to move forward registering the client-side payment extension.
Ian: what of the extensions being added needs to be in Web Authentication?
John Bradley: No need to register anything in WebAuthn
ACTION: the web payments working group will register the payments extension as defined by SPC. When CTAP 2.2 matures, the SPWG will discuss registering the CTAP-dependent.
Tony: if (SWPG) you're headed to publication, you'll need to show interoperability of this extension
The SPWG is working on this
Any news on WebAuthn L3 worth mentioning to Payments folks?
General Questions from SPWG to WAWG
<Ian> Ian: Should we remove special cross-origin create feature from SPC (cf WebAuth 1801)
We're trying to work closely against creating divergent features. The bit in CTAP if standardized gives us a different way to manage our homegrown special extension. Stephen has been working on a cross-origin PR in WebAuthn #1801. Should we remove our special cross-origin create?
John Bradley: I'm not sure the two features overlap completely
… I wouldn't assume that we don't have any need for the SPC special extension
<smcgruer_[EST]> w3c/
Tony: We're not the only ones that are stewards of this
Stephen posts the link above
This deviates from what we have in WebAuthn: the first was allowing creation in a cross origin i-frame, at least for user agents. The other thing we do is a number of checks on the authenticator, different than WebAuthn. We only support platform authenticators right now
Roaming Authenticators - SPC would like to support RA. When discussed at TPAC last fall we discussed UX/I around RA. Wanted to know if there were any updates to RA support.
<Ian> w3c/
John Bradley: Yes there should be ongoing additions in CTAP2.2
John: There are still potentially some gaps around how cable plays into roaming authenticators. Need to discuss with AGL
Ian: If what I'm hearing is that it will "just work" at some point then we'll push forward assuming support, and update when the feature is available for SPC.
… Do you know when this might be available?
AGL: No timeline
Ian asking if the group is ok with SPC having a limitation to platform authenticators
AGL: There are a variety of authenticators and it is independent of WAWG what is supported
Stephen: In a world where a user might have a security key for a credential, and we're unable to discover whether a credential does or doesnt exist on a roaming authenticator, how do we solve this? This is probably up to the SPWG
Discussion around how SPC could solve some of the UX issues where mediated/conditional UI and modals are unavailable
Discussions around limitations in CTAP/WebAuthn around ability to infer the type/transport of authenticators availible to the client
What's new with passkeys and how might they affect SPC?
Time permitting
Sidebar - Tony: Is Web Payments meeting at TPAC?
Ian: yes on Tuesday
Dan Veditz: Mozilla is worried that additions could be made that could fingerprint the user via the authenticator
Ian: There is dialogue for the user authorizing identifying actions
Dan Veditz sidebar: w3c meetings will soon lose the use of MIT-sponsored conference hosting such as the mit.webex.com meeting link we're using right now. Chairs need to figure out where we move in the next couple of weeks
Back to topic
Ian: SPC has an open issue around how passkeys might affect the SPC API. There have been many ongoing conversations we've been casually watching, but wanted to ask the WG directly
Tony: are you wanting the payments extension to work with passkeys?
Ian: yes
John: Seeing that it works with all platform authenticators and all platform authenticators are essentially passkeys, then the answer is yes. The question should be refined to: is everyone cool with multi-device passkeys that can be shared with 3rd parties and how do we communicate that?
… When doing a an assertion, are there additional pieces of information that need to be considered? hasn't yet been discussed in FIDO WGs
David Turner: regulators might not like some of the data transportability
Ian: if there are parameters that become available to 3rd parties regarding which authenticators that may be allowed, that might not be allowed. What we're hearing is the conversations are still ongoing
John: These new parameters are still in flux
Ian: So there's data/possible parameters in the assertion that might be important to SPC?
John: There shouldn't be anything that's an obstacle
Tim: there's no new parameters proposed that would effect you so far
Ian: Yes we're just watching right now. We'll check in again in a few months (at TPAC)
SPWG is interested in meeting with WAWG on Monday or Tuesday at TPAC
Big thanks to Ian Jacobs and Stephen McGruer for dropping by
<plh>
PLH has linked to the new meeting invite, this will replace the Webex link as the W3C moves off MIT-sponsored software
<plh>
Not using Jitsi Meet due to lack of phone support
The meeting link will remain static
Tony: half the group showed interest in meeting at TPAC (as per the RSAC F2F meeting results)
none
ACTION: Chair to schedule F2F meeting at TPAC and coordinate with SPWG for join session
Pull Requests and Issues
AGL: #1878
If the results of the F2F discussion still hold, I will update this to nullable
M2: I am happy with this, but if there's any pushback let me know.
AGL: This PR needs to be changed. These JSON fields become optional and NOT nullable with these changes
ACTION: AGL to update #1878, Matt Miller (M2) to approve
/us02web.zoom.us/j/86300730761?pwd=U2NpYzFYbmpDTHdiMkNpK3Y0SkQ0UT09///us02web.zoom.us/j/86300730761?pwd=U2NpYzFYbmpDTHdiMkNpK3Y0SkQ0UT09
#1855
w3c/
Currently blocked
w3c/
Emil: this is ready to go
… We have approval from Ackshay and Tim on this
non
s/non
none
w3c/
M2: worried about people abusing the credential display name
Nick Steele against, display name should be presented at the discretion of the RP