- From: philomathic_life via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Aug 2024 15:54:29 +0000
- To: public-webauthn@w3.org
zacknewman has just created a new issue for https://github.com/w3c/webauthn: == Remove `RegistrationResponseJSON.id` and `AuthenticationResponseJSON.id` == First, [`RegistrationResponseJSON.id`](https://w3c.github.io/webauthn/#dom-registrationresponsejson-id) and [`AuthenticationResponseJSON.id`](https://w3c.github.io/webauthn/#dom-authenticationresponsejson-id) are modeled as `Base64URLString`s, but [`Credential.id`](https://w3c.github.io/webappsec-credential-management/#dom-credential-id) is already a `USVString` so it's a little bit weird to change the type to a `Base64URLString` since from my understanding only `ArrayBuffer`s should need to have their types changed. Are user agents expected to encode `id` again so that an RP receives a Credential ID that has been encoded twice or are user agents expected to know that the `USVString` is already a `Base64URLString` and send it as is? If the latter, it seems less confusing to just leave the type as a `USVString`. Anyway, one issue I have as an RP library writer is deciding which Credential ID to use. Since my library is focused on _strict_ conformance, I require all instances of Credential IDs to match instead of arbitrarily selecting one to use when they don't align. The more places Credential IDs exist the more likely there is disagreement. What is the motivation behind providing both `id` and `rawId`? They will be exactly the same, so why not remove one? I know at least one application that provides different values for `id` and `rawId` almost certainly by accident: the latter is double encoded first as base64URL then again base64. Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2119 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 12 August 2024 15:54:30 UTC