specs/auth/oob/request/v0_1/payload
library
Classes
-
Payload
-
A starter asks a service to open an out-of-band request that an approver will
decide on another device. The document is issued and signed by the starter's fresh
Ed25519 key, which is fixed for the life of the request. The outer document members
(id, type, issuer, recipient, issuedAt, expiresAt, proof) are owned by the
framework — SPEC §6.3.
-
Response
-
The handle of the new request and its claim deadline. The starter builds the
trigger link from these and the service's DID.
Extension Types
-
Mode
-
How the request reaches the approver. A CLOSED list. Version 0.1 defines
scan:
the starter shows a trigger link (as a QR code that is also a clickable link,
TRIGGER-LINK.md) and the approver's wallet reads it. code (a typed code of at
least 8 characters, under strict rate limits) and push (sent to the approver's
enrolled devices) are reserved names.
-
Purpose
-
What the request is for. A CLOSED list: each purpose has a fixed row in
CONVENTIONS.md §3 stating what is revealed at each step, what the grant contains,
what redeem returns and the window lengths. Version 0.1 defines
login only.
stepUp and deviceEnrol are reserved names; adding one is a new version of this
component and of every task that references it, never an in-place edit.
Typedefs
-
Ext
= Map<String, dynamic>
-
Vendor-namespaced extension object per SPEC.md §4.5.1. Each immediate key MUST be a
reverse-DNS namespace; structure under each namespace is opaque to the framework.
-
RequestId
= String
-
The service-generated handle of one request: 16 to 32 bytes from a
cryptographically secure random source, written as unpadded base64url (22 to 43
characters; 16 bytes, 22 characters, is RECOMMENDED). It is also the nonce of the
exchange, so the family needs no separate challenge, and it is the
_id of the
trigger link (VTI-LNK-033). Compared as a string. It confers no authority on its
holder.