Consent and Data Access Source Pack

Source pack version 0.1 — verified 2 August 2026
This source pack supports the ANUKA Consent and Data Request Protocol. It records technical baselines, not a universal legal conclusion that a given authorization flow constitutes valid consent in every jurisdiction or context.

Status labels

Normative baseline — selected stable protocol or best-current-practice baseline.
Implementation reference — stable standard used when its feature is required.
Interoperability candidate — suitable for implementation profiling but not mandatory for every ANUKA client.
Legal watch — official guidance requiring context-specific legal review.

Core OAuth authorization

RFC 6749 — The OAuth 2.0 Authorization Framework

Publisher: IETF / RFC Editor
URL: rfc-editor.org/rfc/rfc6749
State: Foundational protocol reference
Used for: Authorization server, client, resource owner, authorization grant, access token, refresh token, authorization code, and resource-server roles.
ANUKA boundary: Later security requirements in RFC 9700 control new implementation choices where they update or deprecate older patterns.
Checked: 2 August 2026

RFC 9700 — Best Current Practice for OAuth 2.0 Security

Publisher: IETF / RFC Editor
Published: January 2025
URL: rfc-editor.org/rfc/rfc9700
State: Normative security baseline
Used for: Authorization-code security, PKCE, exact redirect URI matching, token restriction, sender-constrained tokens, refresh-token protections, mix-up defenses, and deprecation of insecure flows.
Key requirements adopted by ANUKA: No resource-owner-password grant; no implicit grant for new clients; least privilege; exact redirect URIs; PKCE for public clients.
Checked: 2 August 2026

RFC 7636 — Proof Key for Code Exchange

Publisher: IETF / RFC Editor
URL: rfc-editor.org/rfc/rfc7636
State: Normative public-client baseline
Used for: Binding authorization-code redemption to the client instance that initiated the flow.
Checked: 2 August 2026

Fine-grained requests and partial approval

RFC 9396 — OAuth 2.0 Rich Authorization Requests

Publisher: IETF / RFC Editor
Published: May 2023
URL: rfc-editor.org/rfc/rfc9396
State: Normative fine-grained authorization baseline
Used for: The authorization_details parameter, typed JSON authorization requirements, named actions and resources, storage of granted details, and returning granted details in token responses.
Critical support for ANUKA: The RFC explicitly notes that a user may grant a subset of requested authorization details.
ANUKA use: Every requested claim or data package can be rendered and approved independently, with alternatives such as exact, band, threshold, or derived proof.
Checked: 2 August 2026

RFC 8707 — Resource Indicators for OAuth 2.0

Publisher: IETF / RFC Editor
URL: rfc-editor.org/rfc/rfc8707
State: Implementation reference
Used for: Restricting authorization and tokens to intended resource servers.
Checked: 2 August 2026

Integrity-protected authorization requests

RFC 9126 — OAuth 2.0 Pushed Authorization Requests

Publisher: IETF / RFC Editor
URL: rfc-editor.org/rfc/rfc9126
State: Normative sensitive-request reference
Used for: Sending large or sensitive authorization requests directly to the authorization server and using a short-lived request_uri in the browser flow.
ANUKA use: Data requests containing detailed claim descriptions, purposes, audiences, or sensitive context should use PAR rather than expose the full request in the browser URL.
Checked: 2 August 2026

RFC 9101 — JWT-Secured Authorization Request

Publisher: IETF / RFC Editor
URL: rfc-editor.org/rfc/rfc9101
State: Implementation reference
Used for: Signed and optionally encrypted OAuth Request Objects that protect authorization parameters from tampering and substitution.
Checked: 2 August 2026

Token restriction and replay resistance

RFC 9449 — OAuth 2.0 Demonstrating Proof of Possession

Publisher: IETF / RFC Editor
URL: rfc-editor.org/rfc/rfc9449
State: High-risk implementation reference
Used for: Sender-constraining OAuth tokens with DPoP proofs to reduce misuse of stolen bearer tokens.
ANUKA use: Recommended for higher-risk delegated access, agent clients, and sensitive evidence APIs.
Checked: 2 August 2026

RFC 9068 — JWT Profile for OAuth 2.0 Access Tokens

