diff --git a/CHANGELOG.md b/CHANGELOG.md
index 4639f1a..e0d7b49 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -66,6 +66,9 @@ Keep a Changelog, and releases use semantic versioning.
   2.0, SAML, LDAP, and SCIM contracts, and cite independently opened
   official records in `docs/REFERENCES.md`. OAuth 2.1 is labeled an IETF
   Internet-Draft, not a final RFC.
+- Expanded accepted architecture decision record 0008 with APA 7th references
+  whose DOI or official catalog URL was opened from the IETF RFC Editor and
+  OpenID Foundation. Decision intent is unchanged.
 - Updated the design-only MCP authorization contract to MCP Authorization
   2026-07-28, RFC 9207 callback-issuer validation, and RFC 9068 JWT
   access-token header, claim, signature, and algorithm rejection evidence;
diff --git a/docs/adr/0008-keyverse-rp-authorization-boundary.md b/docs/adr/0008-keyverse-rp-authorization-boundary.md
index 51a65b7..0e33177 100644
--- a/docs/adr/0008-keyverse-rp-authorization-boundary.md
+++ b/docs/adr/0008-keyverse-rp-authorization-boundary.md
@@ -1,10 +1,30 @@
 # ADR-0008: Make Keyverse RP authorization explicit across non-fork applications
 
 **Status:** Accepted  
-**Date:** 2026-08-11
+**Date:** 2026-08-11  
+**Updated:** 2026-08-24
 
 ## Context
 
+OpenID Connect Core 1.0 defines a relying party as an OAuth 2.0 client that
+verifies the end user from tokens issued by an OpenID provider (Sakimura et
+al., 2023). JSON Web Token RFC 7519 requires recipients to validate the
+signed claims they consume (Jones, Bradley, & Sakimura, 2015). JWT BCP 225
+updates that guidance and requires audience checks when a JWT is intended for
+a specific recipient (Sheffer et al., 2020). The JWT profile for OAuth 2.0
+access tokens requires a resource server to reject a token whose `aud` does
+not identify that resource (Bertocci, 2021). Bearer tokens can be used by any
+party that possesses them (Jones & Hardt, 2012). NIST SP 800-63C-4 treats
+federation assertions as evidence for a separately administered relying party,
+not as an authorization decision inside that party's resources (Temoshok,
+Richer, et al., 2025).
+
+Those records specify authentication and token-acceptance rules. They do not
+grant authorization from a README listing, a shared GitHub organization, or a
+hardcoded routing claim. Identity attributes used for tenant binding are
+handled through purpose-bound access, encryption, and audit. This ADR does not
+claim NIST, IETF, or OpenID conformance.
+
 Keyverse is the ContextualWisdomLab identity hub, but an application does not
 inherit that trust merely because it is listed in the Keyverse README or lives
 in the same GitHub organization. The ecosystem RPs are separate, non-fork
@@ -169,3 +189,28 @@ link its exact issuer/audience/JWKS configuration, claim mapping, ABAC/RBAC
 tests, cross-tenant denial tests, and production-mode configuration. Until
 that evidence exists, the app's status is `planned`, `gap-not-claimed`, or
 `deployment-restricted`, never `authorization-ready`.
+
+## References
+
+Bertocci, V. (2021). *JSON Web Token (JWT) profile for OAuth 2.0 access tokens*
+(RFC 9068). Internet Engineering Task Force. https://doi.org/10.17487/RFC9068
+
+Jones, M., Bradley, J., & Sakimura, N. (2015). *JSON Web Token (JWT)*
+(RFC 7519). Internet Engineering Task Force. https://doi.org/10.17487/RFC7519
+
+Jones, M., & Hardt, D. (2012). *The OAuth 2.0 authorization framework: Bearer
+token usage* (RFC 6750). Internet Engineering Task Force.
+https://doi.org/10.17487/RFC6750
+
+Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., & Mortimore, C. (2023).
+*OpenID Connect Core 1.0 incorporating errata set 2*. OpenID Foundation.
+https://openid.net/specs/openid-connect-core-1_0.html
+
+Sheffer, Y., Hardt, D., & Jones, M. (2020). *JSON Web Token best current
+practices* (BCP 225, RFC 8725). Internet Engineering Task Force.
+https://doi.org/10.17487/RFC8725
+
+Temoshok, D., Richer, J., Choong, Y.-Y., Fenton, J., Lefkovitz, N.,
+Regenscheid, A., & Galluzzo, R. (2025). *Digital identity guidelines:
+Federation and assertions* (NIST SP 800-63C-4). National Institute of Standards
+and Technology. https://doi.org/10.6028/NIST.SP.800-63C-4
diff --git a/docs/adr/README.md b/docs/adr/README.md
index aad6a6a..9e10059 100644
--- a/docs/adr/README.md
+++ b/docs/adr/README.md
@@ -31,3 +31,11 @@ architecture on protected `main` yet.
 Create or update an ADR for changes to authenticator policy, federation hub ownership, identity matching evidence, merge/tombstone semantics, SCIM authority, directory write/trust policy, RP credential/claim ownership, desired-state mutation order, persistent state, secret handling, or autonomous/release authority.
 
 Each implementation PR should reconcile PRD/TRD/Architecture/UML/ERD/Threat/Test/Operability/Traceability and the relevant `docs/doctoring/`, `docs/papers/`, or `docs/operations/` research/standards/runbook record when those contracts move.
+
+Each accepted ADR now includes Context, Decision, Consequences, and an APA 7th
+References list. Citations use a DOI or official catalog URL opened from the
+IETF RFC Editor, OpenID Foundation, OASIS, NIST CSRC/nvlpubs, W3C, Keycloak
+documentation, or SLSA specification on 2026-08-24. The 2017 NIST SP 800-63B
+and SP 800-63C volumes named in `docs/papers/` are superseded by the July 2025
+SP 800-63B-4 and SP 800-63C-4 finals cited in these ADRs. Citations are
+standards evidence, not conformance claims.