LEARN. PRACTICE. GROW.Read the bytes protected by the signature
The exercise creates a temporary EC P-256 key and synthetic assertion data. The 37 authenticatorData bytes in this subset include the RP ID hash, flags and counter. The signed message combines those bytes with SHA-256 of the original clientDataJSON. OpenSSL performs ECDSA signing and verification; Python controls expected context and interprets results. No browser invokes navigator.credentials, no authenticator physically authorizes the operation, and no validated registration ceremony occurs. Observe the case where JSON is reformatted while preserving equivalent values. The binary representation changes, so the protected hash changes. Verifying a reconstruction instead of received bytes can break the cryptographic contract. The laboratory rejects that version with the old signature. The lesson is not to prohibit formatting every document; it is to identify which representation forms the authenticated message. Commands and output hashes are recorded while temporary keys and files are removed. These artifacts support repetition of the mechanism but do not establish physical key protection, FIDO conformance or the security of a complete product and its deployment.
Separate cryptographic validity from acceptance
A valid signature answers a question about a message and key. Acceptance additionally requires that the message match the operation and policy. In the exercise, the local registry binds registered-a to operator-a. Attempting to use that credential for operator-b fails before acceptance even without a mathematical signature problem. A different challenge, unapproved origin or another RP ID also invalidates the intended context. Do not derive credential ownership from an owner field submitted by the client. Run the legitimate example first, then each isolated change. Compare rejection reasons and confirm that the observed control is the intended one. The model supports only UP and UV and rejects formats outside its subset; it should not be promoted into a complete WebAuthn implementation. Backup flags, extensions, attestation and frames require additional work. This boundary matters to a technical manager: a local test can support acceptance of a specific correction without supporting readiness of the entire solution. Record what was executed, what was only researched, and what still needs exercises with actual components.
PKCE binds code exchange to the request
In the authorization-code flow, PKCE adds binding between the initial request and later exchange. With S256, the client retains a code_verifier and sends a derived challenge. A server accepting that challenge must require a match when the code is exchanged. A different verifier does not become legitimate because the code is recent or the parameter has the correct length. Current BCP guidance also addresses downgrade attacks: the relationship between an original challenge and acceptance of a verifier must remain consistent. For an integration project, include criteria covering actual server support, per-transaction generation, client correlation and behavior when parameters are missing. Avoid concentrating the entire assessment on the consent screen. For web clients with registered redirect URIs, exact comparison constrains permissible destinations; the specific native-application localhost port exception does not authorize generic prefix matching. These mechanisms complement one another but have different roles. This block’s signature laboratory operates neither an authorization server nor an OAuth exchange. The questions and analysis follow consulted standards and require subsequent validation in the chosen integration.
Token purpose and privacy of account linking
An ID Token communicates authentication information to a client; an access token serves a resource-access contract. Similar format or a common issuer does not authorize interchanging them. An API requiring an access token intended for itself should not accept a frontend ID Token merely because its signature verifies. Identify in the design who receives each artifact, which validation applies, and where authorization for the business operation is decided. Identifying a person across services also needs a contract. Pairwise pseudonymous identifiers may intentionally differ between RPs to limit correlation. A migration forcing equality through email can undo that property or create associations without sufficient evidence. Define necessity, authority, binding evidence and change handling before reconciling accounts. The same attribute presented in two contexts is not implicit authorization to merge data. For APS, the practical consequence is an inventory of integrations and owners responsible for linking, tests maintaining account separation, and a way to correct erroneous associations without confusing identity, sessions and permissions or treating one application’s identifier as universally authoritative.
Produce a reviewable exercise record
The laboratory report retains Python and OpenSSL versions, the script hash, executed commands, expected and observed results, and cleanup of temporary artifacts. There are two kinds of observation: actual cryptographic operations and decisions of the local model. Hashes help associate a record with an exercise version, but do not turn an editable report into immutable evidence. The assessor still needs to understand the method and boundary of the executed mechanism. The small desktop/mobile and v1/v2 selection demonstrates a purposeful rule. The full population yields four distinct objects; removing v2 reduces observed strata to two. Reversing input order does not change selected IDs. Repeating selection does not increase distinct objects either. Connect those outputs to the assessment plan instead of presenting them as measured statistical quality. Comparing the two runs should permit different random values and signatures while preserving criteria and semantic results. A different binary hash of an ECDSA signature is not by itself a regression. Define what should remain stable and what may vary before automating comparison of the evidence.
Prepare integration acceptance and support
Turn the analysis into decisions that responsible people can execute. For a fictional authentication integration, identify expected origin and RP ID, credential ownership, user-verification policy, required freshness, supported versions and recovery path. Associate each criterion with positive evidence, negative evidence and a known limitation. Define who decides when results disagree and which operations may continue when a higher-assurance requirement is unmet. This avoids a production handover where the support team knows only the generic message “login failed.” During review, distinguish control failure, test failure and missing coverage. An operation rejected because the environment never started does not validate its policy. Accepting a legitimate operation also does not prove rejection of improper combinations. Retain inconclusive outcomes and plan their resolution instead of counting them as successes. Handover should include rollback conditions, contacts and triggers for reassessment following relevant changes. These examples do not describe internal procedures at any particular bank. Documentation and local execution support better decisions while leaving enterprise exercises, independent specialist review and any psychometric inference about examination readiness outstanding.
python3 content/labs/cissp-assurance-contracts/run.py --output content/labs/cissp-assurance-contracts/learner-run.jsonA signed assertion from an unapproved origin is rejected; removing only origin comparison reveals a gap in the old suite.
Common pitfalls
Treating valid signatures as complete authorization; counting repeats as new samples; calling the teaching subset a FIDO implementation.
Related topics: WebAuthn and federation · Negative testing and sampling
Acceptance requires signature, context and evidence proportionate to the claim; conclusion strength depends on what was observed.
Reference: Web Authentication Level 3 · CISSP outline effective April 15, 2024; current AI guidance consulted 2026-09-29