- From: John Bradley via GitHub <sysbot+gh@w3.org>
- Date: Wed, 01 Dec 2021 18:58:41 +0000
- To: public-webauthn@w3.org
The current proposal of creating a new RPID namespace for credentials that can be used in the SPC 3rd party context would prevent those credentials from being used in webAuthn as authentication credentials without significant changes to webAuthn implementations. On the SPC calls the banks have indicated that they prefer a single credential that can be flagged as also being SPC 3rd party capable. Some people like @akshayku have indicated that they never want a plain authentication credential used in SPC. That would also be incompatible with adding one namespace, as non 3rd party SPC credentials and authentication credentials would look the same. We would need to add two new namespaces one for 1st party SPC and one for 3rd party SPC and not use normal authentication credentials in the SPC flows. The downside of this seems to be that the RP needs to make two credentials In principal CTAP could address UV caching and allow two credentials to be created at one time, but this will be complicated and take a long time to deploy at any scale. The other way to approach the problem would be to use some other member of the discoverable credential to store some sort of credential type flag. The two likely candidates that are both set by the RP and not user visible, are the userID and credblob. The RP when making the credential could add special flags to one of those members that WebAuthn would pass through and ignore. Only the SPC implementation would need to inspect those flags to see if the credential is allowed for payments and separately if it is allowed in a 3rd party context. credBlob is a minimum 32bytes if supported so space is probably OK. Its intended application is to store a certificate hash, the other is to store a symmetric key. Probably not things you would want with a SPC credential. One issue with using this value is that the value is not exposed in the credential management API. You can however get it via get assertion without UP or UV if you have the RPID and it is created with credprotect 1 or 2. If you wanted to use this with discoverable credentials then the RP would need to create them with credprotect 1. user.id (User Handle) is 64bytes and required for discoverable credentials. It can be interrogated both by the credential management API and by performing get assertions with UP=0 UV=0 assuming the credential was created with the correct credprotect value. The other alternative would be to go back to the CTAP TWG and ask for a new credential-type member in CTAP2.2. That would be incompatible with all current authenticators but could be inserted into CTAP2.1 authenticators if specified quickly. This could also be combined with using credblob/user.id only if the new member is not available in SPC. -- GitHub Notification of comment by ve7jtb Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1667#issuecomment-983962193 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 1 December 2021 18:58:43 UTC