diff --git a/spec/src/main/asciidoc/authenticationMechanism.asciidoc b/spec/src/main/asciidoc/authenticationMechanism.asciidoc
index 20fa6d0..69ebea8 100644
--- a/spec/src/main/asciidoc/authenticationMechanism.asciidoc
+++ b/spec/src/main/asciidoc/authenticationMechanism.asciidoc
@@ -14,7 +14,7 @@ In some cases (for example, username/password authentication) the interaction be
 
 The Jakarta EE Platform already specifies mechanisms for authenticating users of web applications. The Jakarta Servlet Specification, version 4.0 [https://jakarta.ee/specifications/servlet/4.0/[SERVLET40]] specifies a declarative mechanism for configuring an application to provide BASIC, DIGEST, FORM, or CERT authentication, with authentication performed automatically by the container based on the application's configuration, which, in the case of FORM authentication, can include custom form pages.
 
-In addition, [https://jakarta.ee/specifications/authentication/1.1/[JASPIC]] specifies a general-purpose mechanism for securing messages sent between Jakarta EE clients and servers. Jakarta Authentication defines an SPI called _ServerAuthModule_, which enables development of authentication modules to handle any credential type, or engage in interaction of arbitrary complexity with clients and third parties. [https://jakarta.ee/specifications/authentication/1.1/[JASPIC]] also defines the Servlet Container Profile, which specifies howJakarta Authentication mechanisms, including _ServerAuthModules_, are integrated with the servlet container.
+In addition, [https://jakarta.ee/specifications/authentication/1.1/[AUTHENTICATIONSPEC]] specifies a general-purpose mechanism for securing messages sent between Jakarta EE clients and servers. Jakarta Authentication defines an SPI called _ServerAuthModule_, which enables development of authentication modules to handle any credential type, or engage in interaction of arbitrary complexity with clients and third parties. [https://jakarta.ee/specifications/authentication/1.1/[AUTHENTICATIONSPEC]] also defines the Servlet Container Profile, which specifies howJakarta Authentication mechanisms, including _ServerAuthModules_, are integrated with the servlet container.
 
 While both existing mechanisms are important and useful, each has limitations from the point of view of an application developer. The servlet container's _login-config_ mechanism is limited to the _auth-method_ types defined by [https://jakarta.ee/specifications/servlet/4.0/[SERVLET40]] -- it doesn't support other credential types, or complex interactions with callers. It also relies on unspecified container mechanisms to associate identity stores with applications. There is no way for an application to ensure that callers are authenticated against the desired identity store, or, indeed, against _any_ identity store.
 
@@ -307,7 +307,7 @@ See also the description of _RememberMeIdentityStore_ in Chapter 3, "<<identityS
 
 The _AutoApplySession_ annotation provides a way to declaratively enableJakarta Authentication _javax.servlet.http.registerSession_ behavior for an authentication mechanism, and automatically apply it for every request.
 
-The _javax.servlet.http.registerSession_ property is described in Section 3.8.4 of [https://jakarta.ee/specifications/authentication/1.1/[JASPIC]].
+The _javax.servlet.http.registerSession_ property is described in Section 3.8.4 of [https://jakarta.ee/specifications/authentication/1.1/[AUTHENTICATIONSPEC]].
 
 This annotation embodies the concept of a caller being authenticated over a series of multiple HTTP requests (together, a "session"). The built-in form-based authentication mechanisms use this same concept. It is therefore implicitly suggested, but not required, that the form-based authentication mechanisms use the backing interceptor for this annotation to establish and maintain their sessions.
 
@@ -430,7 +430,7 @@ public class LoginBacking {
 
 ==== SecurityContext.authenticate() Notes ====
 
-Any _LoginToContinue_-annotated _HttpAuthenticationMechanism_, as well as the two built-in FORM authentication mechanisms, can be triggered via a call to the _SecurityContext.authenticate()_ method. This method is based on the _HttpServletRequest.authenticate()_ method, as defined by [https://jakarta.ee/specifications/servlet/4.0/[SERVLET40]], but has been extended to support additional functionality defined by the Servlet Container Profile of [https://jakarta.ee/specifications/authentication/1.1/[JASPIC]].
+Any _LoginToContinue_-annotated _HttpAuthenticationMechanism_, as well as the two built-in FORM authentication mechanisms, can be triggered via a call to the _SecurityContext.authenticate()_ method. This method is based on the _HttpServletRequest.authenticate()_ method, as defined by [https://jakarta.ee/specifications/servlet/4.0/[SERVLET40]], but has been extended to support additional functionality defined by the Servlet Container Profile of [https://jakarta.ee/specifications/authentication/1.1/[AUTHENTICATIONSPEC]].
 
 The extended behavior is facilitated by the _AuthenticationParameters_ parameter passed to _SecurityContext.authenticate()_. _AuthenticationParameters_ includes a _newAuthentication_ field.
 
@@ -464,7 +464,7 @@ httpMessageContext.getHandler().handle(new Callback[] {
 
 An _HttpAuthenticationMechanism_ is a CDI bean, as defined by Jakarta Contexts and Dependency Injection spec, version 2.0 [https://jakarta.ee/specifications/cdi/2.0/[CDI20]].
 
-The methods defined by the _HttpAuthenticationMechanism_ closely map to the methods and semantics of a _ServerAuthModule_, as defined by the Servlet Container Profile of [https://jakarta.ee/specifications/authentication/1.1/[JASPIC]]. (But an _HttpAuthenticationMechanism_ is itself not a _ServerAuthModule_.) The servlet container MUST useJakarta Authentication mechanisms to arrange for an _HttpAuthenticationMechanism_ to be placed in service.
+The methods defined by the _HttpAuthenticationMechanism_ closely map to the methods and semantics of a _ServerAuthModule_, as defined by the Servlet Container Profile of [https://jakarta.ee/specifications/authentication/1.1/[AUTHENTICATIONSPEC]]. (But an _HttpAuthenticationMechanism_ is itself not a _ServerAuthModule_.) The servlet container MUST useJakarta Authentication mechanisms to arrange for an _HttpAuthenticationMechanism_ to be placed in service.
 
 This specification mandates that when a _ServerAuthModule_ is called by the Servlet container, CDI services (such as the _BeanManager_) MUST be fully available, and all scopes that are defined to be active during the _service()_ method of a servlet, or during the _doFilter()_ method of a servlet filter, MUST be active. Specifically this means that the request, session, and application scopes MUST be active, and that a _ServerAuthModule_ method such as _validateRequest()_ MUST be able to obtain a reference to the CDI _BeanManager_ programmatically (for example, by doing a JNDI lookup), and MUST be able to use that reference to obtain a valid request-scoped, session-scoped, or application-scoped bean. This specification does not mandate that a _ServerAuthModule_ must itself be a CDI bean, or that a _ServerAuthModule_ must be injectable.
 
diff --git a/spec/src/main/asciidoc/bibliography.asciidoc b/spec/src/main/asciidoc/bibliography.asciidoc
index e95bac0..cfaa20d 100644
--- a/spec/src/main/asciidoc/bibliography.asciidoc
+++ b/spec/src/main/asciidoc/bibliography.asciidoc
@@ -19,11 +19,11 @@ https://jakarta.ee/specifications/enterprise-beans/3.2/
 Jakarta Expression Language, version 3.0 +
 https://jakarta.ee/specifications/expression-language/3.0/
 
-[JACC]::
+[AUTHORIZATIONSPEC]::
 Jakarta Authorization, version 1.5 +
 https://jakarta.ee/specifications/authorization/1.5/
 
-[JASPIC]::
+[AUTHENTICATIONSPEC]::
 Jakarta Authentication, version 1.1 +
 https://jakarta.ee/specifications/authentication/1.1/