Conceptual result schema
The example below illustrates possible semantics. It is not a production endpoint, response, or credential format.
{
"outcome": "verified | rejected | expired | unavailable",
"challengeId": "opaque-reference",
"purpose": "specific-requested-action",
"expiresAt": "RFC3339 timestamp",
"consumed": false
}Required security properties
- Authentication: approved relying services use server-held credentials.
- Context binding: a result cannot authorize an unrelated action.
- Freshness: a bounded validity window limits stale results.
- Replay protection: the same result cannot silently authorize repeated actions.
- Fail closed: unknown states never become approvals by default.
Response semantics
Distinguish verified outcomes from rejected, expired, malformed, rate-limited, and unavailable states. Retry only when appropriate; return user-readable recovery guidance without disclosing security internals.
Versioning
A future contract should specify stable versioning, an announced deprecation window, signed or mutually authenticated results where appropriate, and extensive negative-path contract tests.
These pages document reference architecture. They do not represent a live verification endpoint or substitute for production security review.