- From: Arshad Noor via GitHub <sysbot+gh@w3.org>
- Date: Wed, 04 Aug 2021 19:36:23 +0000
- To: public-webauthn@w3.org
The issue to the best of my knowledge, Natalie (@ncthbrt), is that the schemes devised in the past to authenticate Consumers to Issuers, excluded the use of public-key cryptography (PKC) as an authentication mechanism. While PKC schemes can be designed to be used in embedded mode (as S/MIME does), the FIDO/WebAuthn protocol was not designed with this requirement. FIDO was designed to be a 2-party protocol - like TLS ClientAuth - but with additional features and constraints. Trying to shoehorn that protocol into a multi-party transaction with a third-party controlling the flow was not a design-requirement. When you add in the fact that the world has changed wrt privacy (with GDPR/CCPA simply representing the vanguard of privacy regulations), you have additional non-technical constraints placed on the protocol. IMO, these constraints can be addressed by simply having Consumers register their payment instrument _directly_ with the Issuer _before_ they use it anywhere. Not only does it eliminate the multi-party FIDO registration conundrum, but the registration flow can be designed to comply with privacy regulations adequately (once the Issuer's lawyers are involved in the process). Once registered, as long as the Issuer has received consent from the Consumer for that credential to be used (for generating digital signatures) through the Issuers' affiliates, getting an assertion through an iframe is not as problematic - as long as we have ethical Issuers and Merchants/PSPs. -- GitHub Notification of comment by arshadnoor Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1656#issuecomment-892920835 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 4 August 2021 19:36:25 UTC