- From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Aug 2024 18:02:41 +0000
- To: public-webauthn@w3.org
> That is why I created the now-closed issue talking about `Credential.id` being a `USVString`. If we change it to a `DOMString`, [...]
"We" the WebAuthn working group cannot change it, because it's defined in a different spec. You're welcome to bring the issue to the [Web Application Security Working Group](https://github.com/w3c/webappsec-credential-management) as noted in #2118, but it's off topic for this working group.
> I'm confused about what a breaking change is.
I haven't seen a hard definition, but broadly it's about whether existing implementations of the three participants: authenticators, clients and RPs, would remain compatible if one, but not all, participants make the change in question. For example, removing `rawId` would make L3 client implementations incompatible with existing RP implementations that use it. Indeed this is mostly concerned with compatibility between mature ("Candidate Recommendation" or higher) specifications, and breaking changes within "Working Draft" state are more allowable. But in reality, implementations sometimes launch before the spec is mature, so in practice it's a matter of consensus in the Working Group on how much would break and whether that's a problem.
I don't know how the decision was made in #412, as that was long before the L1 release, so there wasn't a mature spec to break. I would assume there may have been objections against breaking existing prototype implementations and that the benefit wasn't considered worth it.
> I'm not advocating for `id` or `rawId` to be removed from `PublicKeyCredential` but only the _JSON_-motivated definitions which don't exist in any of the previous published specs.
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?
--
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2119#issuecomment-2284615983 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 18:02:42 UTC