Skip to content

Unknown enum values throw ValueError instead of a library error #106

Description

@Firehed

Several backed enums are resolved with ::from() on values that originate from the authenticator or the wire. Any value outside the enum's declared cases throws a ValueError, which is neither a WebAuthnErrorInterface nor documented, so callers cannot catch it alongside the library's own errors.

Sites

Attestations\AttestationObject::__construct

$this->format = Format::from($decoded['fmt']);

Format declares 7 cases. Any other identifier — compound, or anything newly added to the IANA registry — throws ValueError.

This is the most consequential of the three, because it defeats a graceful path that already exists. AttestationObject::verify() has:

default => new LibraryUnsupported(),

which returns AttestationType::Uncertain and lets CreateResponse reject the registration cleanly at 7.1.24. That arm can only ever be reached by formats that are in the enum but unimplemented (android-key, android-safetynet, tpm). For anything outside the enum, the constructor has already thrown.

It also undercuts the README's guidance:

If you receive a RegistratonError from the library referencing 7.1.24 or insufficient attestation trustworthiness [...] please file an issue containing the registration data you were attempting to use

A user hitting an unrecognized format gets a ValueError instead, with no pointer to that guidance.

COSEKey::__construct

$keyType = COSE\KeyType::from($decodedCbor[self::INDEX_KEY_TYPE]);

KeyType declares only EllipticCurve = 2 and Rsa = 3; OctetKeyPair = 1 and Symmetric = 4 are present as comments. A credential using an OKP key (Ed25519) therefore throws ValueError rather than reporting an unsupported key type.

PublicKey\EllipticCurve::fromDecodedCbor

$curve = COSE\Curve::from($decoded[self::INDEX_CURVE]);

Same shape for a curve identifier outside 1-7.

Note

The lenient pattern already exists elsewhere in the library. Both response parsers do:

// "client platforms MUST ignore unknown values" -> tryFrom+filter
$transports = array_filter(array_map(Enums\AuthenticatorTransport::tryFrom(...), $response['transports']));

Switching these three sites to tryFrom() and routing null into the existing unsupported/error paths would make the behavior consistent and keep unknown values catchable.


This issue body was written by AI. The underlying findings were reviewed by a human.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions