Meeting minutes
Shape of the API
Rouslan: We are trying to ship SPC before year's end
… given those timelines, we are thinking that the API shape will remain largely the same.
… enrollment will go through Credential management; authentication through PR API
Rouslan: In the future we'd like to move closer to WebAuthn as an extension to public key credential
… it might take .5-1 year to make the translation
… and that would decouple SPC from payment request API and put it closer to Credential Management API
… the question is how to we communicate this transition to developers?
… we suggest that the SPC API both talk about the current implementation, but with additional notes in the spec about future direction expectations
… signposts for developers and other reviewers about the direction of the API
AdrianHB: Yes, we'd like to describe both API shapes in the spec, get developer feedback, explain the origins of the current shape, and set expectations about the longer term
Praveena: Let's check with Adyen. How much would the API change? Do we know yet?
AdrianHB: In my view, the future API will be a lot cleaner. PR API is a bit hacky in terms of its use of a payment method identifier.
Praveena: Is there a migration guide I can point to?
AdrianHB: Not yet. We'll spec it out and get feedback.
Jean-Carlo: +1 to using get/create from the same API in the future
… invoking different APIs is not a big lift if there is feature parity
… would be interesting, when we have a new API shape, to have full feature detection (to discover that the new API is available) without parsing the user agent string
AdrianHB: WebAuthn extensions don't make it easy to know what extensions are supported. Is there a way to do that easily?
AdrianHB: Regarding feature detection, I like the credential interface; we may not have that in current version but in future would be good
Jean-Carlo: Reliance on user verification is another question.
AdrianHB: +1 to async function to do feature detection
Timing of the CfC
Ian: 9 August or sooner
AdrianHB: What's a good way to say this?
Ian: I feel like less is more here.
… a para for how we got here, where we'd like to go, heads-up change is coming
Rouslan: +1 to signposting. If the spec is written in a way that it only marginally states the current flow, that might create confusion.
… so we need to be clear that the current SPC API aligns with implementation, and indicate that other ideas are only ideas at this point.
… so I would not suggest interleaved "next gen" text; e.g., just use an appendix
AdrianHB: Should we get TAG review of we know it's going to change?
Rouslan: Blink rule is that anything that ships needs some initial TAG review
Ian: I would not delay TAG review, but would be great if we can get them to review compared proposals.
Ian: I am hearing slight pref for getting counter proposal in front of TAG as part of review.
2 new issues
(96, 97)
Next meeting
16 August