Evidence record verifier

Loaded case: Valid record, signed. The example record signed with the published test key. Every step that can be checked passes, including the signature.

9 passed, 0 failed, 2 not checked.

1. Section 4Structure

   ✓Pass

   The record conforms to section 4.

   The payload is a JSON object with every required member of section 4, each of its stated type and with an allowed value. Members this version does not define are ignored.

2. Step 1Platform attestation

   –Not checked

   This page does not hold Apple's and Google's root certificates. The relying party's server performs this step.

   Verifies device.attestation.statement to Apple's or Google's root certificate and the attested app identifier.

3. Step 2Signature and key identifier

   ✓Pass

   The signature verifies with the public key entered, and device.keyId is that key's thumbprint.

   Verifies the ES256 signature with the public key the attestation binds and compares device.keyId with that key's JWK Thumbprint. This page uses the public key entered above in place of the attested key.

4. Step 3Audience

   ✓Pass

   audience equals the expected audience.

   Compares audience with the relying party's own registered identifier.

5. Step 4Nonce

   ✓Pass

   nonce equals the issued nonce.

   Compares nonce with the nonce the relying party issued. The relying party also confirms that no earlier record carried it; this page holds no list of earlier records.

6. Step 5Freshness

   ✓Pass

   issuedAt falls within the freshness window.

   Checks that issuedAt is no more than 300 seconds before the time of verification and no more than 60 seconds after it.

7. Step 6Registry response binding

   ✓Pass

   Every registry response carries its check's proof and outcome and the record's nonce and audience.

   Decodes each registryResponse and compares its proof and outcome with the check's, and its nonce and aud with the record's nonce and audience.

8. Step 6Registry response signature

   –Not checked

   This page does not hold the router's published keys. The relying party's server performs this step.

   Verifies each registryResponse against the router key its kid header names.

9. Step 7Attributes

   ✓Pass

   Every attribute is verified by a passing check that can verify it.

   Checks that each proof in an attribute's verifiedBy can verify that attribute and has a check in the record that passed.

10. Step 8Required checks

    ✓Pass

    Every check in the IAL2 steps the record claims passed.

    Rejects the record when a check the relying party's policy requires is absent or did not pass. Without that policy, this page applies the steps the record claims: when assurance.met is true for IAL2, every check in an IAL2 step must pass.

11. Step 9Assurance

    ✓Pass

    assurance.met agrees with the IAL2 step coverage of the checks that passed.

    Recomputes IAL2 step coverage from the checks that passed and compares it with assurance.met. The acceptance decision remains the relying party's.