Consent and Data Request Protocol

Draft 0.1 — 2 August 2026
This document defines a product and protocol baseline. It is not a universal legal definition of consent, authorization, privacy compliance, or contractual permission.

Objective

ANUKA verification must be request-driven and person-controlled.

A verifier does not receive a participant’s or company’s full Passport. The verifier submits a structured request that explains:

• who is asking;
• which exact data or claims are requested;
• why each item is needed;
• whether each item is required or optional;
• whether raw data, a derived answer, or a credential is acceptable;
• who will receive the result;
• how long access or the result will remain valid;
• whether access is one-time or ongoing;
• whether the data may be stored, shared, or used for automated decisions.

The person or authorized organization representative can approve:

• all requested items;
• only selected items;
• a less revealing alternative;
• one-time access instead of ongoing access;
• a shorter duration;
• nothing.

The central rule is:

No verifier receives more data, for longer, or for a broader purpose than the holder deliberately authorizes.

Two authorization modes

ANUKA needs two related but distinct flows.

1. One-time presentation

Use when a verifier needs a snapshot or proof without ongoing API access.

Examples:

• prove that at least three verified product experiments were completed;
• prove that company MRR is above a threshold without disclosing the exact amount;
• present selected contribution credentials to a project steward;
• disclose a verified organization role;
• share a traction package with one investor for seven days.

Preferred interoperability path:

• OpenID for Verifiable Presentations;
• DCQL or another declared query format to identify requested credentials and claims;
• selective disclosure where the credential format supports it;
• signed presentation bound to the verifier, nonce, and transaction.

The verifier receives a presentation or derived proof, not an access token for the underlying data source.

2. Delegated API access

Use when a product or verifier needs time-limited access to a protected API.

Examples:

• allow an investor data room to refresh selected traction metrics for 14 days;
• allow an auditor to query named evidence packages;
• allow a resident product to read selected Passport claims while an application is active;
• allow a dashboard to retrieve one company’s public and permissioned quality records;
• allow an AI agent to inspect selected data for one declared task.

Preferred interoperability path:

• OAuth authorization code flow;
• PKCE for public clients;
• OAuth Rich Authorization Requests using authorization_details;
• Pushed Authorization Requests for sensitive or large requests;
• exact redirect URI matching;
• short-lived, audience-restricted access tokens;
• sender-constrained tokens where risk justifies it;
• explicit revocation and grant management.

Roles

Requesting Client

The application, company, product, investor portal, verifier, or agent requesting data or proof.

Authorization Server

The ANUKA or compatible service that authenticates the holder, presents the request, records the decision, and issues the resulting authorization or presentation request response.

Holder

The person or authorized organization representative controlling the Passport, credential, or permissioned data.

Resource Server

The API or evidence service that holds protected data and enforces the granted authorization.

Verifier

The party relying on a presentation, credential, proof, API response, or verification result.

Data Subject

The person or organization to which the requested information relates. The holder and data subject may differ.

Policy Authority

The person, company, resident product, or network governance process that defines whether the holder is permitted to share the requested data.

Request object

Every request MUST be machine-readable and renderable in plain language.

A request SHOULD include:

{
  "request_id": "req_01J...",
  "client_id": "client_investor_room_123",
  "client_name": "Example Capital Data Room",
  "subject": "anuka:company:acme",
  "purpose": {
    "code": "investment_due_diligence",
    "description": "Evaluate the company for a potential seed investment"
  },
  "decision_context": {
    "type": "investment_review",
    "automated_decision": false
  },
  "authorization_details": [
    {
      "type": "anuka_data_request",
      "item_id": "mrr_band",
      "resource": "traction_passport",
      "claim": "monthly_recurring_revenue",
      "actions": ["present"],
      "required": true,
      "acceptable_disclosures": ["exact", "band", "threshold"],
      "requested_disclosure": "band",
      "source_requirements": ["stripe_connected"],
      "freshness": "P7D"
    },
    {
      "type": "anuka_data_request",
      "item_id": "retention_trend",
      "resource": "traction_passport",
      "claim": "customer_retention_trend",
      "actions": ["present"],
      "required": false,
      "requested_disclosure": "trend_only",
      "freshness": "P30D"
    }
  ],
  "audience": ["https://dataroom.example"],
  "access_mode": "one_time_presentation",
  "expires_at": "2026-08-09T12:00:00Z",
  "retention": "P30D",
  "onward_sharing": "prohibited",
  "policy_url": "https://dataroom.example/privacy",
  "terms_url": "https://dataroom.example/terms"
}

