[GH-ISSUE #8423] [Feature] Capture WebAuthn/passkey ceremony metadata without retaining credential secrets #6598

New issue

Open

opened 2026-11-01 21:12:34 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-01 21:12:34 +00:00

Owner

Originally created by @jayykernel on GitHub (Nov 1, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8423

Problem

Modern web applications increasingly use WebAuthn/passkeys for registration and authentication. A reverse-engineering investigation can observe the surrounding JavaScript and HTTP requests, but currently lacks a structured, privacy-safe view of the browser-side WebAuthn ceremony: relying-party identity, operation type, authenticator selection and the relationship between a ceremony and its resulting network exchange.

Proposed outcome

Add an opt-in, passive WebAuthn metadata view for an explicitly selected browser target.

Record whether the observed operation is credential creation or assertion.
Capture non-secret option metadata such as RP ID, user-verification requirement, resident-key policy, authenticator attachment, transport hints and supported algorithm identifiers when available.
Preserve the browser target, origin, timestamp and correlation to the relevant page/network events.
Represent unavailable, browser-redacted and unsupported fields explicitly; do not infer server acceptance from a successful browser API call.
Support a summary of repeated ceremonies and differences between observed registration/login flows.

Safety and privacy boundary

Never retain credential private keys, raw attestation objects, authenticator responses, client-data challenge values, user handles, access tokens or other credential-bearing payloads. Do not invoke WebAuthn APIs, create credentials, prompt an authenticator, or replay a ceremony. Collection must be passive and opt-in, with sensitive identifiers redacted or represented only by safe structural metadata.

Acceptance criteria

Owned fixtures cover create/get operations, missing optional fields, multiple algorithms, and browser-redacted values.
Output distinguishes observed browser options from inferred application/server behavior.
CLI/MCP Evidence includes target/origin provenance and partial-coverage reasons.
Tests prove that challenge values, credential IDs, attestation/assertion bytes and user handles are not retained.
Documentation describes supported Chromium/provider versions and the privacy boundary.

Scope

A narrowly scoped browser reverse-engineering capability related to the website roadmap (#774). It does not implement an authenticator, bypass authentication, or recover credentials.

Originally created by @jayykernel on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8423 ## Problem Modern web applications increasingly use WebAuthn/passkeys for registration and authentication. A reverse-engineering investigation can observe the surrounding JavaScript and HTTP requests, but currently lacks a structured, privacy-safe view of the browser-side WebAuthn ceremony: relying-party identity, operation type, authenticator selection and the relationship between a ceremony and its resulting network exchange. ## Proposed outcome Add an opt-in, passive WebAuthn metadata view for an explicitly selected browser target. - Record whether the observed operation is credential creation or assertion. - Capture non-secret option metadata such as RP ID, user-verification requirement, resident-key policy, authenticator attachment, transport hints and supported algorithm identifiers when available. - Preserve the browser target, origin, timestamp and correlation to the relevant page/network events. - Represent unavailable, browser-redacted and unsupported fields explicitly; do not infer server acceptance from a successful browser API call. - Support a summary of repeated ceremonies and differences between observed registration/login flows. ## Safety and privacy boundary Never retain credential private keys, raw attestation objects, authenticator responses, client-data challenge values, user handles, access tokens or other credential-bearing payloads. Do not invoke WebAuthn APIs, create credentials, prompt an authenticator, or replay a ceremony. Collection must be passive and opt-in, with sensitive identifiers redacted or represented only by safe structural metadata. ## Acceptance criteria - [ ] Owned fixtures cover create/get operations, missing optional fields, multiple algorithms, and browser-redacted values. - [ ] Output distinguishes observed browser options from inferred application/server behavior. - [ ] CLI/MCP Evidence includes target/origin provenance and partial-coverage reasons. - [ ] Tests prove that challenge values, credential IDs, attestation/assertion bytes and user handles are not retained. - [ ] Documentation describes supported Chromium/provider versions and the privacy boundary. ## Scope A narrowly scoped browser reverse-engineering capability related to the website roadmap (#774). It does not implement an authenticator, bypass authentication, or recover credentials.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#6598

No description provided.

Rows
Columns