Meeting minutes
https://
https://
Enrollment of multiple instruments with one authentication
<Rolf> Do we already cover the ability to use the underlying credential for traditional authentication?
https://
FIDO credentials should be "enhanceable" to SPC Credentials.
SPC credentials should also usable as ordinary FIDO credentials. See issue 39.
In-transaction enrollment, later authentication same merchant
IJ: can you optimize the UX to enroll+authenticate/sign
Rolf: Technically what you expect is after registration of credential. ID&V steps often prone to fishing. So registration time has a different security characteristics
… session binding assurance level not really known at this point
… how do you know it's the "same session". Cookie? stronger than that?
… binding assurance level might be relevant for this one
Authentication with out-of-band authenticator
Rolf: Best thing would be to be able to send transaction details to the out-of-band authenticator
… Level 1 extension for transaction confirmation technically is this kind of approach
… the concept is the same even if not same data as SPC
… it doesn't matter how you send the data, but would be great if you could do so
… what we do today is that the browser displays the transaction text
… the browser has a privileged position (since it can talk to the authenticator), this is the security that we are leveraging
… if you send the transaction text to the authenticator it would be even higher security level
… the browser should be able to *understand* whether the text will be displayed by the authenticator
… the browser needs to be able to say "Check your smartphone" in the dialog...that at least needs to be discussed
… I can send push notification that launches an app that talks to a server to trigger SPC
… you can trigger it through out-of-band mechanisms like QR codes
Jean-Carlo: In this case, would be still know user verification was formed?
Rolf: Yes, you get an assertion from the authenticator.
… suppose I'm on desktop without a registered platform authenticator
… it might know that I have a smartphone that supports SPC
… so it could send push notification to app or OS or browser on my smartphone to trigger spc on my device
… the browser on my phone would ask for confirmation which would generate the signed assertion
… we might not need to standardize the out-of-band behavior (since different on each platform)
IJ: What are security requirements for shipping to the phone?
Rolf: Merchant has the data (currency, credential ID)
… if SPC returns null, the merchant's JS can tell the merchant server.
… ideally, if my PC browser is synced to my phone, then the BROWSER might know I have an SPC credential on my Android device. In which case the display can be shipped to my phone where I can sign it.
… that would be a browser vendor decision
… multiple channels to ship the display info to another authenticator: CABLE, known authenticator since same vendor
… CABLE-connected is still considered "Roaming"
<Rolf> caBLE - cloud assisted BLE
next meeting
7 June
No meeting 14 June