The authorization server MUST reject unknown request types, malformed fields, unsupported actions, invalid audiences, or requests that conflict with policy.

Required request semantics

Identity of requester

The consent screen must show the verified client identity, not merely a display name supplied in a redirect URL.

Show:

• legal or operating name;
• product name;
• verified domain;
• network status;
• client registration status;
• contact and policy links;
• whether the requester is acting for another party.

Purpose

Purpose must be specific enough for a person to understand the expected use.

Good:

• “Verify eligibility for the Acme beta-testing bounty.”
• “Evaluate the company for a seed investment.”
• “Confirm that the contributor completed two production releases.”

Bad:

• “Improve services.”
• “Business purposes.”
• “AI and analytics.”

A verifier MUST NOT reuse a grant for a materially different purpose without a new request.

Requested items

Each item must be separately understandable and selectable unless technical or policy dependencies require grouping.

For every item show:

• human-readable label;
• reason requested;
• required or optional status;
• source and verification level;
• requested precision;
• freshness requirement;
• intended audience;
• retention and onward-sharing rules;
• consequences of denial, stated without coercion.

Required versus optional

A client may label an item required only when the client will not proceed without it.

Optional items must be off by default unless the holder has a clearly established preference and the interface still makes the selection obvious.

The interface must not disguise optional collection as required.

Disclosure alternatives

A holder should be able to provide the least revealing answer that satisfies the request.

Examples:

• MRR > $10,000 instead of exact MRR;
• “verified U.S. entity” instead of formation documents;
• “completed 5–9 accepted experiments” instead of the full work history;
• “retention increased” instead of customer-level data;
• a capability credential instead of every supporting work record.

If the requester does not accept an alternative, the UI must explain that before authorization.

Consent interface

The primary screen should resemble a high-quality OAuth authorization screen, but with field-level controls.

Header

Example Capital is requesting access to selected ANUKA data

Show requester identity and purpose immediately.

Selection controls

Use grouped rows with independent controls:

• Allow all requested data
• Choose data
• per-item checkboxes or toggles;
• disclosure selector where alternatives exist;
• duration selector for ongoing access;
• one-time versus recurring choice where both are supported.

The user must be able to switch from “Allow all” to a granular view before confirming.

Summary before approval

Before the final action, show:

• number of approved items;
• exact audience;
• duration;
• whether ongoing refresh is enabled;
• whether the requester may store the result;
• whether onward sharing is allowed;
• whether automated decision-making is declared;
• how to revoke access.

Actions

Recommended actions:

• Allow selected
• Allow all
• Deny
• Review later

Avoid manipulative button hierarchy or shame language.

Partial approval

Partial approval is a first-class outcome, not an error.

OAuth Rich Authorization Requests explicitly allow the resource owner to grant a subset of requested authorization details. ANUKA adopts that behavior as the default for data requests.

The resulting token, presentation, or consent receipt MUST contain only the granted subset.

The client must be able to distinguish:

• item granted;
• item denied;
• item unavailable;
• alternative disclosure granted;
• request expired;
• holder deferred the request.

The client must not infer that an unreturned optional item is false.

Grant object

A grant SHOULD record:

{
  "grant_id": "grant_01J...",
  "request_id": "req_01J...",
  "holder": "anuka:person:123",
  "subject": "anuka:company:acme",
  "client_id": "client_investor_room_123",
  "purpose": "investment_due_diligence",
  "granted_authorization_details": [
    {
      "item_id": "mrr_band",
      "claim": "monthly_recurring_revenue",
      "disclosure": "band",
      "actions": ["present"],
      "audience": ["https://dataroom.example"]
    }
  ],
  "issued_at": "2026-08-02T12:00:00Z",
  "expires_at": "2026-08-09T12:00:00Z",
  "revocable": true,
  "status": "active"
}

