Chapter 05 · Tabs

Prove control, constrain the answer

The smallest request in the app, and the one that introduces constraints: who may answer, and until when.

FIGURE 5.1 · AuthenticationRequestDetails and its three constraint types.

What the request asks

"Prove you control this identity, by signing my challenge." The request itself is small: a request id so you can match the answer, an optional expiry so a leaked QR stops working, and optional recipient constraints so only a particular identity, system, or parent may answer.

The route

const details = new AuthenticationRequestDetails({
  requestID: CompactIAddressObject.fromAddress(params.requestId),
  recipientConstraints,                                  // optional, one constraint
  expiryTime: params.expiryTime != null ? new BN(params.expiryTime) : undefined
});
return buildGenericRequestFromDetails({
  details: [new AuthenticationRequestOrdinalVDXFObject({ data: details })],
  signed: true, signingId, redirects
}, isTestnet);

Constraints are validated against exactly three values — REQUIRED_ID (1), REQUIRED_SYSTEM (2), REQUIRED_PARENT (3). Anything else is a 400 with an explicit message. The app supports one constraint per request; the primitive supports an array.

Where the answer goes

The wallet signs and returns a Response to the configured response URI. There is no server-side verification in this tab — the redirect/POST URI is yours to handle, and the app returns it in the request exactly as configured.

Reading the code

src/routes/requests/authentication.ts
  parseRecipientConstraints()   # validates 1/2/3
  buildAuthRequest()
  generateAuthQr()