Meeting minutes
Scope + Requirements
https://
https://
https://
Clearer benefits/features (pull request 70)
https://
Gerhard: Will review today or tomorrow
Pull request 73
https://
https://
Gerhard: This is the "user gesture" bit, right
Tomasz: What about capability delegation?
Tomasz: I think this is a good requirement; capability delegation can help with the UX
Wrap up discussion raised by Tomasz and Stephen on GitHub:
https://
Tomasz: How does API know that auth has taken place already?
rouslan: SPC requires a "key" as input.
Ian: But what impact would this have on the API?
rouslan: None
Tomasz: I am ok with requirement for in-transaction enrollment; but we may not need to mention "the user has been authenticated"
Action: Ian to revise the requirement to remove the pre-auth mention and to focus on the UX
Christian: In 3DS land, 3DS space would be where we talk about this.
… not sure it belongs in SPC
proposal regarding cardinality
Tomasz: I am hearing from API perspective that I provide an SPC Credential Identifier
Ian: The main proposed requirement is that "Each instrument is independently addressable."
<Gerhard> +1 for that unique addressability. Unique id for each instrument + auth combination.
Gerhard: I agree with the simple model
… but it does bring me to a use case comment: how do we handle scenario where multiple credentials are available
Benjamin: Regarding N > 1, the original expectation was "browser picks arbitrary one"
<Zakim> rouslan, you wanted to discuss cardinality and to talk about cardinality and failure experience
rouslan: In case of "no matches", the reqs returns error code without uX. That's the experiment we've been running. But there are some people who think that if there's no a user gesture requirement, there might be a way to iterate over a list of credentials ... and bad actors might use that info nefariously.
… so some people might be interested in an error message in case of no match
… regarding cardinality, I think that for each web site you'd have one credential
… some people want to reuse webauthn credential for payments
… the experience we've tested with SPC trial increases number of credentials
<Rolf> Note that it presents some level of friction to register an additional credential. So the ability to reuse one credential for auth and for payment is preferred from our side.
btidor: If we have a situation where N instruments can have signature from same key, we want to reduce avenues of attack, e.g., locking down cardinality as well as good practice to avoid vulnerability
<Gerhard> Thanks everone. Have to drop. Chat later
<jcemer> It is important to cover the case where the API is invoked with 2 credentialIds that are from 2 different instruments.
Next call
31 May