#5 Added key for isAuthenticationRequest to server container profile.

Signed-off-by: arjantijms <arjan.tijms@gmail.com>

spec/src/main/asciidoc/revision-history.adoc

@@ -220,3 +220,10 @@ the request
 
 . In abstract `AuthConfigFactory` class, made public the static permissions that are used to protect the static `getFactory` and `setFactory` methods, and improved documentation so users of the SPI can know which permissions are used. Also added an additional public `providerRegistrationSecurityPermission` and required that it be used by factory implementations to protect methods like `registerConfigProvider`. Removed incorrect assertion from javadoc of `getFactory`, both forms of `registerConfigProvider`, and `refresh`, that checked `AuthException` could be thrown (by these methods). Changed the javadoc of these four methods to indicate that the conditions for which they were expected to throw an `AuthException` should instead be handled within their existing declarations of throwing an (unchecked) `SecurityException`. Regenerated (mif) javadocs (embedded in spec) from html javadocs, which corrected definition for `layer` and `appContext`parameters of `getConfigProvider(java.lang.String layer, java.lang.String appContext, RegistrationListener listener)`.
 . In `AuthConfig`, and `AuthConfigProvider` interfaces, removed incorrect assertion from javadoc of refresh method that checked `AuthException` could be thrown, and changed javadoc to indicate that the conditions for which `refresh` was expected to throw an `AuthException` should instead be handled within its existing declaration of throwing an (unchecked) `SecurityException`.
+
+=== Changes in Jakarta Authentication 3.0
+
+==== Changes to Servlet Container Profile
+
+ . Added the `jakarta.servlet.http.isAuthenticationRequest` key, so modules can distinguish between being called at the very start of a request and in the middle of it following a call to `HttpServletRequest.authenticate`. This could be needed to determine if certain contexts are certainly not active (such as the Faces context in Jakarta Faces).
+

spec/src/main/asciidoc/servlet-container-profile.adoc

@@ -444,7 +444,7 @@ relay these properties should they be included in their input `MessageInfo` argu
 [[a479]]
 === Sub-profile for authenticate, login, and logout of HttpServletRequest
 
-Servlet 3.0 added the `authenticate`, `login`, and `logout` methods to the `HttpServletRequest` interface. 
+The Servlet `HttpServletRequest` interface contains methods related to authentication, namely: the `authenticate`, `login`, and `logout` methods.
 A compatible implementation of the Servlet Container Profile must satisfy the requirements defined in this sub-profile. This sub-profile differs from the larger profile in which it is contained, in that it describes the
 handling of calls that would typically be expected to occur within the service invocation; while the focus of 
 the larger profile, is on points (2) and (3) in the messaging model (which occur on either side of the
@@ -480,8 +480,8 @@ determines that an `AuthConfigProvider` is not configured for the application co
 Otherwise, `authenticate` must acquire the corresponding `ServerAuthContext` object as defined in
 <<a396>> (and its subsections), while satisfying the additional 
 requirement that the authentication context identifier used to obtain the `ServerAuthContext` must be the identifier that would be acquired by
-calling `getAuthContextID` with `MessageInfo` as defined in <<a425>> and while satisfying the additional requirement that the `MessageInfo` map must unconditionally contain the
-`jakarta.security.auth.message.MessagePolicy.isMandatory` key (with associated `true` value).
+calling `getAuthContextID` with `MessageInfo` as defined in <<a425>> and while satisfying the additional requirement that the `MessageInfo` map must unconditionally contain both the
+`jakarta.security.auth.message.MessagePolicy.isMandatory` key (with associated `true` value) and the `jakarta.servlet.http.isAuthenticationRequest` key (with associated `true` value).
 
 `Authenticate` must call `validateRequest` on the acquired `ServerAuthContext`. The `MessageInfo` 
 argument to the call to `validateRequest` must be as defined above. The `clientSubject` argument must be a