- From: Matthew Miller via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Aug 2024 05:18:18 +0000
- To: public-webauthn@w3.org
> Fair point. Though perhaps it's debatable which is worse under the principle of least surprise: `*ResponseJSON` _duplicating_ `id` as `rawId`, or `*ResponseJSON` _missing_ the `rawId` attribute from the `*Response` types they're supposed to be mirroring? > > I think I agree that correctness should override that concern, though: removing `*ResponseJSON.rawId` is better because it eliminates a possible source of inconsistency. > > @MasterKale What do you think? It has always been weird to me that `id` and `rawId` are always the same value. FIDO conformance requires RPs (and libraries that aim to become conformant) to check that both are present and equal to each other, but beyond that there is no practical reason to keep both values around. _However_, both values exist in `PublicKeyCredential` and afaik we're not considering trying to remove the redundancy here. I suggest it would become confusing for a JSON-serialized representation of a `PublicKeyCredential` to **omit** any value because there's nothing about the serialization process that suggests, "this value will be serialized and also optimized of redundancies." 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. It was never intended to address any of the issues higher up the type hierarchy about redundant values. I don't think it would help the adoption of the JSON serialization methods either if they became perceived as somehow "flawed" because people looked at the output and think, "this is missing `rawId`...what else might it not be serializing?" -- GitHub Notification of comment by MasterKale Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2119#issuecomment-2287875401 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 05:18:19 UTC