W3C

SPC Task Force

30 August 2021

Attendees

Present
Adrian Hope-Bailie (Fynbos), Bastien Latge (EMVCo), Clinton Allen (American Express), Doug Fisher (Visa), Gerhard Oosthuizen (Entersekt), Ian Jacobs (W3C), John Bradley (Yubico), Jonathan Grossar (Mastercard), Michel Weksler (Airbnb), Sameer Tare (Visa), Stephen McGruer (Google), Susan Pandy (Discover)
Regrets
-
Chair
Ian
Scribe
Ian

Meeting minutes

Pull request 120

Ian: Ok @goosth?

Editor thanks!

FPWD is tomorrow!

Chrome updates?

Stephen: Chatted with WebAuthn WG last week; expect more discussion next week. No actions yet.
… we have filed an intent to ship in 95; not a guarantee but we hope to have it there.

John_Bradley: M95 where?

Stephen: MacOS and Windows

John_Bradley: How are you doing it on Windows? WebAuthn.dll v1 doesn't have any way to track cross-origin flag.
… the question is: how does the platform authenticator differentiate SPC v other FIDO credentials?

Stephen: I don't think today it's the job of the platform authenticator. We have a local browser list implementation today (not the long-term plan)

Stephen: Temporary in-browser storage today; various proposals being discussed (e.g., CTAP, or discoverable credentials)

John_Bradley: Windows doesn't have non-discoverable-credentials.
… in principle SPC credentials are non-discoverable

stephen: Yes, when used in a 3p context

IJ: What does the spec need to say?

Stephen: I was waiting to chat with WebAuthn folks before adding some info to the spec.

John_Bradley: LargeBlob is a viable option.
… best thing is to have an extension IMO and store information in authenticator.
… could be a Webauthn extension (inherited by CTAP)
… there's no reason the extension couldn't also be passed to the authenticator
… the question is how the authenticator tells the platform that it is one kind of credential or another

Stephen: Long term, what I'm hoping to do is that the necessary APIs for conditional UI should enable this use case.
… what we need is the ability to say "Does this credential match?" without a user interaction....

AdrianHB: Is our use case in front of conditional UI folks?

Stephen: Yes from Google side

John_Bradley: People aren't necessarily thinking how this will work with caBLE
… how do private APIs talk to internal authenticator....we need to think about how this works with roaming authenticators

Stephen: I agree.
… what I'm hoping to see is that, with this initial version, we will prove the value and then we extend to roaming, caBLE, etc.

<Gerhard_> question: Will SPC work across all Platform Authenticators today (WebAuthn Level 1)

Gerhard: Will M95 work on Android?
… will M95 work on existing Windows and MacOS versions shipping today?

Stephen: Windows and MacOS works today with existing libraries today
… but we are waiting for Android to add discoverable credentials before we support SPC on Android

Ian: What is that timeline?

Issue 101: Proposal: support data URIs for card art icons

Ian: Doug indicated probably suffices to has the URL (not the data)

Stephen: Current implementation is to sign the URL.

John: The authenticator signs a hash of client data.

Stephen: Cripes! You're right!

AdrianHB: We don't have to has the data, but we should sign the image data (e.g., base 64). You don't need to hash it.

John: Put the information in client data (e.g., base 64 url encoded or whatever)

Stephen: It does mean that whatever has to be sent to the RP may be quite large
… what is the hash also in webAuthN?

John_Bradley: SHA256. Just the one algorithm.

Stephen: the original problem is that I thought the authenticator would not like the large blob, not realizing that it would be hashed before hitting the authenticator. Sorry about that!

Stephen: So first problem not a problem.

John_Bradley: The RP should have the image. They keep the challenge. Why can't they keep the image?

Stephen: So "URL or image data"?

John_Bradley: Signing over URL probably not useful for embedded flows. The Verifier doesn't know what the URL pointed to.

John_Bradley: What was the feedback from Apple and Firefox on displaying image URLs in this as opposed to structured data?
… somebody else could use this API for displaying arbitrary (nefarious) images
… if it's an image URL, people will try to use it to sign for property purchases or other things

Stephen: Hoping to get more input from Mozilla and Apple.
… regarding URL...it's just to an image

John_Bradley: Ah, ok
… this is just for confirmation of what card image was used.

Stephen: I suspect RPs will not check this field.

John_Bradley: Agreed.
… if just the card image, just sign a hash of the argument that was passed.
… let the RP cache that.

Next meeting 13 September

(No meeting on the 6th)

Minutes manually created (not a transcript), formatted by scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).