- From: Stephen McGruer via GitHub <sysbot+gh@w3.org>
- Date: Fri, 03 Sep 2021 21:33:55 +0000
- To: public-webauthn@w3.org
Apologies for the delay here folks, I got wrapped up with other happenings this week. Starting with Akshay's latest comment: > This is not a good design. This does not work cross-browser. We are in agreement! It's a hack, to speak plainly, which suffices to let us see if the general concept of SPC (trustable user authentication initiated by merchants) is attractive to the payments industry. > I would like to understand whether we have a need for separating out normal credentials vs SPC credentials. [...] @sbweeden has a point. Why only restrict to SPC type of credentials? Why not everything? One thing to make clear, from my perspective - the term 'SPC credential' exists only to differentiate the ability to utilize the credential in a third-party initiated authentication. I do not expect a long-term solution in WebAuthn to even refer to SPC - the concept might be called 'third-party enabled credentials' or something like that (I'm bad at naming!). SPC then becomes a spec that relies on such 'third-party enabled credentials'. > We believe that user should be able to use external authenticators if they choose to. And we don't want SPC to be restricted only to platform authenticators. And for external authenticators, there cannot exist an API which says tell me the credentials when that device is not even plugged in at that moment. Hence the UI prompt occurs to guide the user first and that is a big problem in all of this. I think this might still be compatible with SPC. To maintain authentication ceremony privacy, SPC has to show a user dialogue whether or not the passed credentials match the device. In the match case, it's a transaction dialog (followed by WebAuthn if the user agrees to verify the transaction). In the non-match case, it's a form of error dialogue that we try to make payment-specific. It seems like the latter could additionally allow for the user to plug an external authenticator in at that moment, and it would 'retry' the matching logic? > In your current design, RP is not in control. [...]. RP must be be able to decide what behavior they want and what scenarios they want to support. As discussed in the call; I (and I think at least @christiaanbrand will agree with me) am asserting that the RP does have control, in that this behavior is opt-in when they create the credential. I agree they don't have absolute control, but as per below I don't think that's desirable for the payments case. > The solution I am thinking of is along the following lines. [...] The issue with this solution, as with @emlun 's, is what @ve7jtb points out below - it puts the bank back in the middle of the payment transaction. This re-introduces the performance and reliability issues we were trying to get away from (though I will cede that it does still keep the user-confusion issue out of it as the user never sees this). Moreso, this solution, as with @emlun 's **and** @ve7jtb 's do not integrate with or build on top of existing widely-used payment protocols that banks are familiar with and which they trust. SPC's current model should (I believe) work with any payment protocol where the merchant and the bank talk on some form of backend protocol - which is most of them. > I wonder whether you choose non-discoverable because that what Android supports today or there is some other reason? For comparison, Windows only support discoverable credentials and not planning to support non-discoverable credentials. And I would like to Windows Hello and external authenticators to also be able to satisfy the SPC requirements because user verification is what should matter to the RPs. Whether those credentials are in allow list or not, should not matter IMO. I think you perhaps misread: we choose **Discoverable**, not non-Discoverable. That's actually why SPC cannot launch currently on Android, because I *think* that Discoverable Credentials are required for it's long-term success. (I could be wrong!). (Although perhaps we are just using different definitions here... you're correct that currently SPC requires the merchant to pass in the list of credentials, which is very 'non-Discoverable' like. The reason was that in our opinion from the _website_'s perspective credentials should only be Discoverable for the RP, not for a third-party.) -- GitHub Notification of comment by stephenmcgruer Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1667#issuecomment-912822803 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 3 September 2021 21:33:57 UTC