- From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Jul 2024 13:19:22 +0000
- To: public-webauthn@w3.org
Without judgement of the proposed errors, some spec formalia: currently, most WebAuthn errors are instances of [`DOMException`](https://webidl.spec.whatwg.org/#idl-DOMException) with different [names](https://webidl.spec.whatwg.org/#dfn-error-names-table). The `DOMException` names table section of the WebIDL spec states that: >When [creating](https://webidl.spec.whatwg.org/#dfn-create-exception) or [throwing](https://webidl.spec.whatwg.org/#dfn-throw) a [DOMException](https://webidl.spec.whatwg.org/#idl-DOMException), specifications must use one of these names. If a specification author believes none of these names are a good fit for their case, they must [file an issue](https://github.com/whatwg/webidl/issues/new?title=DOMException%20name%20proposal) to discuss adding a new name to the shared namespace [...] So if we're going to continue using `DOMException` for all of these errors (I currently don't know any arguments for nor against it), we may need to pick from the already existing names, or generalize the error names enough that they can be upstreamed and useful in other contexts. Fortunately, [`TimeoutError`](https://webidl.spec.whatwg.org/#timeouterror) already exists, and [`OptOutError`](https://webidl.spec.whatwg.org/#optouterror) seems like a suitable match for `UserCancelledError`. The others are trickier to find existing matches for, though. As summarized in #2047 (thanks!), the errors we already use are `AbortError`, `ConstraintError`, `InvalidStateError`, `NotAllowedError`, `NotSupportedError`, `SecurityError` and `UnknownError` (hm, turns out `TypeError` is not a `DOMException` but a [simple exception](https://webidl.spec.whatwg.org/#dfn-simple-exception)). Adding `TimeoutError` and `OptOutError` to that, and removing deprecated names, the remaining ones are: - `DataCloneError`: The object can not be cloned. - `DataError`: Provided data is inadequate. - `EncodingError`: The encoding operation (either encoded or decoding) failed. - `HierarchyRequestError`: The operation would yield an incorrect node tree. - `InUseAttributeError`: The attribute is in use by another element. - `InvalidCharacterError`: The string contains invalid characters. - `InvalidModificationError`: The object can not be modified in this way. - `InvalidNodeTypeError`: The supplied node is incorrect or has an incorrect ancestor for this operation. - `NamespaceError`: The operation is not allowed by Namespaces in XML. - `NetworkError`: A network error occurred. - `NoModificationAllowedError`: The object can not be modified. - `NotFoundError`: The object can not be found here. - `NotReadableError`: The I/O read operation failed. - `OperationError`: The operation failed for an operation-specific reason. - `QuotaExceededError`: The quota has been exceeded. - `ReadOnlyError`: The mutating operation was attempted in a "readonly" transaction. - `SyntaxError`: The string did not match the expected pattern. - `TransactionInactiveError`: A request was placed against a transaction which is currently not active, or which is finished. - `VersionError`: An attempt was made to open a database using a lower version than the existing version. - `WrongDocumentError`: The object is in the wrong document. I don't think any of these are good matches for `HybridPrerequisitesError`, `UserHybridCancelError` or `UserVerificationError`. The only somewhat-applicable one would be `OperationError`, but only because it's so unspecific it could apply to anything. So maybe we need to use [`DOMException` derived interfaces](https://webidl.spec.whatwg.org/#idl-DOMException-derived-interfaces) for these errors? Maybe a `WebAuthenticationError` with an enum-like `DOMString cause` attribute, for example. -- GitHub Notification of comment by emlun Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2096#issuecomment-2233307689 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 17 July 2024 13:19:23 UTC