A grant is not itself proof that the underlying data is true. It records permission.

Consent receipt

The holder SHOULD receive a durable receipt after every decision.

The receipt should include:

• requester;
• purpose;
• requested items;
• granted items;
• denied items;
• alternatives chosen;
• duration and audience;
• retention statement;
• policy versions;
• timestamp;
• revocation link;
• request and grant identifiers.

The receipt may be signed for integrity, but sensitive consent content should not be published onchain.

One-time presentation flow

1. The verifier creates a signed presentation request.
2. The request states purpose, claims, formats, audience, nonce, and expiry.
3. The holder opens the request in ANUKA or a compatible wallet.
4. ANUKA resolves matching credentials and evidence.
5. The holder selects credentials and individual claims.
6. ANUKA shows the exact disclosure preview.
7. The holder approves, denies, or defers.
8. ANUKA creates a verifier-bound presentation.
9. The verifier validates signature, audience, nonce, status, expiry, and policy.
10. The holder receives a receipt and can inspect request history.

The verifier must not treat absence of a claim as evidence that the claim is false.

Delegated API flow

1. The client creates a Rich Authorization Request.
2. For sensitive or large requests, the client pushes it to the authorization server using PAR.
3. The authorization server authenticates the holder.
4. The server validates client identity, request schema, policy, and resource ownership.
5. The consent UI renders all requested items.
6. The holder grants all, a subset, alternatives, or nothing.
7. The server issues an authorization code bound to PKCE.
8. The client exchanges the code for a short-lived token.
9. The token contains or resolves to only the granted authorization_details.
10. The resource server enforces audience, action, item, subject, purpose, and expiry.
11. The holder can revoke the grant from ANUKA.
12. The client loses access immediately or within a declared revocation propagation window.

Security profile

ANUKA implementations MUST follow the current OAuth Security Best Current Practice.

Minimum requirements:

• authorization code flow;
• PKCE for public clients;
• no implicit grant for new implementations;
• no resource-owner-password grant;
• exact redirect URI matching;
• state and issuer validation;
• short-lived access tokens;
• audience restriction;
• least-privilege authorization details;
• one-time authorization request references where used;
• PAR for requests containing sensitive details;
• signed request objects where integrity requires it;
• refresh-token rotation or sender constraint where refresh tokens are issued;
• secure token storage;
• clickjacking protection on authorization screens;
• no sensitive request details in analytics, referrers, or logs.

High-risk clients SHOULD use DPoP or another suitable sender-constrained-token mechanism.

Duration and access types

Every request must specify one access type.

One-time

One presentation or one API retrieval. No refresh token.

Session

Valid for the current authenticated session or a short declared window.

Time-limited recurring

The client may refresh approved data until a fixed expiry.

Event-limited

Valid until a named event occurs, such as application closure, bounty completion, or diligence termination.

Standing access

Long-lived access requiring stronger justification, visible grant management, periodic reauthorization, and explicit organization policy.

Standing access is not an MVP default.

Revocation and grant management

Every holder needs a Connected Access page showing:

• active clients;
• purpose;
• approved data;
• last access time;
• expiry;
• refresh capability;
• onward-sharing policy;
• revoke control;
• request history;
• suspicious-access reporting.

The holder should be able to:

• revoke the full grant;
• revoke selected items where supported;
• shorten duration;
• disable refresh;
• replace exact disclosure with a less precise presentation when policy allows;
• request deletion from the client where applicable;
• see when a client last accessed the resource.

Revocation of future access does not automatically erase a presentation or data lawfully received earlier. The consent screen must explain the difference.

Organization-controlled data

A person may not have unilateral authority to share company data.

Before approval, ANUKA must resolve:

• organization role;
• delegated data-sharing authority;
• whether multiple approvals are required;
• whether the request exceeds a steward’s mandate;
• whether the data belongs to customers, employees, or third parties;
• whether contractual restrictions apply.