Publisher: IETF / RFC Editor
URL: rfc-editor.org/rfc/rfc9068
State: Implementation reference
Used for: Interoperable JWT access-token claims including issuer, subject, audience, expiry, client, and authorization information.
ANUKA boundary: Opaque reference tokens remain valid where introspection and privacy requirements make them preferable.
Checked: 2 August 2026

RFC 7662 — OAuth 2.0 Token Introspection

Publisher: IETF / RFC Editor
URL: rfc-editor.org/rfc/rfc7662
State: Implementation reference
Used for: Resource servers checking whether a token is active and retrieving authorization context.
Checked: 2 August 2026

RFC 7009 — OAuth 2.0 Token Revocation

Publisher: IETF / RFC Editor
URL: rfc-editor.org/rfc/rfc7009
State: Normative revocation reference
Used for: Holder-initiated and client-initiated revocation of access and refresh tokens.
Important limitation: Revoking future access does not delete data or presentations already received by a client.
Checked: 2 August 2026

One-time credential presentation

OpenID for Verifiable Presentations 1.0

Publisher: OpenID Foundation
URL: openid.net/specs/openid-4-verifiable-presentations-1_0-final.html
Status: OpenID Final Specification, approved 10 July 2025
State: Normative presentation protocol candidate
Used for: Verifier requests, wallet-mediated selection, same-device and cross-device presentation flows, nonce and verifier binding, and credential-format negotiation.
Privacy support: The specification calls for sufficiently specific collection purpose and supports selective disclosure through claim queries.
ANUKA use: Preferred for one-time presentation when the verifier needs selected claims or credentials but no ongoing API access.
Checked: 2 August 2026

W3C Verifiable Credentials Data Model v2.0

Publisher: W3C
URL: w3.org/TR/vc-data-model-2.0
Status: W3C Recommendation, 15 May 2025
State: Normative credential data-model baseline
Used for: Issuer, holder, verifier, credential, presentation, purpose limitation, data minimization, and privacy concepts.
Critical limitation: Cryptographic verification does not establish that a claim is true, sufficient, or appropriate for a decision.
Checked: 2 August 2026

W3C Bitstring Status List v1.0

Publisher: W3C
URL: w3.org/TR/vc-bitstring-status-list
State: Normative credential-status reference
Used for: Privacy-conscious suspension and revocation status for credentials used in presentations.
Checked: 2 August 2026

Discovery and client metadata

RFC 8414 — OAuth 2.0 Authorization Server Metadata

Publisher: IETF / RFC Editor
URL: rfc-editor.org/rfc/rfc8414
State: Implementation reference
Used for: Publishing authorization, token, revocation, introspection, PAR, and supported-feature metadata.
ANUKA use: Advertise supported authorization-detail types and protocol capabilities.
Checked: 2 August 2026

RFC 7591 — OAuth 2.0 Dynamic Client Registration

Publisher: IETF / RFC Editor
URL: rfc-editor.org/rfc/rfc7591
State: Optional implementation reference
Used for: Client registration metadata where trusted dynamic onboarding is needed.
ANUKA boundary: The MVP may use reviewed static registration; dynamic registration requires policy and anti-abuse controls.
Checked: 2 August 2026

Adoption rules for ANUKA

A verifier requests named data or claims, not an entire Passport by default.
One-time presentation and ongoing API access are separate grant types.
RFC 9396 authorization_details is the baseline for field-level API authorization.
Partial approval is a normal successful result.
OpenID4VP is the preferred baseline candidate for wallet-mediated one-time presentations.
Sensitive authorization requests use PAR and, where needed, signed Request Objects.
Public clients use authorization code plus PKCE.
Tokens are audience-restricted, short-lived, and limited to the granted subset.
Revocation stops future access but does not falsely promise remote deletion of prior disclosures.
Consent receipts remain private and must not expose sensitive details on a public blockchain.
Technical authorization does not replace legal authority, organization policy, or data-subject rights.
High-impact decision requests require a separate legal and fairness review.

Verification record

Last manual validation: 2 August 2026
Selected OAuth security baseline: RFC 9700
Selected fine-grained authorization baseline: RFC 9396
Selected presentation candidate: OpenID4VP 1.0 Final
Next review: Before implementation freeze or within 90 days