317300 2026-06-17 07:24:39 -0700 Digital Credentials: validation failures are silently dropped instead of throwing a classified exception (TypeError / OperationError) 2026-07-13 20:42:54 -0700 1 1 1 Unclassified WebKit WebCore Misc. WebKit Nightly Build Unspecified Unspecified NEW InRadar P2 Normal --- 268516 1 marcosc webkit-unassigned webkit-bug-importer oldest_to_newest 2221569 0 marcosc 2026-06-17 07:24:39 -0700 The Digital Credentials spec change in w3c-fedid/digital-credentials#515 ("Classify validation failures into specific exception types") updates the "Validate credential requests" algorithm so that a validation failure throws a specific exception: a TypeError when the request data is malformed or invalid, otherwise an "OperationError" DOMException. The fail-fast contract is unchanged; #515 only pins down the exception type. WebKit does not implement this. In DigitalCredentials::validateRequests (Source/WebKit/WebProcess/cocoa/IdentityDocumentServices/DigitalCredentialsRequestValidatorBridge.mm), each request is validated in a loop; on a validation failure the code adds a console warning ("An error occurred validating the incoming 'org-iso-mdoc' request. The request will be ignored."), then drops that request and continues. The function returns a plain Vector<ValidatedMobileDocumentRequest> (not an ExceptionOr), so it has no channel to surface a validation-failure exception at all. DigitalCredentialsCoordinator::validateAndParseDigitalCredentialRequests wraps the plain vector into a successful result. This means a request set with some invalid entries silently proceeds with a partial set, and a set where every entry fails validation returns an empty vector that is then treated as success: bug 314382 (the missing empty-vector guard) tracks that empty-vector case. Note: the TypeError/NotAllowedError exceptions currently thrown in DigitalCredential::discoverFromExternalSource belong to the earlier "Initiate the credential request"/binding layer (permissions policy, focus, visibility, IDL/JSON conversion, "at least one request"), not to the per-request "Validate credential requests" step that #515 governs. Proposed fix (the plumbing already supports it): the client interface validateAndParseDigitalCredentialRequests already returns ExceptionOr<Vector<...>>, and CredentialRequestCoordinator::prepareCredentialRequests already rejects the promise with releaseException(). Change DigitalCredentials::validateRequests to return ExceptionOr<...> and, on the platform validator's failure, return a TypeError (malformed/invalid request data) or an "OperationError" DOMException (otherwise) per the #515 switch, instead of logging-and-dropping. Spec PR: https://github.com/w3c-fedid/digital-credentials/pull/515 Spec issue: https://github.com/w3c-fedid/digital-credentials/issues/472 2221570 1 webkit-bug-importer 2026-06-17 07:24:46 -0700 <rdar://problem/179927860>