Sensitive company requests may require:

• founder or officer approval;
• data-owner approval;
• dual control;
• legal or finance review;
• investor data-room policy;
• audit logging.

The consent UI must show whether the person is authorizing for themselves or on behalf of an organization.

Requests to AI agents

An AI agent may prepare or explain a request, but it must not silently expand it.

For agent-originated requests show:

• accountable principal;
• agent identity and version;
• task;
• requested tools and data;
• whether raw data enters a model context;
• model/provider role;
• retention and training policy;
• planned output audience;
• whether the agent may take actions or only analyze.

An agent must receive only the granted subset and must not use prior access for a new purpose.

High-impact decisions

Requests used for employment, credit, housing, insurance, education, investment eligibility, or similar consequential decisions need enhanced safeguards.

The request must disclose:

• decision category;
• legal or contractual basis;
• required versus optional data;
• whether automation is used;
• whether a human reviews the result;
• contest and correction process;
• adverse-action or explanation obligations where applicable.

Consent alone does not make an unlawful, discriminatory, inaccurate, or unfair decision process acceptable.

Anti-patterns

ANUKA clients MUST NOT:

• request an entire Passport when named claims would suffice;
• use broad scopes such as passport.read_all for ordinary verification;
• preselect optional sensitive data;
• hide purpose in generic policy text;
• request indefinite access without a specific need;
• combine unrelated purposes in one consent screen;
• treat denial as evidence of dishonesty;
• punish a holder for choosing a supported privacy-preserving alternative;
• reuse data for training, advertising, resale, or profiling without explicit authorization and a valid legal basis;
• request credentials directly through an untrusted iframe;
• bypass the authorization server by asking users to upload secrets or raw exports;
• write sensitive consent receipts or raw personal data to a public blockchain.

MVP authorization detail types

The first public registry should remain small.

Recommended initial types:

• anuka_identity_claim
• anuka_organization_role
• anuka_capability_credential
• anuka_contribution_summary
• anuka_work_record
• anuka_traction_metric
• anuka_quality_evidence
• anuka_attestation_status
• anuka_data_room_access

Each type needs:

• JSON Schema;
• human-readable rendering rules;
• allowed actions;
• disclosure alternatives;
• source requirements;
• sensitivity classification;
• default maximum duration;
• audit requirements;
• test vectors.

MVP acceptance criteria

The protocol is ready for first implementation only when:

• every request shows verified requester identity and purpose;
• every data item is individually selectable unless a documented dependency exists;
• Allow selected, Allow all, and Deny are supported;
• optional fields are not preselected;
• one-time presentation works without ongoing API access;
• delegated API access uses authorization code plus PKCE;
• the issued token contains only the granted subset;
• Connected Access shows active grants and supports revocation;
• receipts record what was requested and granted;
• denied items are not represented as negative facts;
• organization authority is checked server-side;
• sensitive requests use PAR or equivalent integrity-protected request handling;
• no universal passport.read_all scope is required;
• consent and access logs exclude unnecessary sensitive values;
• privacy and legal notices match actual production behavior.

Sources

• RFC 9396 — OAuth 2.0 Rich Authorization Requests
• RFC 9700 — Best Current Practice for OAuth 2.0 Security
• RFC 9126 — OAuth 2.0 Pushed Authorization Requests
• RFC 9101 — JWT-Secured Authorization Request
• RFC 7636 — Proof Key for Code Exchange
• RFC 7009 — OAuth 2.0 Token Revocation
• RFC 7662 — OAuth 2.0 Token Introspection
• RFC 9449 — OAuth 2.0 Demonstrating Proof of Possession
• OpenID for Verifiable Presentations 1.0
• W3C Verifiable Credentials Data Model v2.0

Verification record

• Sources opened and checked: 2 August 2026
• OAuth baseline: RFC 9700 plus authorization code and PKCE
• Fine-grained authorization baseline: RFC 9396
• Presentation baseline candidate: OpenID4VP 1.0 Final
• Legal review required for high-impact decisions and organization-controlled data: Yes