Web IDL support 3/N: response JSON serialization

[AlfioEmanueleFresta]

⚠️ AI-Assisted PR: This pull request was developed with the assistance of an AI coding agent (Claude Opus 4.5).

---

Summary

This PR is the second in a series (follows #138) and adds JSON serialization for WebAuthn responses - the inverse of the existing JSON request parsing functionality.

Changes

New Response Serialization Infrastructure

• Add WebAuthnIDLResponse trait - Provides to_json() and to_inner_model() methods for converting responses to JSON format
• Add JsonFormat enum - Supports both minified and prettified JSON output
• Add ResponseSerializationError - Error type for serialization failures

New JSON Response Models (per WebAuthn Level 3 spec)

• RegistrationResponseJSON - For MakeCredentialResponse serialization
• AuthenticationResponseJSON - For Assertion serialization
• AuthenticatorAttestationResponseJSON - Attestation response details
• AuthenticatorAssertionResponseJSON - Assertion response details
• AuthenticationExtensionsClientOutputsJSON - Extension output serialization

Request Structure Refactoring

Refactored MakeCredentialRequest and GetAssertionRequest to enable client data generation on-the-fly:

• Replaced hash: Vec<u8> with challenge: Vec<u8> - Store raw challenge instead of pre-computed hash
• Added origin: String field - Store origin explicitly
• Added cross_origin: Option<bool> field - Optional cross-origin flag
• Removed client_data: ClientData field - No longer needed as separate field
• Added helper methods:
  • client_data() - Builds ClientData internally
  • client_data_hash() - Computes SHA-256 hash on demand
  • client_data_json() - Returns JSON bytes for response serialization

Implementation Details

• Implemented WebAuthnIDLResponse for MakeCredentialResponse with full attestation object CBOR serialization
• Implemented WebAuthnIDLResponse for Assertion with signature and authenticator data handling
• Support for extension outputs: credProps, hmacCreateSecret, hmacGetSecret, largeBlob, prf
• Added Serialize derives to attestation statement types for CBOR encoding

Updated Files

• All example files updated to use new request structure
• All test files updated
• CTAP2 model conversions updated to use client_data_hash()
• U2F fallback code updated
• WebAuthn preflight logic updated

Testing

• All 85 existing tests pass
• New unit tests added for response serialization
• Updated webauthn_json_hid.rs example to demonstrate JSON response output

Example Usage

use libwebauthn::ops::webauthn::{WebAuthnIDLResponse, JsonFormat};

// After a MakeCredential operation
let response = channel.webauthn_make_credential(&request).await?;
let json = response.to_json(&request, JsonFormat::Prettified)?;
println!("{}", json);

// After a GetAssertion operation  
for assertion in &response.assertions {
    let json = assertion.to_json(&request, JsonFormat::Minified)?;
    println!("{}", json);
}

[AlfioEmanueleFresta]

@msirringhaus — Following up on your review comment on PR #138 regarding clientExtensionResults handling:

I investigated the WebAuthn Level 3 specification and found that clientExtensionResults is marked as required in both response types:

• RegistrationResponseJSON: required AuthenticationExtensionsClientOutputsJSON clientExtensionResults;
• AuthenticationResponseJSON: required AuthenticationExtensionsClientOutputsJSON clientExtensionResults;

This matches the behavior observed on demo.yubico.com, which always returns "clientExtensionResults": {} even when no extensions produce output.

So the current implementation in this PR is correct — we always include clientExtensionResults (as an empty object {} if no extensions produced output). The two cases you mentioned:

1. Extensions absent in request → Response includes "clientExtensionResults": {}
2. Extensions present but empty (extensions: {}) → Response includes "clientExtensionResults": {}

Both cases result in the same output per the spec, since clientExtensionResults is always required.

---

This comment was written by GitHub Copilot (Claude) operating on @AlfioEmanueleFresta's instructions.

[msirringhaus]

Looking good to me. Some minor comments and questions inline.

[msirringhaus]

Is it intentional to 'reimplement' this, instead of exposing a serde_json-Value, which the user can then use and format according to whatever serde_json offers?
I don't have a strong preference for either way, just wanting to understand the reasoning better, if there is any.

[AlfioEmanueleFresta]

I am of two minds. Returning a Value, the caller would need add a dependency on serde_json for something as trivial as formatting. Furthermore, as JSON is in a way a technical detail of WebAuthn IDL, I feel like it should be encapsulated within libwebauthn.

Other than formatting, do we envision any other valid use case where the caller should be manipulating the JSON response?

[msirringhaus]

serde_json is in the dependency tree anyways, since we pull it it, so adding it shouldn't really hurt users. But I get that it is weird/clunky to return a type that you can only work with, if you add another dependency (or if we re-export some of serde_json).

I'm not sure about manipulating the JSON, but maybe reading? Esp. extensions? But I'm not sure right now.

I'm fine with the way it is right now, I was just curious.

[AlfioEmanueleFresta]

I agree with you, I'm thinking it would be best to have both methods available, eg. to_json_value as well as a convenience method to_json_string. Let's do this in a follow-up diff.

[iinuwa]

Overall, this looks good. I agree with @msirringhaus's comments. Once those are cleaned up, we should merge this and start using it

[iinuwa]

I believe that I have properly rebased the code here and pushed it to the json-2a branch.

Sorry for the trouble :/

[AlfioEmanueleFresta]

Resolved most comments, and commented on two. Please take a look :)

@iinuwa thanks for fixing the conflicts! Updated this branch from your json-2a branch.

[msirringhaus]

lgtm!