- From: philomathic_life via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Aug 2024 13:45:48 +0000
- To: public-webauthn@w3.org
> It has always been weird to me that `id` and `rawId` are always the same value. Technically they are not the same: one is base64url encoded and the other is not. For this reason I find it less weird that they both exist. When a client wants the actual Credential ID, it's nice `rawId` exists; otherwise you'd have to decode `id`. Similarly when a client wants a base64URL-encoded Credential ID (perhaps to send to a server), it's nice `id` exists; otherwise you'd have to encode `rawId`. Personally, I still wouldn't have included both; but that ship has sailed. In the JSON-motivated definitions though, they are _actually_ the same (i.e., bit-for-bit identical). This means the same minor benefit does not exist. > The goal of the serialization methods was to reduce the complexity of transforming a response to `.create()` or `.get()` to help get it from the front end to the back end. Including both _increases_ the complexity though therefore contradicting the goal: now RPs have to verify both fields exist and are identical. Regardless, this is not a hill I'm willing to die on; but I do feel more strongly that `id` should be changed to `DOMString`/`USVString`. -- GitHub Notification of comment by zacknewman Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2119#issuecomment-2288804109 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 14 August 2024 13:45:49 UTC