<?xml version="1.0" encoding="UTF-8"?>
<!--

    Copyright (c) 2018, 2020 Oracle and/or its affiliates. All rights reserved.

    This program and the accompanying materials are made available under the
    terms of the Eclipse Public License v. 2.0, which is available at
    http://www.eclipse.org/legal/epl-2.0.

    This Source Code may also be made available under the following Secondary
    Licenses when the conditions for such availability set forth in the
    Eclipse Public License v. 2.0 are satisfied: GNU General Public License,
    version 2 with the GNU Classpath Exception, which is available at
    https://www.gnu.org/software/classpath/license.html.

    SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0

-->

<?xml-stylesheet type="text/xsl" href="https://raw.githubusercontent.com/eclipse-ee4j/jakartaee-tck/master/internal/docs/xsl/spec_assertions.xsl"?>

<spec>
    <next-available-id>346</next-available-id>
    <previous-id>1</previous-id>
    <technology>JASPIC</technology>
    <id>JASPIC</id>
    <name>Jakarta Authentication</name>
    <version>2.0</version>
    <location-names>
        <chapters>
            <chapter id="1" name="Overview">
                <sections>
                    <section id="1.1" name="Message Processing Model" />
                    <section id="1.1.1" name="Authentication Modules" />
                    <section id="1.1.2" name="Authentication Contexts" />
                    <section id="1.1.3" name="Authentication Context Configuration" />
                    <section id="1.1.4" name="Authentication Context Configuration Providers" />
                    <section id="1.1.5" name="Request and Response Messages" />
                    <section id="1.1.6" name="Message Authentication Policy" />
                    <section id="1.1.7" name="Authentication Exchanges and State" />
                    <section id="1.1.8" name="Callbacks for Information from the Runtime" />
                    <section id="1.1.9" name="Subjects" />
                    <section id="1.1.10" name="Status Values and Exceptions" />
                    <section id="1.2" name="Typical Runtime Use Model" />
                    <section id="1.2.1" name="Acquire AuthConfigProvider" />
                    <section id="1.2.2" name="Acquire AuthConfig" />
                    <section id="1.2.3" name="Acquire Message/Operation Identifier" />
                    <section id="1.2.4" name="Acquire Authentication Context" />
                    <section id="1.2.5" name="Process Messages" />
                    <section id="1.3" name="Terminology" />
                    <section id="1.4" name="Assumptions" />
                    <section id="1.5" name="Requirements" />
                    <section id="1.5.1" name="Non Requirements" />
                </sections>
            </chapter>
            <chapter id="2" name="Message Authentication">
                <sections>
                    <section id="2.1" name="Authentication" />
                    <section id="2.1.1" name="Acquire AuthConfigProvider" />
                    <section id="2.1.1.1" name="What the Runtime Must Do" />
                    <section id="2.1.1.2" name="What the Factory Must Do" />
                    <section id="2.1.2" name="Acquire AuthConfig" />
                    <section id="2.1.2.1" name="What the Runtime Must Do" />
                    <section id="2.1.2.2" name="What the Provider Must Do" />
                    <section id="2.1.3" name="Acquire Message/Operation Identifier" />
                    <section id="2.1.3.1" name="What the Runtime Must Do" />
                    <section id="2.1.3.2" name="What the Configuration Must Do" />
                    <section id="2.1.4" name="Acquire the Authentication Context" />
                    <section id="2.1.4.1" name="What the Runtime Must Do" />
                    <section id="2.1.4.2" name="What the Configuration Must Do" />
                    <section id="2.1.5" name="Process Messages" />
                    <section id="2.1.5.1" name="What the Context Must Do" />
                    <section id="2.1.5.2" name="What the Runtime Must Do" />
                    <section id="2.1.5.3" name="What the Modules Must Do" />
                </sections>
            </chapter>
            <chapter id="3" name="Servlet Container Profile">
                <sections>
                    <section id="3.1" name="Message Layer Identifier" />
                    <section id="3.2" name="Application Context Identifier" />
                    <section id="3.3" name="Message Requirements" />
                    <section id="3.4" name="Module Requirements" />
                    <section id="3.5" name="CallbackHandler Requirements" />
                    <section id="3.6" name="AuthConfigProvider Requirements" />
                    <section id="3.7" name="Authentication Context Requirements" />
                    <section id="3.7.1" name="Operation Identifiers" />
                    <section id="3.7.2" name="getAuthContext Subject" />
                    <section id="3.7.3" name="Module Initialization Properties" />
                    <section id="3.7.4" name="MessagePolicy Requirements" />
                    <section id="3.8" name="Message Processing Requirements" />
                    <section id="3.8.1" name="MessageInfo Requirements" />
                    <section id="3.8.1.1" name="MessageInfo Properties" />
                    <section id="3.8.2" name="Subject Requirements" />
                    <section id="3.8.3" name="ServerAuth Processing" />
                    <section id="3.8.3.1" name="validateRequest Befor Service Invocation" />
                    <section id="3.8.3.2" name="validateRequest After Service Invocation" />
                    <section id="3.8.3.3" name="SecureResponse processing" />
                </sections>
            </chapter>
            <chapter id="4" name="SOAP Profile">
                <sections>
                    <section id="4.1" name="Message Layer Identifier" />
                    <section id="4.2" name="Application Context Identifier" />
                    <section id="4.3" name="Message Requirements" />
                    <section id="4.4" name="Module Requirements" />
                    <section id="4.5" name="CallbackHandler Requirements" />
                    <section id="4.6" name="AuthConfigProvider Requirements" />
                    <section id="4.7" name="Authentication Context Requirements" />
                    <section id="4.7.1" name="Operation Identifiers" />
                    <section id="4.7.2" name="MessagePolicy Requirements" />
                    <section id="4.8" name="Requirements for Client Runtimes" />
                    <section id="4.8.1" name="CallbackHandler Requirements" />
                    <section id="4.8.2" name="AuthConfigProvider Requirements" />
                    <section id="4.8.3" name="Authentication Context Requirements" />
                    <section id="4.8.3.1" name="getAuthContext Subject" />
                    <section id="4.8.3.2" name="Module Initialization Properties" />
                    <section id="4.8.3.3" name="MessagePolicy Requirements" />
                    <section id="4.8.4" name="Message Processing Requirements" />
                    <section id="4.8.4.1" name="Message Info Requirements" />
                    <section id="4.8.4.2" name="Subject Requirements" />
                    <section id="4.8.4.3" name="secureRequest processing" />
                    <section id="4.8.4.4" name="validateResponse Processing" />
                    <section id="4.9" name="Requirements for Server Runtimes" />
                    <section id="4.9.1" name="CallbackHandler Requirements" />
                    <section id="4.9.2" name="AuthConfigProvider Requirements" />
                    <section id="4.9.3" name="Authentication Context Requirements" />
                    <section id="4.9.3.1" name="Module Initialization Properties" />
                    <section id="4.9.3.2" name="MessagePolicy Requirements" />
                    <section id="4.9.4" name="Message Processing Requirements" />
                    <section id="4.9.4.1" name="Message Info Requirements" />
                    <section id="4.9.4.2" name="Subject Requirements" />
                    <section id="4.9.4.3" name="validateRequest Processing" />
                    <section id="4.9.4.4" name="secureResponse processing" />
                </sections>
            </chapter>
            <chapter id="5" name="LoginModule Bridge Profile">
                <sections>
                    <section id="5.1" name="Processing Model" />
                    <section id="5.2" name="Division of Responsibility" />
                    <section id="5.3" name="Standard Callbacks" />
                    <section id="5.4" name="Subjects" />
                    <section id="5.5" name="Logout" />
                    <section id="5.6" name="LoginExceptions" />
                </sections>
            </chapter>
            <chapter id="6" name="JMS Profile">
                <sections>
                    <section id="6.1" name="Message Layer Identifier" />
                    <section id="6.2" name="Application Context Identifier" />
                    <section id="6.3" name="Message Requirements" />
                    <section id="6.4" name="Module Requirements" />
                    <section id="6.5" name="CallbackHandler Requirements" />
                    <section id="6.6" name="AuthConfigProvider Requirements" />
                    <section id="6.7" name="Authentication Context Requirements" />
                    <section id="6.7.1" name="Operation Identifiers" />
                    <section id="6.7.2" name="MessagePolicy Requirements" />
                    <section id="6.8" name="Requirements for Client Runtimes" />
                    <section id="6.8.1" name="CallbackHandler Requirements" />
                    <section id="6.8.2" name="AuthConfigProvider Requirements" />
                    <section id="6.8.3" name="Authentication Context Requirements" />
                    <section id="6.8.3.1" name="getAuthContext Subject" />
                    <section id="6.8.3.2" name="Module Initialization Properties" />
                    <section id="6.8.3.3" name="MessagePolicy Requirements" />
                    <section id="6.8.4" name="Message Processing Requirements" />
                    <section id="6.8.4.1" name="Message Info Requirements" />
                    <section id="6.8.4.2" name="Subject Requirements" />
                    <section id="6.8.4.3" name="secureRequest processing" />
                    <section id="6.8.4.4" name="validateResponse Processing" />
                    <section id="6.9" name="Requirements for Server Runtimes" />
                    <section id="6.9.1" name="CallbackHandler Requirements" />
                    <section id="6.9.2" name="AuthConfigProvider Requirements" />
                    <section id="6.9.3" name="Authentication Context Requirements" />
                    <section id="6.9.3.1" name="Module Initialization Properties" />
                    <section id="6.9.3.2" name="MessagePolicy Requirements" />
                    <section id="6.9.4" name="Message Processing Requirements" />
                    <section id="6.9.4.1" name="Message Info Requirements" />
                    <section id="6.9.4.2" name="Subject Requirements" />
                    <section id="6.9.4.3" name="validateRequest Processing" />
                    <section id="6.9.4.4" name="secureResponse processing" />
                </sections>
            </chapter>
        </chapters>
    </location-names>
    <assertions>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:1</id>
            <description> A message processing runtime may acquire the authentication context objects thatit uses to
                invoke authentication modules by interacting with an authentication context configuration object
            </description>
            <keywords>
                <keyword>authentication</keyword>
            </keywords>
            <location chapter="1" section="1.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:2</id>
            <description> An authentication context configuration object is an implementation of either the
                ClientAuthConfig or ServerAuthConfig interface as defined by this specification.
            </description>
            <keywords>
                <keyword>authentication</keyword>
            </keywords>
            <location chapter="1" section="1.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:3</id>
            <description> A message processing runtime may acquire authentication context configuration objects
                by interacting with a provider of authentication context configuration objects.
            </description>
            <keywords>
                <keyword>authentication</keyword>
            </keywords>
            <location chapter="1" section="1.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:4</id>
            <description> A message processing runtime may interact with the factory to obtain or establish the provider
                registered for an application context and messaging layer.
            </description>
            <keywords>
                <keyword>authentication</keyword>
            </keywords>
            <location chapter="1" section="1.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:5</id>
            <description> Authentication modules should be implemented such that they may be invoked concurrently and
                such that they are able to apply and establish independent security identities for concurrent
                invocations.
            </description>
            <keywords>
                <keyword>Module</keyword>
            </keywords>
            <location chapter="1" section="1.7" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:6</id>
            <description> In a multi-message authentication scenario, it is the responsibility of the authentication
                modules
                involved in the authentication to tie together or correlate the messages that comprise the
                authentication exchange. In addition to message correlation to tie to together the messages
                required to complete an authentication, message correlation may also be employed post-authentication
                such that a prior authentication result or session may be applied to a subsequent invocation. Modules
                are expected to perform their message correlation function based on the parameters of their invocation
                and with the benefit of any additional facilities provided by the invoking runtime (e.g., via their
                CallbackHandler).
            </description>
            <keywords>
                <keyword>multi-message</keyword>
            </keywords>
            <location chapter="1" section="1.7" />
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:7</id>
            <description> A message processing runtime that wishes to invoke authentication modules configured according
                to this specification, must use the AuthConfigFactory.getFactory method to obtain a factory
                implementation.

            </description>
            <keywords>
                <keyword>Module</keyword>
            </keywords>
            <location chapter="2" section="1.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:8</id>
            <description> The runtime must invoke the getConfigProvider method of the factory to obtain the
                AuthConfigProvider. The runtime must specify appropriate (non-null) layer and application context
                identifiers in its call to getConfigProvider.

            </description>
            <keywords>
                <keyword>getConfigProvider</keyword>
            </keywords>
            <location chapter="2" section="1.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:9</id>
            <description> A runtime may continue to reuse a provider for as long as it wishes. However, a runtime that
                wishes to be notified of changes to the factory that would cause the factory to return a different
                provider for the layer and appContext arguments should include a (non-null) RegistrationListener as an
                argument in the call used to acquire the provider.
            </description>
            <keywords>
                <keyword>provider</keyword>
            </keywords>
            <location chapter="2" section="1.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:10</id>
            <description> The factory implementation must satisfy the requirements defined by the AuthConfigFactory
                class. In particular, it must offer a public, zero argument constructor that supports the construction
                and registration of AuthConfigProvider objects from a persistent declarative representation.

            </description>
            <keywords>
                <keyword>AuthConfigFactory</keyword>
            </keywords>
            <location chapter="2" section="1.1.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:11</id>
            <description> Once the runtime has obtained the appropriate (non-null) AuthConfigProvider, it must obtain
                from the provider the authentication context configuration object corresponding to the messaging layer,
                its role as client or server, and the application context for which it will be exchanging messages. It
                does this by invoking getClientAuthConfig or getServerAuthConfig as appropriate to the role of the
                runtime in the message exchange.

            </description>
            <keywords>
                <keyword>AuthConfigProvider</keyword>
            </keywords>
            <location chapter="2" section="1.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:12</id>
            <description> A runtime operating at points 1 and 4 in the messaging model must invoke getClientAuthConfig
                to acquire its configuration object.
            </description>
            <keywords>
                <keyword>getClientAuthConfig</keyword>
            </keywords>
            <location chapter="2" section="1.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:13</id>
            <description> A runtime operating at points 2 and 3 in the messaging model must invoke getServerAuthConfig
                to acquire its configuration object.

            </description>
            <keywords>
                <keyword>getServerAuthConfig</keyword>
            </keywords>
            <location chapter="2" section="1.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:14</id>
            <description> The call to acquire the configuration object must specify the same values for layer and
                application context identifier that were used to acquire the provider

            </description>
            <location chapter="2" section="1.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:15</id>
            <description> A runtime may continue to reuse an acquired authentication context configuration object for as
                long as it is acting as client or server of the corresponding application. A runtime should reacquire an
                authentication context configuration object when it is notified (via a RegistrationListener) that it
                must reacquire the AuthConfigProvider from which the configuration object was acquired (and after having
                reacquired the provider).

            </description>
            <keywords>
                <keyword>authentication</keyword>
            </keywords>
            <location chapter="2" section="1.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:16</id>
            <description> The provider implementation must satisfy the requirements defined by the AuthConfigProvider
                interface. In particular, it must return non-null authentication configuration objects.

            </description>
            <keywords>
                <keyword>AuthConfigProvider</keyword>
            </keywords>
            <location chapter="2" section="1.2.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:17</id>
            <description> When the provider is a dynamic configuration provider, any change to the internal state of the
                provider occurring as the result of a call to its refresh method must be recognized by every
                authentication context configuration object obtained from the provider.

            </description>
            <keywords>
                <keyword>AuthConfigProvider</keyword>
            </keywords>
            <location chapter="2" section="1.2.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:18</id>
            <description> The provider implementation must provide a configuration facility that may be used to
                configure the information required to initialize authentication contexts for the (one or more)
                authentication context configuration scopes (defined by layer and application context) for which the
                provider is registered (at the factory).

            </description>
            <keywords>
                <keyword>provider</keyword>
            </keywords>
            <location chapter="2" section="1.2.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:19</id>
            <description> At points (1) and (2) in the messaging model, the message processing runtime must obtain the
                authentication context identifier corresponding to the request message processing being performed by the
                runtime.

            </description>
            <keywords>
                <keyword>Identifier</keyword>
            </keywords>
            <location chapter="2" section="1.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:20</id>
            <description> The identifier may be acquired by calling the getOperation method of the authentication
                context configuration object (obtained in the preceding step). If the messaging runtime chooses to
                obtain the operation identifier by this means, it must provide a MessageInfo object as argument to the
                getOperation call, and the MessageInfo must have been initialized such that its getRequestMessage method
                will return the request message being processed by the runtime. The type of the returned request message
                must be as defined by the profile of this specification being followed by the messaging runtime.

            </description>
            <keywords>
                <keyword>getOperation</keyword>
            </keywords>
            <location chapter="2" section="1.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:21</id>
            <description> Alternatively and depending on the requirements relating to operation identifier inherent in
                the profile being followed by the messaging runtime, the runtime may obtain the operation identifier by
                other means. Where a profile defines or facilitates other means by which a messaging runtime may acquire
                the operation identifier, the identifier acquired by any such means must be equivalent to the identifier
                that would be acquired by calling getOperation as described above.

            </description>
            <keywords>
                <keyword>identifier</keyword>
            </keywords>
            <location chapter="2" section="1.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:22</id>
            <description> The configuration implementation must satisfy the requirements defined by the AuthConfig
                interface with respect to the getOperation method.

            </description>
            <keywords>
                <keyword>AuthConfig</keyword>
            </keywords>
            <location chapter="2" section="1.3.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:23</id>
            <description> At points (1) and (2) in the messaging model, the message processing runtime must invoke the
                getAuthContext method of the authentication context configuration object (obtained in step 2) to obtain
                the authentication context object corresponding to the message that is to be processed. This is
                accomplished by invoking getAuthContext with the operation/message identifier corresponding to the
                request message and obtained as described above.

            </description>
            <keywords>
                <keyword>getAuthContext</keyword>
            </keywords>
            <location chapter="2" section="1.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:24</id>
            <description> If required by the profile of this specification being followed by the runtime, the call to
                getAuthContext must pass a Map containing the required property elements. The value of the Subject
                argument provided by the runtime in its call to getAuthContext must correpond to the requirements of the
                profile of this specification being followed by the runtime.

            </description>
            <keywords>
                <keyword>profile</keyword>
            </keywords>
            <location chapter="2" section="1.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:25</id>
            <description> Once an authentication context is acquired, it may be reused to process subsequent requests of
                the application for which an equivalent authentication context identifier, Subject, and properties Map
                (as used in the getAuthContext) applies.

            </description>
            <keywords>
                <keyword>getAuthContext</keyword>
            </keywords>
            <location chapter="2" section="1.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:26</id>
            <description> Runtimes that wish to be dynamic with respect to changes in context configuration, should call
                getAuthContext for every request. An authentication context configuration object may return the same
                authentication context object for different authentication context identifiers for which the same module
                configuration and message protection policy applies.

            </description>
            <keywords>
                <keyword>policy</keyword>
            </keywords>
            <location chapter="2" section="1.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:27</id>
            <description> At points (3) and (4) in the messaging model, the runtime may repeat the context acquisition
                performed at point (2) and (1) respectively, or it may reuse the previously acquired context.

            </description>
            <keywords>
                <keyword>context</keyword>
            </keywords>
            <location chapter="2" section="1.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:28</id>
            <description> The configuration implementation must satisfy the requirements defined by the corresponding
                ClientAuthConfig or ServerAuthConfig interface with respect to the getAuthContext method. In this
                regard, the configuration implementation must determine the authentication modules that are to comprise
                the acquired context, and it must provide the context implementation with sufficient information to
                initialize the modules of the context.

            </description>
            <keywords>
                <keyword>getAuthContext</keyword>
            </keywords>
            <location chapter="2" section="1.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:29</id>
            <description> The getAuthContext method must return null when no authentication modules are to be invoked
                for an identified authentication context at the layer and application context represented by the
                configuration object
            </description>
            <keywords>
                <keyword>getAuthContext</keyword>
            </keywords>
            <location chapter="2" section="1.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:30</id>
            <description> The AuthConfigProvider from which the authentication context configuration object was acquired
                must provide a configuration facility by which the information required to initialize authentication
                contexts may be configured and associated with one or more authentication context identifiers within the
                (one or more) layer and application context scopes for which the provider is registered (at the
                factory).

            </description>
            <keywords>
                <keyword>AuthConfigProvider</keyword>
            </keywords>
            <location chapter="2" section="1.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:31</id>
            <description> Every context implementation must satisfy the requirements as defined by the corresponding
                ClientAuthContext or ServerAuthContext interface.

            </description>
            <keywords>
                <keyword>ClientAuthContext</keyword>
                <keyword>ServerAuthContext</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:32</id>
            <description> Every context must delegate calls made to the methods of its corresponding ClientAuth or
                ServerAuth interface to the corresponding methods of its one or more authentication modules.

            </description>
            <keywords>
                <keyword>ClientAuth</keyword>
                <keyword>ServerAuth</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:33</id>
            <description> When a context encapsulates multiple authentication modules, the context must embody the
                control logic to determine which modules of the context are to be invoked and in what order. Contexts
                which encapsulate alternative sufficient modules, must ensure that the same message values are passed to
                each invoked alternative of the context. When a context invokes multiple authentication modules, the
                context must combine the AuthStatus values returned by the invoked authentication modules to establish
                the AuthStatus value returned by the context to the messaging runtime. The context implementation must
                define the logic for combining the returned AuthStatus values.

            </description>
            <keywords>
                <keyword>AuthStatus</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:34</id>
            <description> If a non-null authentication context object is returned by getAuthContext, the corresponding
                message processing runtime must invoke the methods of the acquired authentication context to process the
                corresponding request and response messages as defined below. Otherwise, the message processing runtime,
                must proceed with its normal processing of the corresponding messages and without invoking the methods
                of an authentication context object.

            </description>
            <keywords>
                <keyword>getAuthContext</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:35</id>
            <description> At point (1) in the message processing model : the message processing runtime must call the
                secureRequest method of the ClientAuthContext.

            </description>
            <keywords>
                <keyword>secureRequest</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:36</id>
            <description> (At point 1 in message processing model) The messageInfo argument to the call must have been
                initialized such that its getRequestMessage method will return the request message being processed by
                the runtime. The type of the returned request message must be as defined by the profile being followed.

            </description>
            <keywords>
                <keyword>messageInfo</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:37</id>
            <description> (At point 1 in message processing model) If a non-null Subject was used to acquire the
                ClientAuthContext, the same Subject must be passed as the clientSubject in this call. If a non-null
                clientSubject is used in this call, it must not be read-only, and the same clientSubject argument must
                be passed in all calls to validateResponse made for the one or more responses processed to complete the
                message exchange.

            </description>
            <keywords>
                <keyword>Subject</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:38</id>
            <description> (At point 1 in message processing model) If the call to secureRequest returns:
                AuthStatus.SEND_SUCCESS - the runtime should send (without calling secureRequest) the request message
                acquired by calling messageInfo.getRequestMessage. After sending the request, the runtime should proceed
                to point (4) in the message processing model (to receive and validate the response).

            </description>
            <keywords>
                <keyword>secureRequest</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:39</id>
            <description> (At point 1 in message processing model) If the call to secureRequest returns:
                AuthStatus.SEND_CONTINUE - the module has returned, in messageInfo, an initial request message to be
                sent. Moreover, the module is informing the client runtime that it will be required to continue the
                message dialog by sending the message resulting from validation of the response to the initial message.
                If the runtime will be unable to continue the dialog by sending the message resulting from validation of
                the response, the runtime must not send the initial request and it must convey its inability by
                returning an error to the client application. Otherwise, the runtime should send (without calling
                secureRequest) the request message acquired by calling messageInfo.getRequestMessage.

            </description>
            <keywords>
                <keyword>secureRequest</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:40</id>
            <description> (At point 1 in message processing model) If the call to validateRequest returns:
                AuthStatus.FAILURE (Befor service Invocation) - The runtime should return an error to the client
                application. The runtime should derive the returned error from the response message acquired by calling
                messageInfo.getResponseMessage.
            </description>
            <keywords>
                <keyword>secureRequest</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:41</id>
            <description> (At point 1 in message processing model) If the call to secureRequest throws an AuthException
                - the runtime should use the exception to convey to the client runtime that the request failed.

            </description>
            <keywords>
                <keyword>secureRequest</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:42</id>
            <description> At point (4) in the message processing model: the message processing runtime must call the
                validateResponse method of the ClientAuthContext.
            </description>
            <keywords>
                <keyword>validateResponse</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:43</id>
            <description> In the call made to validateResponse, the runtime must pass the same MessageInfo instance that
                was passed to secureRequest (at the start of the message exchange). The messageInfo argument must have
                been initialized such that its getResponseMessage method will return the response message being
                processed by the runtime.The type of the required return messages must be as defined by the profile
                being followed.

            </description>
            <keywords>
                <keyword>validateResponse</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:44</id>
            <description> The value of the clientSubject argument to the (validateResponse) call must be the same as
                that passed in the call to secureRequest for the corresponding request.

            </description>
            <keywords>
                <keyword>clientSubject</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:45</id>
            <description> The serviceSubject argument to the (validateResponse) call may be non-null, in which it may be
                used by modules to store Principals and credentials determined to pertain to the source of the response.

            </description>
            <keywords>
                <keyword>serviceSubject</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:46</id>
            <description> If the call to validateResponse returns: AuthStatus.SUCCESS - The runtime should use the
                response message acquired by calling messageInfo.getResponseMessage.to create the return value to be
                returned to the client.

            </description>
            <keywords>
                <keyword>validateResponse</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:47</id>
            <description> If the call to validateResponse returns: AuthStatus.SEND_CONTINUE - if the runtime it is
                unable to process this status value it must return an error to the client application indicating its
                inability to process this status value. To process this status value, the runtime must send (without
                calling secureRequest) the (continuation) request message obtained by calling
                messageInfo.getRequestMessage, and it must receive and process via validateResponse (at least) the next
                corresponding response or error (before returning a value to the client).

            </description>
            <keywords>
                <keyword>validateResponse</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:48</id>
            <description> If the call to validateResponse returns: AuthStatus.FAILURE- the runtime should return an
                error to the client application. The runtime should derive the returned error from the response message
                acquired by calling messageInfo.getResponseMessage.

            </description>
            <keywords>
                <keyword>validateResponse</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:49</id>
            <description> If the call to validateResponse throws an AuthException - runtime should use the exception to
                convey to the client runtime that the request failed.

            </description>
            <keywords>
                <keyword>validateResponse</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:50</id>
            <description> At point (2) in the message processing model: the message processing runtime must call the
                validateRequest method of the ServerAuthContext.

            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:51</id>
            <description> (at point 2 in MPR model) The messageInfo argument to the call must have been initialized such
                that its getRequestMessage method will return the request message being processed by the runtime. For
                some profiles of this specification, the runtime must also initialize messageInfo such that its
                getResponseMessage method will return the response message being processed by the runtime. The type of
                the required return messages must be as defined by the profile being followed.

            </description>
            <keywords>
                <keyword>messageInfo</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:52</id>
            <description> (At point (2) in the message processing model) The clientSubject argument must be non-null and
                it must not be read-only.
            </description>
            <keywords>
                <keyword>clientSubject</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:53</id>
            <description> (At point (2) in the message processing model) If a non-null Subject was used to acquire the
                ServerAuthContext, the same Subject must be passed as the serviceSubject in this call.
            </description>
            <keywords>
                <keyword>serviceSubject</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:313</id>
            <description> (At point (2) in the message processing model) If a non-null serviceSubject is used in this
                call, it must not be read-only.
            </description>
            <keywords>
                <keyword>serviceSubject</keyword>
            </keywords>
            <location chapter="2" section="1.5.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:314</id>
            <description> (At point (2) in the message processing model) the same serviceSubject must be passed in the
                call to secureResponse for the corresponding response (if there is one).
            </description>
            <keywords>
                <keyword>serviceSubject</keyword>
            </keywords>
            <location chapter="2" section="1.5.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:54</id>
            <description> If the call to validateRequest returns: AuthStatus.SUCCESS - the runtime should proceed to
                authorize the request using the clientSubject, perform the application request processing (depending on
                the authorization result), and proceed to point (3) as appropriate.

            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:55</id>
            <description> If the call to validateRequest returns: AuthStatus.SEND_SUCCESS - The runtime must NOT proceed
                to authorize the request or perform the application request processing.
            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:56</id>
            <description> If the call to validateRequest returns: AuthStatus.SEND_CONTINUE - The runtime must NOT
                proceed to authorize the request or perform the application request processing.
            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:57</id>
            <description> If the call to validateRequest returns: AuthStatus.SEND_FAILURE - (If the failure occurred
                after the service invocation), the runtime must perform whatever processing it requires to complete the
                processing of a request that failed after a successful service invocation, and prior to communicating
                the invocation result to the client runtime.
            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:315</id>
            <description> If the call to validateRequest returns: AuthStatus.SEND_FAILURE - (If the failure occurred
                befor the service invocation), the runtime must NOT proceed to authorize the request or perform the
                application request processing.
            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:58</id>
            <description> If the call to validateRequest throws an AuthException (Befor Service Invocation) - the
                runtime must NOT proceed to authorize the request or perform the application request processing.
            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:316</id>
            <description> If the call to validateRequest throws an AuthException - (If the failure occurred after the
                service invocation) the runtime must perform whatever processing it requires to complete the processing
                of a request that failed after a successful service invocation, and prior to communicating the
                invocation result to the client runtime.
            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:59</id>
            <description> At point (3) in the message processing model: the message processing runtime must call the
                secureResponse method of the ServerAuthContext.
            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:60</id>
            <description> In the call made to secureResponse, the runtime must pass the same MessageInfo instance that
                was passed to validateRequest (for the corresponding request message). The messageInfo argument must
                have been initialized such that its getResponseMessage method will return the response message being
                processed by the runtime. The type of the required return messages must be as defined by the profile
                being followed.

            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:61</id>
            <description> The value of the serviceSubject argument to the (secureResponse) call must be the same as that
                passed in the call to validateRequest for the corresponding request.

            </description>
            <keywords>
                <keyword>serviceSubject</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:62</id>
            <description> If the call to secureResponse returns: AuthStatus.SEND_SUCCESS - the runtime should send
                (without calling secureResponse) the response message acquired by calling messageInfo.getResponseMessage
                at which time, the processing of the application request and its corresponding response will be
                complete.

            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:63</id>
            <description> If the call to secureResponse returns: AuthStatus.SEND_CONTINUE - the runtime should send
                (without calling secureResponse) the response message acquired by calling
                messageInfo.getResponseMessage. The processing of the response is not finished, and as such, its outcome
                is not yet known.

            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:64</id>
            <description> If the call to secureResponse returns: AuthStatus.SEND_FAILURE - the runtime must perform
                whatever processing it requires to complete the processing of a request that failed after (or during)
                service invocation, and prior to communicating the invocation result to the client runtime. This may
                include sending (without calling secureResponse) the response message acquired by calling
                messageInfo.getResponseMessage.

            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:65</id>
            <description> If the call to secureResponse throws an AuthException - the runtime must perform whatever
                processing it requires to complete the processing of a request that failed after (or during) service
                invocation, and prior to communicating the invocation result to the client runtime. the runtime may send
                (without calling secureResponse) an appropriate response message of its choice. if a failure message is
                returned, it should indicate that the failure in request processing occurred after the successful
                invocation of the service.

            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:66</id>
            <description> The authentication module implementations within the context must satisfy the requirements as
                defined by the corresponding ClientAuthModule or ServerAuthModule interface.

            </description>
            <keywords>
                <keyword>ClientAuthModule</keyword>
                <keyword>ServerAuthModule</keyword>
            </keywords>
            <location chapter="2" section="1.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:67</id>
            <description> The message layer value used to select the AuthConfigProvider and ServerAuthConfig objects for
                this (servlet) profile must be HttpServlet

            </description>
            <keywords>
                <keyword>Identifier</keyword>
            </keywords>
            <location chapter="3" section="1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:68</id>
            <description> The application context identifier (that is, the appContext parameter value) used to select
                the AuthConfigProvider and ServerAuthConfig objects for a specific application shall be the String value
                constructed by concatenating the host name, a blank separator character, and the decoded context path
                corresponding to the web module.

            </description>
            <keywords>
                <keyword>identifier</keyword>
            </keywords>
            <location chapter="3" section="2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:69</id>
            <description> The MessageInfo argument used in any call made by the message processing runtime to
                validateRequest or secureResponse must have been initialized such that the non-null objects returned by
                the getRequestMessage and getResponseMessage methods of the MessageInfo are an instanceof
                HttpServletRequest and HttpServletResponse, respectively.

            </description>
            <keywords>
                <keyword>MessageInfo</keyword>
            </keywords>
            <location chapter="3" section="3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:70</id>
            <description> The getSupportedMessageTypes method of all authentication modules integrated for use with this
                profile, must include jakarta.servlet.http.HttpServletRequest.class and
                jakarta.servlet.http.HttpServeletResponse.class in its return value.

            </description>
            <keywords>
                <keyword>getSupportedMessageTypes</keyword>
            </keywords>
            <location chapter="3" section="4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:71</id>
            <description> The CallbackHandler passed to ServerAuthModule.initialize is determined by the handler
                argument passed in the AuthConfigProvider.getServerAuthConfig call that acquired the corresponding
                authentication context configuration object. The handler argument must not be null.
            </description>
            <keywords>
                <keyword>getServerAuthConfig</keyword>
            </keywords>
            <location chapter="3" section="5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:72</id>
            <description> The CallbackHandler passed to ServerAuthModule.initialize must support the following
                callbacks: CallerPrincipalCallback, GroupPrincipalCallback, PasswordValidationCallback.

            </description>
            <keywords>
                <keyword>CallbackHandler</keyword>
            </keywords>
            <location chapter="3" section="5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:73</id>
            <description> The argument handler and the CallbackHandler passed through to the authentication modules must
                be initialized with any application context required to process its supported callbacks on behalf of the
                corresponding application.

            </description>
            <keywords>
                <keyword>CallbackHandler</keyword>
            </keywords>
            <location chapter="3" section="5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:318</id>
            <description> The factory implementation returned by calling the getFactory method of the abstract
                AuthConfigFactory class must have been configured such that it returns a non-null AuthConfigProvider for
                those application contexts for which pluggable authentication modules have been configured at the
                ?HttpServlet? layer.

            </description>
            <keywords>
                <keyword>CallbackHandler</keyword>
            </keywords>
            <location chapter="3" section="6" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:74</id>
            <description> For each application context for which it is servicing requests, the runtime must call
                getConfigProvider to acquire the provider object corresponding to the layer and application context. The
                layer and appContext arguments to getConfigProvider must be as defined in Section 3.1, Message Layer
                Identifier and Section 3.2, Application Context Identifier respectively

            </description>
            <keywords>
                <keyword>getConfigProvider</keyword>
            </keywords>
            <location chapter="3" section="6" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:75</id>
            <description> If a non-null AuthConfigProvider is returned, the messaging runtime must call
                getServerAuthConfig on the provider to obtain the authentication context configuration object pertaining
                to the application context at the layer. The layer and appContext arguments of the call to
                getServerAuthConfig must be the same as those used to acquire the provider, and the handler argument
                must be as defined in Section 3.5, CallbackHandler Requirements.

            </description>
            <keywords>
                <keyword>getServerAuthConfig</keyword>
            </keywords>
            <location chapter="3" section="6" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:76</id>
            <description> A null return value from getConfigProvider indicates that pluggable authentication modules
                have not been configured at the layer for the application context and that the messaging runtime must
                proceed to perform its servlet security constraint processing without reliance on this profile.

            </description>
            <keywords>
                <keyword>getConfigProvider</keyword>
            </keywords>
            <location chapter="3" section="6" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:77</id>
            <description> When a non-null AuthConfigProvider is returned by the factory, the provider must have been
                configured with the information required to initialize the authentication contexts for the (one or more)
                authentication context configuration scopes (defined by layer and application context) for which the
                provider is registered (at the factory).

            </description>
            <keywords>
                <keyword>AuthConfigProvider</keyword>
            </keywords>
            <location chapter="3" section="7" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:78</id>
            <description> When a non-null AuthConfigProvider is returned by the factory, the messaging runtime must call
                getAuthContext on the authentication context configuration object (obtained from the provider).

            </description>
            <keywords>
                <keyword>AuthConfigProvider</keyword>
            </keywords>
            <location chapter="3" section="7" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:79</id>
            <description> For all values of the authContextID argument that satisfy the requirements of Section 3.7.1,
                the call to getAuthContext must return a non-null authentication context.

            </description>
            <keywords>
                <keyword>getAuthContext</keyword>
            </keywords>
            <location chapter="3" section="7" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:80</id>
            <description> the authentication context identifier used in the call to getAuthContext must be equivalent to
                the value that would be acquired by calling getAuthContextID with the MessageInfo that will be used in
                the call to validateRequest.

            </description>
            <keywords>
                <keyword>identifier</keyword>
            </keywords>
            <location chapter="3" section="7.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:81</id>
            <description> A null value may be passed as the Subject argument in the getAuthContext call.
            </description>
            <keywords>
                <keyword>getAuthContext</keyword>
            </keywords>
            <location chapter="3" section="7.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:300</id>
            <description> If the runtime is a JSR 115 compatible Servlet container, the properties argument passed in
                all calls to getAuthContext must contain the following key-value pair:
                (key) jakarta.security.jacc.PolicyContext
                (value) The PolicyContext identifier value that the container must set.
            </description>
            <keywords>
                <keyword>getAuthContext</keyword>
            </keywords>
            <location chapter="3" section="7.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:83</id>
            <description> When the runtime is not a JSR 115 compatible Servlet container, the properties argument used
                in all calls to getAuthContext must not include a jakarta.security.jacc.PolicyContext key-value pair,
                and a null value may be passed for the properties argument.
            </description>
            <keywords>
                <keyword>getAuthContext</keyword>
            </keywords>
            <location chapter="3" section="7.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:84</id>
            <description> Each ServerAuthContext obtained via getAuthContext must initialize its encapsulated
                ServerAuthModule objects with a non-null value for requestPolicy. The encapsulated authentication
                modules may be initialized with a null value for responsePolicy.

            </description>
            <keywords>
                <keyword>getAuthContext</keyword>
            </keywords>
            <location chapter="3" section="7.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:85</id>
            <description> The requestPolicy used to initialize the authentication modules of the ServerAuthContext must
                be constructed such that the value obtained by calling isMandatory on the requestPolicy accurately
                reflects whether (i.e., true return value) or not (i.e, false return value) authentication is required
                to access the web resource corresponding to the HttpServletRequest to which the ServerAuthContext will
                be applied.

            </description>
            <keywords>
                <keyword>requestPolicy</keyword>
            </keywords>
            <location chapter="3" section="7.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:86</id>
            <description> The message processing runtime is responsible for determining if authentication is required
                and must convey the results of its determination as described in Section 3.8.1, 'MessageInfo
                Requirements,' on page 29.
            </description>
            <keywords>
                <keyword>auth-constraint</keyword>
            </keywords>
            <location chapter="3" section="7.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:87</id>
            <description> Calling getTargetPolicies on the request MessagePolicy must return an array containing at
                least one TargetPolicy whose ProtectionPolicy will be interpreted by the modules of the context to mean
                that the source of the corresponding targets within the message is to be authenticated. To that end,
                calling the getID method on the ProtectionPolicy must return one of the following values:
                ProtectionPolicy.AUTHENTICATE_SENDER, ProtectionPolicy.AUTHENTICATE_CONTENT

            </description>
            <keywords>
                <keyword>getTargetPolicies</keyword>
            </keywords>
            <location chapter="3" section="7.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:88</id>
            <description> At point (2) in the message processing model, the runtime must call validateRequest on the
                ServerAuthContext.
            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="3" section="8" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:89</id>
            <description> If the request has satisfied the connection requirements, the message processing runtime must
                call validateRequest independent of whether or not access to the resource would be authorized prior to
                the call to validateRequest. validateRequest must be called for all requests, including requests to a
                form-based login form.

            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="3" section="8" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:90</id>
            <description> If the call to validateRequest returns AuthStatus.SUCCESS, the runtime must establish return
                values for getUserPrincipal, getRemoteUser, and getAuthType as defined in Section 3.8.4.

            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="3" section="8" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:301</id>
            <description> If the applicable requestPolicy indicates that authentication is NOT required, the runtime may
                choose to continue the invocation of the resource under the runtime?s representation of the
                unauthenticated caller identity. A runtime must not choose to continue the invocation if the
                HttpServletResponse.isCommitted() returns true.
            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="3" section="8" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:91</id>
            <description> In a JSR 115 compatible runtime, the identity must be comprised of exactly the Principal
                objects of the clientSubject.

            </description>
            <keywords>
                <keyword>clientSubject</keyword>
            </keywords>
            <location chapter="3" section="8" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:92</id>
            <description> In a non-JSR 115 compatible Servlet runtime, the identity must include the caller Principal
                (established during the validateRequest processing using the corresponding CallerPrincipalCallback).
                (and may include any of the Principal objects of the clientSubject.)
            </description>
            <keywords>
                <keyword>Principal</keyword>
            </keywords>
            <location chapter="3" section="8" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:93</id>
            <description> If the request is not authorized, the runtime must return the HTTP status code required by the
                Servlet spec.
            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="3" section="8" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:317</id>
            <description> The request must be dispatched to the resource if the request was determined to be authorized;
                otherwise it must NOT be dispatched and the runtime must proceed to point (3) in the message processing
                model.
            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="3" section="8" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:302</id>
            <description> If the request is dispatched to the resource and the resource invocation throws an exception
                to the runtime, the runtime must set, within the response, an HTTP status code which satisfies any
                applicable requirements defined within the servlet specification.
            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="3" section="8" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:303</id>
            <description> If the request is dispatched to the resource, and the resource was configured to run-as its
                caller, then for invocations originating from the resource where caller propagation is required, the
                identity established using the CallerPrincipalCallback must be used as the propagated identity
            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="3" section="8" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:94</id>
            <description> The call to secureResponse must not be made if the resource throws an exception to the calling
                runtime.

            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="3" section="8" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:304</id>
            <description> If invocation of the resource completes without throwing an exception, the runtime must
                proceed to point (3) in the message processing model.
            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="3" section="8" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:305</id>
            <description> At point (3) in the message processing model, the runtime must call secureResponse on the same
                ServerAuthContext used in the corresponding call to validateRequest and with the same MessageInfo
                object.
            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="3" section="8" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:95</id>
            <description> The messageInfo argument used in the call to validateRequest must have been initialized by the
                runtime such that its getRequestMessage and getResponseMessage methods will return the
                HttpServletRequest and HttpServletResponse objects corresponding to the messages (respectively) being
                processed by the runtime. This must be the case even when the target of the request is a static page
                (that is, not a servlet).

            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="3" section="8.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:306</id>
            <description> This profile requires that the message processing runtime conditionally establish the
                following key-value pair within the Map of the MessageInfo object passed in the calls to
                getAuthContextID, validateRequest, and secureResponse.
                (key) jakarta.security.auth.message.MessagePolicy.isMandatory
                (val) Any non-null String value, s, for which
                Boolean.valueOf(s).booleanValue() == true.

                The MessageInfo map must contain this key and its associated value, if and only if authentication is required to
                perform the resource access corresponding to the HttpServletRequest to which the ServerAuthContext will
                be applied.
            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="3" section="8.1.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:307</id>
            <description> Authentication is required if use of the HTTP method of the HttpServletRequest at the resource
                identified by the HttpServletRequest is covered by a Servlet auth-constraint, or in a JSR 115 compatible
                runtime, if the corresponding WebResourcePermission is NOT granted2 to an unauthenticated caller
            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="3" section="8.1.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:319</id>
            <description> In a JSR 115 compatible runtime, the corresponding WebResourcePermission may be constructed
                directly from the HttpServletRequest as follows: public WebResourcePermission(HttpServletRequest
                request); The authentication context configuration system must use the value of this property to
                establish the corresponding value within the requestPolicy passed to the authentication modules of the
                ServerAuthContext acquired to process the MessageInfo.t
            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="3" section="8.1.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:96</id>
            <description> A new clientSubject must be instantiated and passed in the call to validateRequest.

            </description>
            <keywords>
                <keyword>clientSubject</keyword>
            </keywords>
            <location chapter="3" section="8.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:97</id>
            <description> validateRequest may be called either before the service invocation (to establish the caller
                identity) or after the service invocation (when a multi-message dialog is required to secure the
                response). The module implementation is responsible for recording any state and performing any
                processing required to differentiate these two different types of calls to validateRequest.

            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="3" section="8.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:98</id>
            <description> When validateRequest is called before the service invocation on a module initialized with a
                mandatory requestPolicy (as defined by the return value from requestPolicy.isMandatory()), the module
                must only return AuthStatus.SUCCESS if it was able to completely satisfy the request authentication
                policy. In this case, the module (or its context) must also have used the CallbackHandler passed to it
                by the runtime to handle a CallerPrincipalCallback using the clientSubject as argument to the callback.
                If more than one module of a context uses the CallbackHandler to handle this callback, the context is
                responsible for coordinating the calls such that the appropriate caller principal value is established.

            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="3" section="8.3.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:99</id>
            <description> If the module was not able to completely satisfy the request authentication policy, it must:
                return AuthStatus.SEND_CONTINUE - if it has established a response (available to the runtime by calling
                messageInfo.getResponseMessage) that must be sent by the runtime for the request validation to be
                effectively continued by the client. The module must have set the HTTP status code of the response to a
                value (e.g., HTTP 401 unauthorized, HTTP 303 see other, or HTTP 307 temporary redirect) that will
                indicate to the client that it should retry the request.

            </description>
            <keywords>
                <keyword>AuthStatus</keyword>
            </keywords>
            <location chapter="3" section="8.3.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:100</id>
            <description> If the module was not able to completely satisfy the request authentication policy, it must:
                return AuthStatus.SEND_FAILURE - if the request validation failed, and when the client should not retry
                the request. The module must have established a response message (available to the runtime by calling
                messageInfo.getResponseMessage) that may be sent by the runtime to inform the client that the request
                failed. The module must have set the HTTP status code of the response to a value (e.g., HTTP 403
                forbidden or HTTP 404 not found) that will indicate to the client that it should NOT retry the request.
                The runtime may choose not to send a response message, or to send a different response message (given
                that it also contains an analogous HTTP status code).

            </description>
            <keywords>
                <keyword>AuthStatus</keyword>
            </keywords>
            <location chapter="3" section="8.3.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:101</id>
            <description> If the module was not able to completely satisfy the request authentication policy, it must:
                throw an AuthException - if the request validation failed, and when the client should not retry the
                request, and when the module has not defined a response, to be sent by the runtime. If the runtime
                chooses to send a response, it must define the HTTP status code and descriptive content (of the
                response). The HTTP status code of the response must indicate to the client (e.g., HTTP 403 forbidden,
                HTTP 404 not found, or HTTP 500 internal server error) that the request failed and that it should NOT be
                retried. The decriptive content set in the response may be obtained from the AuthException.

            </description>
            <keywords>
                <keyword>AuthException</keyword>
            </keywords>
            <location chapter="3" section="8.3.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:102</id>
            <description> When validateRequest is called before the service invocation on a module that was initialized
                with an optional requestPolicy (i.e., requestPolicy.isMandatory() returns false), the module should
                attempt to satisfy the request authentication policy, but it must do so without requiring additional
                messages or interactions involving the client.

            </description>
            <keywords>
                <keyword>requestPolicy</keyword>
            </keywords>
            <location chapter="3" section="8.3.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:103</id>
            <description> If the module returns AuthStatus.SUCCESS (and the authentication policy was satisfied), the
                module (or its context) must employ a CallerPrincipalCallback. If the authentication policy was not
                satisfied, and yet the module chooses to return AuthStatus.SUCCESS, the module (or its context) must use
                a CallerPrincipalCallback to establish the containers representation of the unauthenticated caller
                within the clientSubject.

            </description>
            <keywords>
                <keyword>AuthStatus</keyword>
            </keywords>
            <location chapter="3" section="8.3.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:320</id>
            <description> If the module throws an AuthException, or returns any value other that AuthStatus.SUCCESS, the
                runtime must NOT proceed to the service invocation. The runtime must process an AuthException as
                described above for a request with a mandatory requestPolicy.
            </description>
            <keywords>
                <keyword>AuthStatus</keyword>
            </keywords>
            <location chapter="3" section="8.3.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:104</id>
            <description> When validateRequest is called after the service invocation, the module must return
                AuthStatus.SEND_SUCCESS when the module has successfully secured the application response message and
                made it available through messageInfo.getResponseMessage. The module must have set the HTTP status code
                within the response to HTTP 200 (OK). For the request to be successfully completed, the runtime must
                send the response message returned by the module.

            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="3" section="8.3.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:105</id>
            <description> If the module returns AuthStatus.SEND_FAILURE, it must have established a response message in
                messageInfo, and it must have set the HTTP status code within the response to HTTP 500 (internal server
                error). The runtime may choose not to send a response message, or to send a different response message
                (given that it also contains an HTTP 500 status code).

            </description>
            <keywords>
                <keyword>AuthStatus</keyword>
            </keywords>
            <location chapter="3" section="8.3.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:106</id>
            <description> When the module throws an AuthException, the runtime may chose not to send a response. If the
                runtime sends a response, the runtime must set the HTTP status code to HTTP 500 (internal server error),
                and the runtime must define the decriptive content of the response (perhaps by obtaining it from the
                AuthException).

            </description>
            <keywords>
                <keyword>AuthException</keyword>
            </keywords>
            <location chapter="3" section="8.3.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:107</id>
            <description> The module must return AuthStatus.SEND_CONTINUE if the response dialog is to continue. This
                status value is used to inform the calling runtime that, to successfully complete the response
                processing, it will need to be capable of continuing the message dialog by processing at least one
                additional request/response exchange (after having sent the response message returned in messageInfo).
                The module must have established (in messageInfo) a response message that will cause the client to
                continue the response processing (i.e., retry the request). For the response processing to be
                successfully completed, the runtime must send the response message returned by the module.

            </description>
            <keywords>
                <keyword>AuthStatus</keyword>
            </keywords>
            <location chapter="3" section="8.3.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:108</id>
            <description>
                The return value and AuthException semantics of secureResponse are as defined in Section 3.8.3.2, “validateRequest
                After Service Invocation.” This profile places no requirements on authentication modules with respect to
                interpreting responsePolicy values.
            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="3" section="8.3.3" />
            <comment>
                Note 1: This chapter definition seems to have been changed since
                original assertion was created so we are updating this
                particular assertions description since no test currently tests this.
                Note 2: This assertion directly implies that the secureResponse MUST be
                called AFTER service invocation except for the case where service
                invocation throws an exception.
                Note 3: see https://java.net/jira/browse/JASPIC_SPEC-9 for more details
            </comment>
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:308</id>
            <description> A ServerAuthModule must only call MessageInfo.setResponseMessage() to wrap or unwrap the
                existing response within MessageInfo.
            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="3" section="8.3.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:309</id>
            <description> During secureResponse processing, a ServerAuthModule must unwrap the messages in MessageInfo
                that it wrapped during its validateRequest processing. The unwrapped values must be established in
                MessageInfo when secureResponse returns.
            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="3" section="8.3.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:310</id>
            <description> During validateRequest processing, a ServerAuthModule must NOT unwrap a message in
                MessageInfo, and must NOT establish a wrapped message in MessageInfo unless the ServerAuthModule returns
                AuthStatus.SUCCESS.
            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="3" section="8.3.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:311</id>
            <description> When a ServerAuthModule returns a wrapped message in MessageInfo, or unwraps a message in
                MessageInfo, the message processing runtime must ensure that the HttpServletRequest and
                HttpServletResponse objects established by the ServerAuthModule are used in downstream processing.
            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="3" section="8.3.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:321</id>
            <description> The message processing runtime must fulfill the requirements defined in this section when, at
                point (2) in the messaging model, validateRequest returns AuthStatus.SUCCESS. In this case, the runtime
                must modify the HttpServletRequest as necessary to ensure that the Principal returned by
                getUserPrincipal and the String returned by getRemoteUser correspond, respectively, to the Principal
                established by validateRequest (via the CallerPrincipalCallback) and to the String obtained by calling
                getName on the established Principal. (Except when getUserPrincipal returns null; in which case the
                value returned by getRemoteUser must be null)
            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="3" section="8.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:322</id>
            <description> The runtime must also ensure that the value returned by calling getAuthType on the
                HttpServletRequest is consistent in terms of being null or non-null with the value returned by
                getUserPrincipal.
            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="3" section="8.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:323</id>
            <description> When getAuthType is to return a non-null value, the runtime must consult the Map of the
                MessageInfo object used in the call to validateRequest to determine if it contains an entry for the key
                identified in the following table. If the Map contains an entry for the key, the runtime must obtain
                (from the Map) the value corresponding to the key and establish it as the getAuthType return value.
                (from Table 2-2, the key=jakarta.servlet.http.authType and the value=a non-null String value)
            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="3" section="8.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:324</id>
            <description> (When getAuthType is to return a non-null value, the runtime must consult the Map of the
                MessageInfo object used in the call to validateRequest to determine if it contains an entry for the key
                identified in the following table.) If the Map does not contain an entry for the key, and an auth-method
                is defined in the login-config element of the deployment descriptor for the web application, the runtime
                must establish the value from the auth-method as the value returned by getAuthType.
            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="3" section="8.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:325</id>
            <description> (When getAuthType is to return a non-null value, the runtime must consult the Map of the
                MessageInfo object used in the call to validateRequest to determine if it contains an entry for the key
                identified in the following table.) If the Map does not contain an entry for the key, and the deployment
                descriptor does not define an auth-method, the runtime must establish a non-null value of its choice as
                the value returned by getAuthType.
            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="3" section="8.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:109</id>
            <description> This profile is composed of two internal profiles that partition the requirements of the
                profile into those that must be satisfied by client runtimes and those that must be satisfied by server
                runtimes. This profile is equally applicable to SOAP versions 1.1 and 1.2.

            </description>
            <keywords>
                <keyword>SOAP</keyword>
            </keywords>
            <location chapter="4" section="0" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:110</id>
            <description> The message layer value used to select the AuthConfigProvider and ServerAuthConfig objects for
                this profile must be SOAP

            </description>
            <keywords>
                <keyword>AuthConfigProvider</keyword>
                <keyword>ServerAuthConfig</keyword>
            </keywords>
            <location chapter="4" section="1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:111</id>
            <description> The application context identifier (i.e., the appContext parameter value) used by a client
                runtime to select the AuthConfigProvider, ClientAuthConfig objects pertaining to a client-side
                application context configuration scope must be as defined in Section 4.8.1. Similarly the application
                context identifier used by a server runtime to select the AuthConfigProvider and ClientAuthConfig
                objects pertaining to an server-side application context configuration scope must be defined in Section
                4.9.1

            </description>
            <keywords>
                <keyword>appContext</keyword>
            </keywords>
            <location chapter="4" section="2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:112</id>
            <description> The MessageInfo argument used in any call made by the message processing runtime to
                secureRequest, validateResponse, validateRequest, or secureResponse must have been initialized such that
                the non-null objects returned by the getRequestMessage and getResponseMessage methods of the MessageInfo
                are an instance of jakarta.xml.soap.SOAPMessage.

            </description>
            <keywords>
                <keyword>MessageInfo</keyword>
            </keywords>
            <location chapter="4" section="3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:113</id>
            <description> The getSupportedMessageTypes method of all authentication modules integrated for use with this
                profile, must include jakarta.xml.soap.SOAPMessage class in its return value.

            </description>
            <keywords>
                <keyword>getSupportedMessageTypes</keyword>
            </keywords>
            <location chapter="4" section="4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:114</id>
            <description> The CallbackHandler passed to an authentication module's initialize method is determined by
                the handler argument passed in the call to AuthConfigProvider.getClientAuthConfig or getServerAuthConfig
                that acquired the corresponding authentication context configuration object. The handler argument must
                not be null, and the argument handler and the CallbackHandler passed to the initialize method of an
                authentication modules should support the following callbacks, and it must be possible to configure the
                runtime such that the CallbackHandler passed at module initialization supports the following callbacks
                (in addition to any others required to be supported by the applicable internal profile):
                CertStoreCallback, PrivateKeyCallback, SecretKeyCallback, TrustStoreCallback

            </description>
            <keywords>
                <keyword>CallbackHandler</keyword>
            </keywords>
            <location chapter="4" section="5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:115</id>
            <description> The CallbackHandler must be initialized with any application context required to process the
                supported callbacks on behalf of the corresponding application.

            </description>
            <keywords>
                <keyword>CallbackHandler</keyword>
            </keywords>
            <location chapter="4" section="5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:116</id>
            <description> The factory implementation returned by calling the getFactory method of the abstract
                AuthConfigFactory class must have been configured such that it returns a non-null AuthConfigProvider for
                those application contexts for which pluggable authentication modules have been configured at the SOAP
                layer.

            </description>
            <keywords>
                <keyword>factory</keyword>
            </keywords>
            <location chapter="4" section="6" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:117</id>
            <description> For each application context for which it is servicing requests, the runtime must call
                getConfigProvider to acquire the provider object corresponding to the layer and application context. The
                layer and appContext arguments to getConfigProvider must be as defined in Section 4.1, Message Layer
                Identifier and Section 4.2, Application Context Identifier respectively.

            </description>
            <keywords>
                <keyword>getConfigProvider</keyword>
            </keywords>
            <location chapter="4" section="6" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:118</id>
            <description> A null return value from getConfigProvider indicates that pluggable authentication modules
                have not been configured at the layer for the application context and that the messaging runtime must
                proceed to perform its SOAP message processing without reliance on this profile.

            </description>
            <keywords>
                <keyword>getConfigProvider</keyword>
            </keywords>
            <location chapter="4" section="6" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:119</id>
            <description> In cases where a runtime chooses to delegate authentication session management to
                authentication contexts and their contained authentication modules, the AuthConfigPrivider must have
                been configured, as described in Section 2.1.2.2, What the Provider Must Do, to return non-null
                authentication contexts for all operation identifiers, independent of whether or not the corresponding
                operation is protected.

            </description>
            <keywords>
                <keyword>AuthConfigPrivider</keyword>
            </keywords>
            <location chapter="4" section="7" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="deprecated"
            testable="false">
            <id>JASPIC:SPEC:120</id>
            <description> If getOperation returns a non-null operation identifier, then the operation identifier must be
                the String value corresponding to the operation name appearing in the service description (i.e., WSDL).

            </description>
            <keywords>
                <keyword>getOperation</keyword>
            </keywords>
            <location chapter="4" section="7.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="deprecated"
            testable="false">
            <id>JASPIC:SPEC:121</id>
            <description> As
                defined in Section 2.1.3, “Acquire AuthContext Identifier,” on page 17, the authentication context
                identifier used in the call to getAuthContext must be equivalent to the value that would be acquired by
                calling getAuthContextID with the MessageInfo that will be used in the corresponding call to
                secureRequest (by a client runtime) or validateRequest (by a server runtime).


            </description>
            <keywords>
                <keyword>Authentication Context Identifiers</keyword>
            </keywords>
            <location chapter="4" section="7.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:122</id>
            <description> Each authentication context object obtained via getAuthContext must initialize its
                encapsulated authentication modules with a non-null requestPolicy and/or a non-null responsePolicy; such
                that at least one of requestPolicy or responsePolicy is not null.

            </description>
            <keywords>
                <keyword>getAuthContext</keyword>
            </keywords>
            <location chapter="4" section="7.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:123</id>
            <description> Unless the client runtime is embedded in a server runtime (e.g.; an invocation of a web
                service by a servlet running in a Servlet container), The CallbackHandler passed to
                ClientAuthModule.initialize must support the following callbacks: NameCallback, PasswordCallback

            </description>
            <keywords>
                <keyword>ClientAuthModule</keyword>
            </keywords>
            <location chapter="4" section="8.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:124</id>
            <description> If a non-null AuthConfigProvider is returned (by the call to getConfigProvider), the messaging
                runtime must call getClientAuthConfig on the provider to obtain the authentication context configuration
                object pertaining to the application context at the layer. The layer and appContext arguments of the
                call to getClientAuthConfig must be the same as those used to acquire the provider, and the handler
                argument must be as defined in Section 4.8.1, ?CallbackHandler Requirements? for a client runtime.

            </description>
            <keywords>
                <keyword>getClientAuthConfig</keyword>
            </keywords>
            <location chapter="4" section="8.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:125</id>
            <description>
                If a non-null AuthConfigProvider is returned (by the call to getConfigProvider), the messaging runtime
                must call getClientAuthConfig on the provider to obtain the authentication context configuration object
                pertaining to the application context at the layer. The layer and appContext arguments of the call to
                getClientAuthConfig must be the same as those used to acquire the provider, and the handler argument
                must be as defined in Section 4.8.2, CallbackHandler Requirements, for a client runtime.

            </description>
            <keywords>
                <keyword>getAuthContext</keyword>
            </keywords>
            <location chapter="4" section="8.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:126</id>
            <description> A null return value from getAuthContext indicates that pluggable authentication modules have
                not been configured for the operation within the authentication context configuration scope, and that
                the client runtime must proceed to perform its SOAP message processing without reliance on this profile.

            </description>
            <keywords>
                <keyword>getAuthContext</keyword>
            </keywords>
            <location chapter="4" section="8.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:127</id>
            <description> A non-null Subject corresponding to the client must be passed as the clientSubject in the
                getAuthContext call.

            </description>
            <keywords>
                <keyword>getAuthContext</keyword>
            </keywords>
            <location chapter="4" section="8.4.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:128</id>
            <description> A null value may be passed for the properties argument in all calls made to getAuthContext

            </description>
            <keywords>
                <keyword>getAuthContext</keyword>
            </keywords>
            <location chapter="4" section="8.4.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:129</id>
            <description> Each ClientAuthContext obtained via getAuthContext must initialize its encapsulated
                ClientAuthModule objects with requestPolicy and responsePolicy objects (or null values) that are
                compatible with the requirements and capabilities of the service invocation at the service.

            </description>
            <keywords>
                <keyword>getAuthContext</keyword>
            </keywords>
            <location chapter="4" section="8.4.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:130</id>
            <description> If the client runtime obtained a non-null ClientAuthContext by using the operation identifier
                corresponding to the request message, then at point (1) in the message processing model, the runtime
                must call secureRequest on the ClientAuthContext, and at point (4) the runtime must call
                validateResponse on the ClientAuthContext.

            </description>
            <keywords>
                <keyword>secureRequest</keyword>
            </keywords>
            <location chapter="4" section="8.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:131</id>
            <description> The messageInfo argument used in a call to secureRequest must have been initialized by the
                runtime such that its getRequestMessage will return the SOAP request message being processed by the
                runtime.

            </description>
            <keywords>
                <keyword>secureRequest</keyword>
            </keywords>
            <location chapter="4" section="8.4.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:132</id>
            <description> When a corresponding call is made to validateResponse, it must be made with the same
                messageInfo and clientSubject arguments used in the corresponding call to secureRequest, and it must
                have been initialized by the runtime such that its getResponseMessage method will return the SOAP
                response message being processed by the runtime.

            </description>
            <keywords>
                <keyword>validateResponse</keyword>
            </keywords>
            <location chapter="4" section="8.5.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:133</id>
            <description> This profile requires that the message processing runtime establish the following key-value
                pairs within the Map of the MessageInfo passed in the calls to secureRequest and validateResponse Key=
                jakarta.xml.ws.wsdl.service
                Value= qualified service name, represented as a javax.xml.namespace.QName.

            </description>
            <keywords>
                <keyword>MessageInfo</keyword>
            </keywords>
            <location chapter="4" section="8.5.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:134</id>
            <description> The clientSubject used in the call to getAuthContext must be used in the call to secureRequest
                and for any corresponding calls to validateResponse.

            </description>
            <keywords>
                <keyword>clientSubject</keyword>
            </keywords>
            <location chapter="4" section="8.5.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:135</id>
            <description> When secureRequest is called on a module that was initialized with a mandatory request policy
                (as defined by the return value from requestPolicy.isMandatory()), the module must only return
                AuthStatus.SEND_SUCCESS if it was able to completely satisfy the request policy.

            </description>
            <keywords>
                <keyword>secureRequest</keyword>
            </keywords>
            <location chapter="4" section="8.5.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:136</id>
            <description> If the module was not able to completely satisfy the response policy, it must: return
                AuthStatus.SEND_CONTINUE - if it has established a request (available to the runtime by calling
                messageInfo.getRequestMessage) that must be sent by the runtime for the response validation to be
                effectively continued by the client.

            </description>
            <keywords>
                <keyword>AuthStatus</keyword>
            </keywords>
            <location chapter="4" section="8.5.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:137</id>
            <description> If the module was not able to completely satisfy the response policy, it must: return
                AuthStatus.FAILURE - if the response validation failed. The module must have established a response
                message containing a SOAP fault element (available to the runtime by calling
                messageInfo.getResponseMessage) that may be returned to the application to indicate that the request
                failed.

            </description>
            <keywords>
                <keyword>AuthStatus</keyword>
            </keywords>
            <location chapter="4" section="8.5.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:138</id>
            <description> If the module was not able to completely satisfy the response policy, it must: throw an
                AuthException - if the response validation failed. The runtime may choose to return a response message
                containing a SOAP fault element, in which case, the runtime must define the content of the message and
                of the fault, and may do so based on the content of the AuthException.

            </description>
            <keywords>
                <keyword>AuthException</keyword>
            </keywords>
            <location chapter="4" section="8.5.3" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:139</id>
            <description> When secureRequest is called on a module that was initialized with an optional requestPolicy
                (i.e., requestPolicy.isMandatory() returns false), the module should attempt to satisfy the request
                policy but it must do so without requiring additional messages or interactions involving the service.
                Independent of whether the request policy is satisfied, the module may return AuthStatus.SUCCESS.

            </description>
            <keywords>
                <keyword>secureRequest</keyword>
            </keywords>
            <location chapter="4" section="8.5.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:140</id>
            <description> When validateResponse is called after the service invocation on a module that was initialized
                with an undefined response policy (i.e., responsePolicy == null), the module must return
                AuthStatus.SUCCESS.

            </description>
            <keywords>
                <keyword>validateResponse</keyword>
            </keywords>
            <location chapter="4" section="8.5.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:141</id>
            <description> When validateResponse is called after the service invocation on a module that was initialized
                with a mandatory response policy (as defined by the return value from responsePolicy.isMandatory()), the
                module must only return AuthStatus.SUCCESS if it was able to completely satisfy the response policy.

            </description>
            <keywords>
                <keyword>validateResponse</keyword>
            </keywords>
            <location chapter="4" section="8.5.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:142</id>
            <description> If the module was not able to completely satisfy the response policy, it must: return
                AuthStatus.SEND_CONTINUE - if it has established a request (available to the runtime by calling
                messageInfo.getRequestMessage) that must be sent by the runtime for the response validation to be
                effectively continued by the client.

            </description>
            <keywords>
                <keyword>getRequestMessage</keyword>
            </keywords>
            <location chapter="4" section="8.5.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:143</id>
            <description> If the module was not able to completely satisfy the response policy, it must: return
                AuthStatus.FAILURE - if the response validation failed. The module must have established a response
                message containing a SOAP fault element (available to the runtime by calling
                messageInfo.getResponseMessage) that may be returned to the application to indicate that the request
                failed.

            </description>
            <keywords>
                <keyword>getResponseMessage</keyword>
            </keywords>
            <location chapter="4" section="8.5.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:144</id>
            <description> If the module was not able to completely satisfy the response policy, it must: throw an
                AuthException - if the response validation failed. The runtime may choose to return a response message
                containing a SOAP fault element, in which case, the runtime must define the content of the message and
                of the fault, and may do so based on the content of the AuthException.

            </description>
            <keywords>
                <keyword>AuthException</keyword>
            </keywords>
            <location chapter="4" section="8.5.4" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:145</id>
            <description> When validateResponse is called after the service invocation on a module that was initialized
                with an optional responsePolicy (i.e., responsePolicy.isMandatory() returns false), the module should
                attempt to satisfy the response policy but it must do so without requiring additional messages or
                interactions involving the service.

            </description>
            <keywords>
                <keyword>validateResponse</keyword>
            </keywords>
            <location chapter="4" section="8.5.4" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:146</id>
            <description> Independent of whether the response policy is satisfied, the module may return
                AuthStatus.SUCCESS. if the module determines that an invalid security context was used to secure the
                response, then the module may return AuthStatus.FAILURE

            </description>
            <keywords>
                <keyword>AuthStatus</keyword>
            </keywords>
            <location chapter="4" section="8.5.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:147</id>
            <description> When validateResponse is called before the service invocation, the module must return
                AuthStatus.SEND_CONTINUE if the request dialog is to continue.

            </description>
            <keywords>
                <keyword>validateResponse</keyword>
            </keywords>
            <location chapter="4" section="8.5.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:148</id>
            <description> If the module returns AuthStatus.FAILURE, it must have established a SOAP message containing a
                SOAP fault element as the response in messageInfo and that may be returned to the application to
                indicate that the request failed. If the module throws an AuthException, the runtime may choose to
                return a response message containing a SOAP fault element, in which case, the runtime must define the
                content of the message and of the fault, and may do so based on the content of the AuthException.

            </description>
            <keywords>
                <keyword>messageInfo</keyword>
            </keywords>
            <location chapter="4" section="8.5.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:149</id>
            <description> The CallbackHandler passed to ServerAuthModule.initialize must support the following
                callbacks: CallerPrincipalCallback, GroupPrincipalCallback , PasswordValidationCallback .

            </description>
            <keywords>
                <keyword>CallbackHandler</keyword>
            </keywords>
            <location chapter="4" section="9.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:150</id>
            <description> If a non-null AuthConfigProvider is returned (by the call to getConfigProvider), the messaging
                runtime must call getServerAuthConfig on the provider to obtain the authentication context configuration
                object pertaining to the application context at the layer.

            </description>
            <keywords>
                <keyword>AuthConfigProvider</keyword>
            </keywords>
            <location chapter="4" section="9.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="deprecated"
            testable="false">
            <id>JASPIC:SPEC:151</id>
            <description> A null return value from getAuthContext indicates that pluggable authentication modules have
                not been configured for the operation at the layer and for the application context and that the server
                runtime must proceed to perform its SOAP message processing without reliance on this profile.

            </description>
            <keywords>
                <keyword>getAuthContext</keyword>
            </keywords>
            <location chapter="4" section="9.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="deprecated"
            testable="false">
            <id>JASPIC:SPEC:152</id>
            <description> A null value may be passed for the properties argument in all calls made to getAuthContext

            </description>
            <keywords>
                <keyword>getAuthContext</keyword>
            </keywords>
            <location chapter="4" section="9.3.1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:153</id>
            <description> When a non-null requestPolicy is used to initialize the authentication modules of the
                ServerAuthContext must be constructed such that the value obtained by calling isMandatory on the
                requestPolicy accurately reflects whether (i.e., true return value) or not (i.e, false return value)
                message protection is required to access the web service invocation corresponding to the MessageInfo
                used to acquire the ServerAuthContext. Similarly, the responsePolicy used to initialize the
                authentication modules must be constructed such that the value obtained by calling isMandatory on the
                responsePolicy accurately reflects whether (i.e., true return value) or not (i.e, false return value)
                message protection is required (within the SOAP messaging layer) on the response(if there is one)
                resulting from the corresponding webservice invocation.
            </description>
            <keywords>
                <keyword>requestPolicy</keyword>
            </keywords>
            <location chapter="4" section="9.4.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:154</id>
            <description>
                Calling getTargetPolicies on the requestPolicy corresponding to a web service invocation for which a
                SOAP layer client identity is to be established as the caller identity must return an array containing at least
                one TargetPolicy for which calling getProtectionPolicy.getID() returns one of the following values:
                ProtectionPolicy.AUTHENTICATE_SENDER, ProtectionPolicy.AUTHENTICATE_CONTENT


            </description>
            <keywords>
                <keyword>getTargetPolicies</keyword>
            </keywords>
            <location chapter="4" section="9.4.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:155</id>
            <description> If the server runtime obtained a non-null ServerAuthContext by using the authentication
                context identifier corresponding to the request message, then at point (2) in the message processing
                model, the runtime must call validateRequest on the ServerAuthContext, and at point (3) the runtime must
                call secureResponse on the ServerAuthContext.

            </description>
            <keywords>
                <keyword>validateRequest</keyword>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="4" section="9.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:156</id>
            <description> If the call to validateRequest returns AuthStatus.SUCCESS, the runtime must perform any web
                service authorization processing2 required by the runtime as a prerequisite to accessing the target
                resource. If authentication is required for the request to be authorized, the runtime must determine
                whether the authentication identity
                established in the clientSubject is authorized to access the resource.

            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="4" section="9.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:157</id>
            <description>
                In a JSR 115 compatible runtime, the
                identity tested for authorization must be comprised of exactly the Principal objects of the clientSubject. If
                the request is NOT authorized, and the message-exchange pattern is not one-way, the runtime must set
                within the response (within messageInfo) a SOAP fault element as defined by the runtime. If the request
                was determined to be authorized, it must be dispatched to the resource. Otherwise the request must NOT be
                dispatched and the runtime must proceed to point (3) in the message processing model (as appropriate to
                the message exchange pattern).

            </description>
            <keywords>
                <keyword>clientSubject</keyword>
            </keywords>
            <location chapter="4" section="9.5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:158</id>
            <description>
                If the invocation of the resource results in an exception being thrown by the resource to the runtime
                and the message exchange pattern is not one-way, the runtime must set within the response (within
                messageInfo) a SOAP fault element as defined by the runtime. Following the resource invocation, and if
                the message exchange pattern is not one-way, the runtime must proceed to point (3) in the message
                processing model. At point (3) in the message processing model, the runtime must call secureResponse on
                the same ServerAuthContext used in the corresponding call to validateRequest and with the same
                MessageInfo object.
            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="4" section="9.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="deprecated"
            testable="false">
            <id>JASPIC:SPEC:159</id>
            <description> The call to secureResponse must not be made if the resource throws an exception to the calling
                runtime.

            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="4" section="9.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="deprecated"
            testable="false">
            <id>JASPIC:SPEC:160</id>
            <description> This profile requires that the message processing runtime establish the following key-value
                pairs within the Map of the MessageInfo object passed in the calls to validateRequest and
                secureResponse. Key= jakarta.xml.ws.wsdl.service value= the application context identifier as defined in
                Sec 4.2 Application Context Identifier.
            </description>
            <keywords>
                <keyword>MessageInfo</keyword>
            </keywords>
            <location chapter="4" section="9.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:161</id>
            <description> A new clientSubject must be instantiated and passed in any calls made to validateRequest.

            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="4" section="9.5.2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:162</id>
            <description> When validateRequest is called before the service invocation on a module that was initialized
                with an undefined request policy (i.e., requestPolicy == null), the module must return
                AuthStatus.SUCCESS

            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="4" section="9.5.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:163</id>
            <description> When validateRequest is called before the service invocation on a module initialized with a
                mandatory request policy (as defined by the return value from requestPolicy.isMandatory()), the module
                must only return AuthStatus.SUCCESS if it was able to completely satisfy the request policy.

            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="4" section="9.5.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:164</id>
            <description>
                If the module returns AuthStatus.SUCCESS, and the request policy was satisfied
                (and included a TargetPolicy element as described above), then the module (or its context) must employ
                the CallerPrincipalCallback as described above. If the request policy was not satisfied (and included a
                TargetPolicy element as described above), and yet the module chooses to return AuthStatus.SUCCESS,
                the module (or its context) must use a CallerPrincipalCallback to establish the container’s representation
                of the unauthenticated caller within the clientSubject

            </description>
            <keywords>
                <keyword>TargetPolicy</keyword>
            </keywords>
            <location chapter="4" section="9.5.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:165</id>
            <description> If the module determines that an invalid or
                incomplete security context was used to secure the request, then the module may return
                AuthStatus.SEND_FAILURE, AuthStatus.SEND_CONTINUE, or throw an AuthException.If the module
                throws an AuthException, or returns any value other that AuthStatus.SUCCESS, the runtime must NOT
                proceed to the service invocation. The runtime must process an AuthException as described above for a
                request with a mandatory requestPolicy. The runtime must process any return value other than
                AuthStatus.SUCCESS as it would be processed if it were returned for a request with a mandatory
                requestPolicy.

            </description>
            <keywords>
                <keyword>getResponseMessage</keyword>
            </keywords>
            <location chapter="4" section="9.5.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:166</id>
            <description> If the module was not able to completely satisfy the request policy, it must: return
                AuthStatus.SEND_FAILURE - if the request validation failed, and when the module has established a SOAP
                message containing a fault element (available to the runtime by calling messageInfo.getResponseMessage)
                that may be sent by the runtime to inform the client that the request failed.

            </description>
            <keywords>
                <keyword>getResponseMessage</keyword>
            </keywords>
            <location chapter="4" section="9.5.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:167</id>
            <description> If the module was not able to completely satisfy the request policy, it must: throw an
                AuthException - if the request validation failed, and when the module has NOT defined a response, to be
                sent by the runtime. If the runtime chooses to send a response, it must define a SOAP message containing
                a SOAP fault element, and may use the content of the AuthException to do so.

            </description>
            <location chapter="4" section="9.5.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:168</id>
            <description> When validateRequest is called before the service invocation on a module that was initialized
                with an optional request policy (i.e., requestPolicy.isMandatory() returns false), the module should
                attempt to satisfy the request policy but it must do so without requiring additional messages or
                interactions involving the client. If the request policy is satisfied, and it included a TargetPolicy
                element with a PotectionPolicy of AUTHENTICATE_SOURCE or AUTHENTICATE_CONTENT, then the module must
                employ the CallerPrincipalCallback as described above.

            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="4" section="9.5.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="deprecated"
            testable="false">
            <id>JASPIC:SPEC:169</id>
            <description> Independent of whether the authentication policy is satisfied, the module may return
                AuthStatus.SUCCESS. if the module determines that an invalid security context was used to secure the
                request, or that the request requires additional processing (e.g. decryption) to be suitable for
                processing by the runtime, then the module may return AuthStatus.FAILURE or throw an AuthException. In
                which case, the runtime must determine whether to terminate the request or to (attempt to) process it.

            </description>
            <keywords>
                <keyword>AuthStatus</keyword>
            </keywords>
            <location chapter="4" section="9.4.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:170</id>
            <description> When validateRequest is called after the service invocation, the module must return
                AuthStatus.SEND_SUCCESS when the module has successfully secured the application response message and
                made it available via messageInfo.getResponseMessage. For the request to be successfully completed, the
                runtime must send the response message returned by the module.

            </description>
            <keywords>
                <keyword>validateRequest</keyword>
            </keywords>
            <location chapter="4" section="9.5.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:171</id>
            <description> When securing of the application response message has failed, and the response dialog is to be
                terminated, the module must return AuthStatus.SEND_FAILURE or throw an AuthException.

            </description>
            <location chapter="4" section="9.5.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:172</id>
            <description> If the module returns AuthStatus.SEND_FAILURE, it must have established a SOAP message
                containing a SOAP fault element as the response in messageInfo. The runtime may choose not to send a
                response message, or to send a different response message.

            </description>
            <keywords>
                <keyword>messageInfo</keyword>
            </keywords>
            <location chapter="4" section="9.5.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:173</id>
            <description> When the module throws an AuthException, the runtime may chose not to send a response. If the
                runtime sends a response, the runtime must define the content of the response.

            </description>
            <keywords>
                <keyword>AuthException</keyword>
            </keywords>
            <location chapter="4" section="9.5.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:174</id>
            <description> The module must return AuthStatus.SEND_CONTINUE if the response dialog is to continue. This
                status value is used to inform the calling runtime that (in order to successfully complete the response
                processing) it will need to be capable of continuing the message dialog by processing at least one
                additional request/response exchange (after having sent the response message returned in messageInfo).

            </description>
            <keywords>
                <keyword>messageInfo</keyword>
            </keywords>
            <location chapter="4" section="9.5.3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:175</id>
            <description> When secureResponse is called on a module that was initialized with an undefined
                responsePolicy (i.e., responsePolicy == null), the module must return AuthStatus.SUCCESS. Otherwise, the
                AuthStatus return value and AuthException semantics of secureResponse are as defined in validateRequest
                After Service Invocation.

            </description>
            <keywords>
                <keyword>secureResponse</keyword>
            </keywords>
            <location chapter="4" section="9.5.4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:176</id>
            <description> The ServerAuthModule must create an instance of a javax.security.auth.login.LoginContext. If
                the ServerAuthModule passes a custom javax.security.auth.login.Configuration object to the constructor,
                then it also passes a custom value as the name input.

            </description>
            <keywords>
                <keyword>ServerAuthModule</keyword>
            </keywords>
            <location chapter="5" section="1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:177</id>
            <description> If the ServerAuthModule does not pass a custom Configuration object to the constructor, then
                it must pass its own fully qualified class name as the name input. In this case, the configuration
                administrator must configure the relevant LoginModule objects in an entry for that class name, or must
                configure the LoginModule objects into the standard default entry called other.

            </description>
            <keywords>
                <keyword>LoginModule</keyword>
            </keywords>
            <location chapter="5" section="1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:178</id>
            <description> If the ServerAuthModule passes a Subject to the LoginContext constructor, it must pass its
                client Subject.

            </description>
            <keywords>
                <keyword>LoginContext</keyword>
            </keywords>
            <location chapter="5" section="1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:179</id>
            <description> The ServerAuthModule must pass a CallbackHandler to the constructor and the passed
                CallbackHandler must conform to the requirements of Section 5.3, Standard Callbacks.

            </description>
            <keywords>
                <keyword>CallbackHandler</keyword>
            </keywords>
            <location chapter="5" section="1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:180</id>
            <description> A new LoginContext instance should be created for each new request, and a LoginContext
                instance should not be shared across different requests.

            </description>
            <keywords>
                <keyword>LoginContext</keyword>
            </keywords>
            <location chapter="5" section="1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:181</id>
            <description> Once a LoginContext object has been created, the LoginContext.login method may be invoked from
                within the ServerAuthModule.validateRequest method to delegate security processing to the LoginModule
                objects configured in the LoginContext.

            </description>
            <keywords>
                <keyword>LoginContext</keyword>
            </keywords>
            <location chapter="5" section="1" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:182</id>
            <description> A LoginModule must only perform protocolindependent security processing (for example,
                verifying a username/password that was transmitted in the request).

            </description>
            <keywords>
                <keyword>LoginModule</keyword>
            </keywords>
            <location chapter="5" section="2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:183</id>
            <description> A LoginModule requests information from the ServerAuthModule using the ServerAuthModule
                provided CallbackHandler. Since the LoginModule must only perform protocol-independent operations, it
                follows that any callback it requests from the handler must also be protocol-independent.

            </description>
            <keywords>
                <keyword>LoginModule</keyword>
            </keywords>
            <location chapter="5" section="2" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:184</id>
            <description> This profile requires that the CallbackHandler provided by the ServerAuthModule to the
                LoginContext constructor support the javax.security.auth.callback.NameCallback and the
                javax.security.auth.callback.PasswordCallback.

            </description>
            <keywords>
                <keyword>NameCallback</keyword>
                <keyword>PasswordCallback</keyword>
            </keywords>
            <location chapter="5" section="3" />
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:326</id>
            <description> If the ServerAuthModule passes its client Subject to the LoginContext constructor, the
                CallbackHandler provided to the LoginContext constructor must also support the GroupPrincipalCallback.
            </description>
            <keywords>
                <keyword>CallbackHandler</keyword>
            </keywords>
            <location chapter="5" section="3" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:185</id>
            <description> If authentication succeeds, a LoginModule may update its Subject instance with authenticated
                Principal and credential objects.

            </description>
            <keywords>
                <keyword>LoginModule</keyword>
            </keywords>
            <location chapter="5" section="4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:186</id>
            <description> If the ServerAuthModule did not pass its client Subject to the LoginContext constructor, then
                it must transfer the Principals and credentials from the LoginContext Subject to the client Subject.

            </description>
            <keywords>
                <keyword>LoginContext</keyword>
            </keywords>
            <location chapter="5" section="4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:327</id>
            <description> If the ServerAuthModule is implementing a profile of this specification that requires the
                module to employ the CallerPrincipalCallback, then the ServerAuthModule must satisfy this requirement
                using the CallbackHandler provided to the ServerAuthModule, and the CallerPrincipalCallback must be
                constructed using the name value that would be obtained by the LoginModule if it uses its
                CallbackHandler to handle a NameCallback.
                (note 1: The CallerPrincipalCallback may be constucted with a String argument containing the name value, or with a
                Principal argument whose getName method returns the name value.)

            </description>
            <keywords>
                <keyword>LoginContext</keyword>
            </keywords>
            <location chapter="5" section="4" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:187</id>
            <description> When ServerAuthModule.cleanSubject is called on the client Subject, the cleanSubject method
                must invoke the LoginContext.logout method.

            </description>
            <keywords>
                <keyword>cleanSubject</keyword>
            </keywords>
            <location chapter="5" section="5" />
        </assertion>
        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:188</id>
            <description> If the LoginContext instance throws a LoginException, the ServerAuthModule must throw a
                corresponding AuthException. The LoginException may be established as the cause of the AuthException.

            </description>
            <keywords>
                <keyword>LoginContext</keyword>
            </keywords>
            <location chapter="5" section="6" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:189</id>
            <description> The message layer value used to select the AuthConfigProvider and ServerAuthConfig objects for
                this profile must be JMS

            </description>
            <keywords>
                <keyword>AuthConfigProvider</keyword>
                <keyword>ServerAuthConfig</keyword>
            </keywords>
            <location chapter="6" section="1" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:190</id>
            <description> The application context identifier (i.e., the appContext parameter value) used to select the
                AuthConfigProvider, ClientAuthConfig, and ServerAuthConfig objects for a specific application shall be
                the name of the Destination.

            </description>
            <keywords>
                <keyword>appContext</keyword>
            </keywords>
            <location chapter="6" section="2" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:191</id>
            <description> The MessageInfo argument used in any call made by the message processing runtime to
                validateRequest or secureResponse must have been initialized such that the non-null objects returned by
                the getRequestMessage and getResponseMessage methods of the AuthParam are an instance of
                jakarta.jms.Message.

            </description>
            <keywords>
                <keyword>AuthParam</keyword>
            </keywords>
            <location chapter="6" section="3" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:192</id>
            <description> The getSupportedMessageTypes method of all authentication modules integrated for use with this
                profile, must include jakarta.jms.Message in its return value.

            </description>
            <keywords>
                <keyword>getSupportedMessageTypes</keyword>
            </keywords>
            <location chapter="6" section="4" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:193</id>
            <description> The factory implementation returned by calling the getFactory method of the abstract
                AuthConfigFactory class must have been configured such that it returns a non-null AuthConfigProvider for
                those application contexts for which pluggable authentication modules have been configured at the JMS
                layer.
            </description>
            <keywords>
                <keyword>AuthConfigFactory</keyword>
            </keywords>
            <location chapter="6" section="6" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:194</id>
            <description> For each JMS Destination for which it is servicing requests, the runtime must call
                getConfigProvider to acquire the corresponding provider object.
            </description>
            <keywords>
                <keyword>getConfigProvider</keyword>
            </keywords>
            <location chapter="6" section="6" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:195</id>
            <description> For each JMS Destination for which it is servicing requests, the runtime must call
                getConfigProvider to acquire the corresponding provider object. The layer and appContext arguments to
                getConfigProvider must be as defined in Section 6.1, 'Message Layer Identifier' and Section 6.2,
                'Application Context Identifier' respectively.
            </description>
            <keywords>
                <keyword>getConfigProvider</keyword>
            </keywords>
            <location chapter="6" section="6" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:196</id>
            <description> A null return value from getConfigProvider indicates that pluggable authentication modules
                have not been configured at the layer for the application context and that the messaging runtime must
                proceed to perform its JMS message processing without reliance on this profile.
            </description>
            <keywords>
                <keyword>getConfigProvider</keyword>
            </keywords>
            <location chapter="6" section="6" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:197</id>
            <description> When a non-null AuthConfigProvider is returned by the factory, the provider must have been
                configured with the information required to initialize the authentication contexts for the (one or more)
                JMS Destinations for which the provider is registered (at the factory).
            </description>
            <keywords>
                <keyword>AuthConfigPrivider</keyword>
            </keywords>
            <location chapter="6" section="7" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:198</id>
            <description> If getOperation returns a non-null operation identifier, then the operation identifier must be
                the String value defined as follows:
                - When the message is a request for a QueueConnection or a TopicConnection, then the operation
                identifier is the String value representing the JNDI name of the Connection Factory.
                - When the message is a request to create a publisher or subscriber, or a sender or receiver,
                then the operation identifier must be the String value corresponding to the Destination name.
            </description>
            <keywords>
                <keyword>getOperation</keyword>
            </keywords>
            <location chapter="6" section="7.1" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:199</id>
            <description> The following must be satisfied by a runtime operating in the client role: A runtime may
                operate in both the client and server roles.
            </description>
            <location chapter="6" section="8" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:200</id>
            <description> The messageInfo argument used in a call to secureRequest must have been initialized by the
                runtime such that its getRequestMessage will return the JMS request message being processed by the
                runtime.
            </description>
            <keywords>
                <keyword>secureRequest</keyword>
            </keywords>
            <location chapter="6" section="8.4.1" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:201</id>
            <description> When a corresponding call is made to validateResponse, it must be made with the same
                messageInfo and clientSubject arguments used in the corresponding call to secureRequest, and it must
                have been initialized by the runtime such that its getResponseMessage method will return the JMS
                response message being processed by the runtime.
            </description>
            <keywords>
                <keyword>validateResponse</keyword>
            </keywords>
            <location chapter="6" section="8.4.1" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:202</id>
            <description> When secureRequest is called on a module that was initialized with a mandatory request policy
                (as defined by the return value from requestPolicy.isMandatory()), the module must only return
                AuthStatus.SEND_SUCCESS if it was able to completely satisfy the request policy.
            </description>
            <keywords>
                <keyword>secureRequest</keyword>
            </keywords>
            <location chapter="6" section="8.4.3" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:203</id>
            <description> When secureRequest is called on a module that was initialized with a mandatory request policy
                (as defined by the return value from requestPolicy.isMandatory()), If the module was not able to
                completely satisfy the response policy, it must:
                - return AuthStatus.SEND_CONTINUE - if it has established a request
                - return AuthStatus.FAILURE - if the response validation failed.
                - throw an AuthException - if the response validation failed.
            </description>
            <keywords>
                <keyword>secureRequest</keyword>
            </keywords>
            <location chapter="6" section="8.4.3" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:204</id>
            <description> When secureRequest is called on a module that was initialized with an optional requestPolicy
                (i.e.,requestPolicy.isMandatory() returns false), if the module attempts to satisfy the request policy,
                it must do so without requiring additional messages or interactions involving the service.
            </description>
            <keywords>
                <keyword>secureRequest</keyword>
            </keywords>
            <location chapter="6" section="8.4.3" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="false">
            <id>JASPIC:SPEC:205</id>
            <description> The requirements of this profile that must be satisfied by a runtime operating in the server
                role are:
                - Receives a message from a Sender before reaching the Queue
                - Receives a message from a Publisher on the way to a Topic
                - Receives a request for creation of a TopicPublisher or QueueSender
                - Receives a message from the a JMS Provider
            </description>
            <location chapter="6" section="9" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:206</id>
            <description> The messageInfo argument used in a call to validateRequest must have been initialized by the
                runtime such that its getRequestMessage will return the JMS request message being processed by the
                runtime.
            </description>
            <keywords>
                <keyword>getRequestMessage</keyword>
            </keywords>
            <location chapter="6" section="9.4.1" />
        </assertion>
        <assertion required="false" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:207</id>
            <description> When a corresponding call is made to secureResponse, it must be made with the same messageInfo
                and serviceSubject arguments used in the corresponding call to validateRequest, and it must have been
                initialized by the runtime such that its getResponseMessage method will return the JMS response message
                being processed by the runtime.
            </description>
            <keywords>
                <keyword>secureResponse</keyword>
                <keyword>getResponseMessage</keyword>
            </keywords>
            <location chapter="6" section="9.4.1" />
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:208</id>
            <description> The application context identifier used by a client-runtime to acquire the AuthConfigProvider
                and
                ClientAuthConfig objects pertaining to the client side processing of a web service invocation shall begin
                with a client scope identifier that identifies the client. If the client-runtime may host multiple client
                applications, then the client scope identifier must differentiate among the client applications deployed
                within the runtime. In runtimes where applications are differentiated by unambiguous application
                identifiers, an application identifier may be used as the client scope identifier. Where application
                identifiers are not defined or suitable, the location (for example, its file path) of the client archive from
                which the invocation will originate may be used as the client scope identifier
                In addition to its client scope identifier, the application context identifier must include a client
                reference to the service. If a service reference is defined for the invocation (for example, by using a
                WebServiceRef annotation as defined in the JAXWS 2.0 or JAXWS 2.1 Specifications), the client
                reference to the service must be the name value of the service reference. If a service reference was not
                defined for the invocation, the client reference to the service must be the web service URL.
                A client application context identifier must be the String value composed by concatenating the client
                scope identifier, a blank separator character, and the client reference to the service.
                AppContextID ::= client-scope-identfier blank client-reference
            </description>
            <keywords>
                <keyword>Client-Side Application Context Identifier</keyword>
            </keywords>
            <location chapter="4" section="8.1" />
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:209</id>
            <description> The application context identifier used by a server-runtime to acquire the AuthConfigProvider
                and
                ServerAuthConfig objects pertaining to the endpoint side processing of an invocation shall be the String
                value constructed by concatenating a host name, a blank separator character, and the path3 component of
                the service endpoint URI corresponding to the webservice.
                AppContextID ::= hostname blank service-endpoint-uri
                In the definition of server-side application context identifiers, this profile uses the term host name to
                refer to the logical host that performs the service corresponding to a service invocation. Web service
                invocations may be directed to a logical host using various physical or virtual host names or addresses, and
                a message processing runtime may be composed of multiple logical hosts. Systems or administrators that
                register AuthConfigProvider objects with specific server-side application context identifiers must have an
                ability to determine the hostname for which they wish to perform the registration.

            </description>
            <keywords>
                <keyword>Server-Side Application Context Identifier</keyword>
            </keywords>
            <location chapter="4" section="9.1" />
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:328</id>
            <description>
                getConfigProvider():
                All factories shall employ the following precedence rules to select the registered AuthConfigProvider that matches the
                layer and appContext arguments:
                1. The provider that is specifically registered for both the
                corresponding message layer and appContext shall be selected.
                2. If no provider is selected according to
                the preceding rule, the provider specifically registered for the corresponding appContext and for all
                message layers shall be selected.
                3. If no provider is selected according to the preceding rules, the
                provider specifically registered for the corresponding message layer and for all appContexts shall be
                selected.
                4. If no provider is selected according to the preceding rules, the provider registered for all
                message layers and for all appContexts shall be selected.
                5. If no provider is selected according to the
                preceding rules, the factory shall terminate its search for a registered provider.

                The above precedence
                rules apply equivalently to registrations created with a null or non-null className argument.
            </description>
            <keywords>
                <keyword>AuthConfigFactory</keyword>
            </keywords>
            <location chapter="PackageHead - jakarta.security.auth.message.config" section="AuthConfigFactory" />
            <comment>
                This reference is in the JASPIC spec but is in the API section and includes some of the javadoc
                refs. It seemed better suited for this spec than the javadoc spec - even though it may technically be
                javadoc.
            </comment>
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:329</id>
            <description>
                getFactory():
                If a non-null system-wide factory instance is defined at the time of the call, for example, with
                setFactory, it will be returned.
            </description>
            <keywords>
                <keyword>AuthConfigFactory</keyword>
            </keywords>
            <location chapter="PackageHead - jakarta.security.auth.message.config" section="AuthConfigFactory" />
            <comment>
                This reference is in the JASPIC spec but is in the API section and includes some of the javadoc
                refs. It seemed better suited for this spec than the javadoc spec - even though it may technically be
                javadoc.
            </comment>
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:330</id>
            <description>
                getFactory():
                The fully qualified class name of the default factory implementation class is obtained from the value of the
                authconfigprovider.factory security property.
            </description>
            <keywords>
                <keyword>AuthConfigFactory</keyword>
            </keywords>
            <location chapter="PackageHead - jakarta.security.auth.message.config" section="AuthConfigFactory" />
            <comment>
                This reference is in the JASPIC spec but is in the API section and includes some of the javadoc
                refs. It seemed better suited for this spec than the javadoc spec - even though it may technically be
                javadoc.
            </comment>
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:331</id>
            <description>
                registerConfigProvider(className, properties, layer, appContext, description):
                At most one registration may exist within the factory for a given combination of message layer and appContext. Any
                pre-existing registration with identical values for layer and appContext is replaced by a subsequent
                registration.
            </description>
            <keywords>
                <keyword>AuthConfigFactory</keyword>
            </keywords>
            <location chapter="PackageHead - jakarta.security.auth.message.config" section="AuthConfigFactory" />
            <comment>
                This reference is in the JASPIC spec but is in the API section and includes some of the javadoc
                refs. It seemed better suited for this spec than the javadoc spec - even though it may technically be
                javadoc.
            </comment>
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:332</id>
            <description>
                registerConfigProvider(className, properties, layer, appContext, description):
                [At most one registration may exist within the factory for a given combination of message layer and appContext. Any
                pre-existing registration with identical values for layer and appContext is replaced by a subsequent
                registration.]
                When replacement occurs, the registration identifier, layer, and appContext identifier remain unchanged, and the
                AuthConfigProvider (with initialization properties) and description are replaced.
            </description>
            <keywords>
                <keyword>AuthConfigFactory</keyword>
            </keywords>
            <location chapter="PackageHead - jakarta.security.auth.message.config" section="AuthConfigFactory" />
            <comment>
                This reference is in the JASPIC spec but is in the API section and includes some of the javadoc
                refs. It seemed better suited for this spec than the javadoc spec - even though it may technically be
                javadoc.
            </comment>
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:333</id>
            <description>
                registerConfigProvider(className, properties, layer, appContext, description):
                Within the lifetime of its Java process, a factory must assign unique registration identifiers to registrations, and must
                never assign a previously used registration identifier to a registration whose message layer and or
                appContext identifier differ from the previous use.
            </description>
            <keywords>
                <keyword>AuthConfigFactory</keyword>
            </keywords>
            <location chapter="PackageHead - jakarta.security.auth.message.config" section="AuthConfigFactory" />
            <comment>
                This reference is in the JASPIC spec but is in the API section and includes some of the javadoc
                refs. It seemed better suited for this spec than the javadoc spec - even though it may technically be
                javadoc.
            </comment>
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:334</id>
            <description>
                registerConfigProvider(provider, layer, appContext, description):
                Registers within the (in-memory) factory, a provider of ServerAuthConfig and/or
                ClientAuthConfig objects for a message layer and application context identifier.
            </description>
            <keywords>
                <keyword>AuthConfigFactory</keyword>
            </keywords>
            <location chapter="PackageHead - jakarta.security.auth.message.config" section="AuthConfigFactory" />
            <comment>
                This reference is in the JASPIC spec but is in the API section and includes some of the javadoc
                refs. It seemed better suited for this spec than the javadoc spec - even though it may technically be
                javadoc.
            </comment>
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:335</id>
            <description>
                setFactory()
                Set the system-wide AuthConfigFactory implementation.
                If an implementation was set previously, it will be replaced.
                Listeners are not notified of a change to the registered factory.
            </description>
            <keywords>
                <keyword>AuthConfigFactory</keyword>
            </keywords>
            <location chapter="PackageHead - jakarta.security.auth.message.config" section="AuthConfigFactory" />
            <comment>
                This reference is in the JASPIC spec but is in the API section and includes some of the javadoc
                refs. It seemed better suited for this spec than the javadoc spec - even though it may technically be
                javadoc.
            </comment>
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:336</id>
            <description>
                isPersistent()
                Returns: A boolean indicating whether the registration is the result of a className based registration, or an
                instance-based (for example, self-) registration. Only registrations performed using the five argument
                registerConfigProvider method are persistent.
            </description>
            <keywords>
                <keyword>AuthConfigFactory.RegistrationContext</keyword>
            </keywords>
            <location chapter="PackageHead - jakarta.security.auth.message.config"
                section="AuthConfigFactory.RegistrationContext" />
            <comment>
                This reference is in the JASPIC spec but is in the API section and includes some of the javadoc
                refs. It seemed better suited for this spec than the javadoc spec - even though it may technically be
                javadoc.
            </comment>
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:337</id>
            <description>
                When a listener argument is included in the call to acquire a provider, the factory will invoke the notify method of the
                listener when the correspondence between the provider and the layer and application context for which is
                had been acquired is no longer in effect. When the notify method is invoked by the factory, the runtime
                should reacquire an AuthConfigProvider for the layer and application context.
            </description>
            <keywords>
                <keyword>AuthConfigFactory.RegistrationContext</keyword>
            </keywords>
            <location chapter="2" section="1.1.1" />
            <comment>
                This was originally in this doc as part of assertion 9. but after relooking at that assertion, it
                was determined that this is a completely different assertion and so should be pulled out.
            </comment>
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:338</id>
            <description>
                notify()
                The AuthConfigFactory will invoke the notify method of the RegistrationListener if the corresponding provider
                registration is unregistered or replaced at the factory.
            </description>
            <keywords>
                <keyword>AuthConfigFactory.RegistrationContext</keyword>
            </keywords>
            <location chapter="PackageHead - jakarta.security.auth.message.config"
                section="RegistrationListener" />
            <comment>
                This reference is in the JASPIC spec but is in the API section and includes some of the javadoc
                refs. It seemed better suited for this spec than the javadoc spec - even though it may technically be
                javadoc.
            </comment>
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:339</id>
            <description>
                detachListener()
                The AuthConfigFactory will invoke the notify method of the RegistrationListener if the corresponding provider
                registration is unregistered or replaced at the factory.

                Returns: An array of String values where each value identifies a provider registration from which the listener was removed.
                This method never returns null; it returns an empty array if the listener was not removed from any
                registrations.
            </description>
            <keywords>
                <keyword>AuthConfigFactory</keyword>
            </keywords>
            <location chapter="PackageHead - jakarta.security.auth.message.config" section="AuthConfigFactory" />
            <comment>
                This reference is in the JASPIC spec but is in the API section and includes some of the javadoc
                refs. It seemed better suited for this spec than the javadoc spec - even though it may technically be
                javadoc.
            </comment>
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:340</id>
            <description>
                registerConfigProvider(className, properties, layer, appContext, description)
                When replacement occurs, the registration identifier, layer, and
                appContext identifier remain unchanged, and the AuthConfigProvider (with initialization properties) and
                description are replaced.
            </description>
            <keywords>
                <keyword>AuthConfigFactory</keyword>
            </keywords>
            <location chapter="PackageHead - jakarta.security.auth.message.config" section="AuthConfigFactory" />
            <comment>
                This reference is in the JASPIC spec but is in the API section and includes some of the javadoc
                refs. It seemed better suited for this spec than the javadoc spec - even though it may technically be
                javadoc.
                Note that this refers to the persistent registration and NOT the in-memory registration.
            </comment>
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:341</id>
            <description>
                registerConfigProvider(className, properties, layer, appContext, description)
                Programmatic registrations performed by using this method must update
                (according to the replacement rules described above) the persistent declarative representation of
                provider registrations employed by the factory constructor.
            </description>
            <keywords>
                <keyword>AuthConfigFactory</keyword>
            </keywords>
            <location chapter="PackageHead - jakarta.security.auth.message.config" section="AuthConfigFactory" />
            <comment>
                This reference is in the JASPIC spec but is in the API section and includes some of the javadoc
                refs. It seemed better suited for this spec than the javadoc spec - even though it may technically be
                javadoc.
                Note that this refers to the persistent registration and NOT the in-memory registration.
            </comment>
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:342</id>
            <description>
                registerConfigProvider(acp, layer, appContext, description)
                At most one registration may exist within the factory for a given combination of
                message layer and appContext. Any pre-existing registration with identical values for layer and
                appContext is replaced by a subsequent registration.
            </description>
            <keywords>
                <keyword>AuthConfigFactory</keyword>
            </keywords>
            <location chapter="PackageHead - jakarta.security.auth.message.config" section="AuthConfigFactory" />
            <comment>
                This reference is in the JASPIC spec but is in the API section and includes some of the javadoc
                refs. It seemed better suited for this spec than the javadoc spec - even though it may technically be
                javadoc.
                Note that this refers to the in-memory registration and NOT the persistent registration.
            </comment>
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:343</id>
            <description>
                registerConfigProvider(acp, layer, appContext, description)
                When replacement occurs, the registration identifier, layer, and appContext
                identifier remain unchanged, and the AuthConfigProvider (with initialization properties) and description
                are replaced.
            </description>
            <keywords>
                <keyword>AuthConfigFactory</keyword>
            </keywords>
            <location chapter="PackageHead - jakarta.security.auth.message.config" section="AuthConfigFactory" />
            <comment>
                This reference is in the JASPIC spec but is in the API section and includes some of the javadoc
                refs. It seemed better suited for this spec than the javadoc spec - even though it may technically be
                javadoc.
                Note that this refers to the in-memory registration and NOT the persistent registration.
            </comment>
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:344</id>
            <description>
                removeRegistration()
                Remove the identified provider registration from the factory (and from the persistent declarative representation of
                provider registrations, if appropriate) and invoke any listeners associated with the removed
                registration.
                Verify this returns True when there is a registration with the specified identifier and it
                was removed.
            </description>
            <keywords>
                <keyword>AuthConfigFactory</keyword>
            </keywords>
            <location chapter="PackageHead - jakarta.security.auth.message.config" section="AuthConfigFactory" />
            <comment>
                This reference is in the JASPIC spec but is in the API section and includes some of the javadoc
                refs. It seemed better suited for this spec than the javadoc spec - even though it may technically be
                javadoc.
            </comment>
        </assertion>

        <assertion required="true" impl-spec="false" defined-by="technology" status="active" testable="true">
            <id>JASPIC:SPEC:345</id>
            <description>
                removeRegistration()
                Remove the identified provider registration from the factory (and from the persistent declarative representation of
                provider registrations, if appropriate) and invoke any listeners associated with the removed
                registration.
                Verify this returns false when the registrationID is invalid.
            </description>
            <keywords>
                <keyword>AuthConfigFactory</keyword>
            </keywords>
            <location chapter="PackageHead - jakarta.security.auth.message.config" section="AuthConfigFactory" />
            <comment>
                This reference is in the JASPIC spec but is in the API section and includes some of the javadoc
                refs. It seemed better suited for this spec than the javadoc spec - even though it may technically be
                javadoc.
            </comment>
        </assertion>

    </assertions>
</spec>
