| ID | Chapter | Section | Description | Required | Dependency | Implementation Specific | Defined by | Status | Testable | 
            | JASPIC:SPEC:1 | 1 | 1.1 | A message processing runtime may acquire the
                    authentication context objects that it uses to invoke authentication modules by interacting with an
                    authentication context configuration object | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:2 | 1 | 1.1 | An authentication context configuration
                    object is an implementation of either the ClientAuthConfig or ServerAuthConfig interface as defined
                    by this specification. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:3 | 1 | 1.3 | A message processing runtime may acquire
                    authentication context configuration objects by interacting with a provider of authentication
                    context configuration objects. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:4 | 1 | 1.4 | A message processing runtime may interact
                    with the factory to obtain or establish the provider registered for an application context and
                    messaging layer. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:5 | 1 | 1.7 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:6 | 1 | 1.7 | 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). | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:7 | 2 | 1.1 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:8 | 2 | 1.1 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:9 | 2 | 1.1 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:10 | 2 | 1.1.2 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:11 | 2 | 1.2 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:12 | 2 | 1.2 | A runtime operating at points 1 and 4 in the
                    messaging model must invoke getClientAuthConfig to acquire its configuration object. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:13 | 2 | 1.2 | A runtime operating at points 2 and 3 in the
                    messaging model must invoke getServerAuthConfig to acquire its configuration object. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:14 | 2 | 1.2 | 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 | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:15 | 2 | 1.2 | 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). | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:16 | 2 | 1.2.2 | The provider implementation must satisfy the
                    requirements defined by the AuthConfigProvider interface. In particular, it must return non-null
                    authentication configuration objects. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:17 | 2 | 1.2.2 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:18 | 2 | 1.2.2 | 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). | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:19 | 2 | 1.3 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:20 | 2 | 1.3 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:21 | 2 | 1.3 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:22 | 2 | 1.3.2 | The configuration implementation must satisfy
                    the requirements defined by the AuthConfig interface with respect to the getOperation method. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:23 | 2 | 1.4 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:24 | 2 | 1.4 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:25 | 2 | 1.4 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:26 | 2 | 1.4 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:27 | 2 | 1.4 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:28 | 2 | 1.4 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:29 | 2 | 1.4 | 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 | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:30 | 2 | 1.4 | 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). | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:31 | 2 | 1.5 | Every context implementation must satisfy the
                    requirements as defined by the corresponding ClientAuthContext or ServerAuthContext interface. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:32 | 2 | 1.5 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:33 | 2 | 1.5 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:34 | 2 | 1.5 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:35 | 2 | 1.5 | At point (1) in the message processing model
                    : the message processing runtime must call the secureRequest method of the ClientAuthContext. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:36 | 2 | 1.5 | (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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:37 | 2 | 1.5 | (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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:38 | 2 | 1.5 | (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). | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:39 | 2 | 1.5 | (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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:40 | 2 | 1.5 | (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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:41 | 2 | 1.5 | (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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:42 | 2 | 1.5 | At point (4) in the message processing model:
                    the message processing runtime must call the validateResponse method of the ClientAuthContext. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:43 | 2 | 1.5 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:44 | 2 | 1.5 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:45 | 2 | 1.5 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:46 | 2 | 1.5 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:47 | 2 | 1.5 | 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). | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:48 | 2 | 1.5 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:49 | 2 | 1.5 | If the call to validateResponse throws an
                    AuthException - runtime should use the exception to convey to the client runtime that the request
                    failed. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:50 | 2 | 1.5 | At point (2) in the message processing model:
                    the message processing runtime must call the validateRequest method of the ServerAuthContext. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:51 | 2 | 1.5 | (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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:52 | 2 | 1.5 | (At point (2) in the message processing
                    model) The clientSubject argument must be non-null and it must not be read-only. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:53 | 2 | 1.5 | (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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:313 | 2 | 1.5.2 | (At point (2) in the message processing
                    model) If a non-null serviceSubject is used in this call, it must not be read-only. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:314 | 2 | 1.5.2 | (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). | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:54 | 2 | 1.5 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:55 | 2 | 1.5 | If the call to validateRequest returns:
                    AuthStatus.SEND_SUCCESS - The runtime must NOT proceed to authorize the request or perform the
                    application request processing. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:56 | 2 | 1.5 | If the call to validateRequest returns:
                    AuthStatus.SEND_CONTINUE - The runtime must NOT proceed to authorize the request or perform the
                    application request processing. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:57 | 2 | 1.5 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:315 | 2 | 1.5 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:58 | 2 | 1.5 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:316 | 2 | 1.5 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:59 | 2 | 1.5 | At point (3) in the message processing model:
                    the message processing runtime must call the secureResponse method of the ServerAuthContext. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:60 | 2 | 1.5 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:61 | 2 | 1.5 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:62 | 2 | 1.5 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:63 | 2 | 1.5 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:64 | 2 | 1.5 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:65 | 2 | 1.5 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:66 | 2 | 1.5 | The authentication module implementations
                    within the context must satisfy the requirements as defined by the corresponding ClientAuthModule or
                    ServerAuthModule interface. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:67 | 3 | 1 | The message layer value used to select the
                    AuthConfigProvider and ServerAuthConfig objects for this (servlet) profile must be HttpServlet | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:68 | 3 | 2 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:69 | 3 | 3 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:70 | 3 | 4 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:71 | 3 | 5 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:72 | 3 | 5 | The CallbackHandler passed to
                    ServerAuthModule.initialize must support the following callbacks: CallerPrincipalCallback,
                    GroupPrincipalCallback, PasswordValidationCallback. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:73 | 3 | 5 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:318 | 3 | 6 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:74 | 3 | 6 | 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 | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:75 | 3 | 6 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:76 | 3 | 6 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:77 | 3 | 7 | 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). | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:78 | 3 | 7 | 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). | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:79 | 3 | 7 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:80 | 3 | 7.1 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:81 | 3 | 7.2 | A null value may be passed as the Subject
                    argument in the getAuthContext call. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:300 | 3 | 7.2 | If the runtime is a Jakarta Authorization 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:83 | 3 | 7.3 | When the runtime is not a Jakarta Authorization 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:84 | 3 | 7.4 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:85 | 3 | 7.4 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:86 | 3 | 7.4 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:87 | 3 | 7.4 | 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 | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:88 | 3 | 8 | At point (2) in the message processing model,
                    the runtime must call validateRequest on the ServerAuthContext. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:89 | 3 | 8 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:90 | 3 | 8 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:301 | 3 | 8 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:91 | 3 | 8 | In a Jakarta Authorization compatible runtime, the identity
                    must be comprised of exactly the Principal objects of the clientSubject. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:92 | 3 | 8 | In a non-Jakarta Authorization 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.) | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:93 | 3 | 8 | If the request is not authorized, the runtime
                    must return the HTTP status code required by the Servlet spec. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:317 | 3 | 8 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:302 | 3 | 8 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:303 | 3 | 8 | 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 | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:94 | 3 | 8 | The call to secureResponse must not be made
                    if the resource throws an exception to the calling runtime. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:304 | 3 | 8 | If invocation of the resource completes
                    without throwing an exception, the runtime must proceed to point (3) in the message processing
                    model. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:305 | 3 | 8 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:95 | 3 | 8.1 | 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). | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:306 | 3 | 8.1.1 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:307 | 3 | 8.1.1 | 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 Jakarta Authorization compatible runtime, if the corresponding
                    WebResourcePermission is NOT granted2 to an unauthenticated caller | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:319 | 3 | 8.1.1 | In a Jakarta Authorization 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 | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:96 | 3 | 8.2 | A new clientSubject must be instantiated and
                    passed in the call to validateRequest. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:97 | 3 | 8.3 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:98 | 3 | 8.3.1 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:99 | 3 | 8.3.1 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:100 | 3 | 8.3.1 | 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). | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:101 | 3 | 8.3.1 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:102 | 3 | 8.3.1 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:103 | 3 | 8.3.1 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:320 | 3 | 8.3.1 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:104 | 3 | 8.3.2 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:105 | 3 | 8.3.2 | 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). | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:106 | 3 | 8.3.2 | 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). | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:107 | 3 | 8.3.2 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:108 | 3 | 8.3.3 | 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 Section 3.8.3.2, validateRequest After Service Invocation. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:308 | 3 | 8.3.4 | A ServerAuthModule must only call
                    MessageInfo.setResponseMessage() to wrap or unwrap the existing response within MessageInfo. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:309 | 3 | 8.3.4 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:310 | 3 | 8.3.4 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:311 | 3 | 8.3.4 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:321 | 3 | 8.4 | 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) | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:322 | 3 | 8.4 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:323 | 3 | 8.4 | 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) | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:324 | 3 | 8.4 | (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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:325 | 3 | 8.4 | (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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:109 | 4 | 0 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:110 | 4 | 1 | The message layer value used to select the
                    AuthConfigProvider and ServerAuthConfig objects for this profile must be SOAP | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:111 | 4 | 2 | 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 | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:112 | 4 | 3 | 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 instanceof
                    jakarta.xml.soap.SOAPMessage. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:113 | 4 | 4 | The getSupportedMessageTypes method of all
                    authentication modules integrated for use with this profile, must include
                    jakarta.xml.soap.SOAPMessage.class in its return value. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:114 | 4 | 5 | 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 | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:115 | 4 | 5 | The CallbackHandler must be initialized with
                    any application context required to process the supported callbacks on behalf of the corresponding
                    application. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:116 | 4 | 6 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:117 | 4 | 6 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:118 | 4 | 6 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:119 | 4 | 7 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:120 | 4 | 7.1 | 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). | true | 
 | false | technology | deprecated | false | 
        
            | JASPIC:SPEC:121 | 4 | 7.1 | 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). | true | 
 | false | technology | deprecated | false | 
        
            | JASPIC:SPEC:122 | 4 | 7.2 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:123 | 4 | 8.1 | 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 | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:124 | 4 | 8.2 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:125 | 4 | 8.3 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:126 | 4 | 8.3 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:127 | 4 | 8.4.1 | A non-null Subject corresponding to the
                    client must be passed as the clientSubject in the getAuthContext call. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:128 | 4 | 8.4.2 | A null value may be passed for the properties
                    argument in all calls made to getAuthContext | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:129 | 4 | 8.4.3 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:130 | 4 | 8.5 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:131 | 4 | 8.4.1 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:132 | 4 | 8.5.1 | 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 initiialized by the runtime such that its
                    getResponseMessage method will return the SOAP response message being processed by the runtime. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:133 | 4 | 8.5.1 | 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.. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:134 | 4 | 8.5.2 | The clientSubject used in the call to
                    getAuthContext must be used in the call to secureRequest and for any corresponding calls to
                    validateResponse. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:135 | 4 | 8.5.3 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:136 | 4 | 8.5.3 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:137 | 4 | 8.5.3 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:138 | 4 | 8.5.3 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:139 | 4 | 8.5.3 | 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. | false | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:140 | 4 | 8.5.4 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:141 | 4 | 8.5.4 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:142 | 4 | 8.5.4 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:143 | 4 | 8.5.4 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:144 | 4 | 8.5.4 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:145 | 4 | 8.5.4 | 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. | false | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:146 | 4 | 8.5.4 | 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 | false | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:147 | 4 | 8.5.4 | When validateResponse is called before the
                    service invocation, the module must return AuthStatus.SEND_CONTINUE if the request dialog is to
                    continue. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:148 | 4 | 8.5.4 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:149 | 4 | 9.2 | The CallbackHandler passed to
                    ServerAuthModule.initialize must support the following callbacks: CallerPrincipalCallback,
                    GroupPrincipalCallback , PasswordValidationCallback . | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:150 | 4 | 9.3 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:151 | 4 | 9.3 | 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. | true | 
 | false | technology | deprecated | false | 
        
            | JASPIC:SPEC:152 | 4 | 9.3.1 | A null value may be passed for the properties
                    argument in all calls made to getAuthContext | true | 
 | false | technology | deprecated | false | 
        
            | JASPIC:SPEC:153 | 4 | 9.4.2 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:154 | 4 | 9.4.2 | 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 | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:155 | 4 | 9.5 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:156 | 4 | 9.4 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:157 | 4 | 9.5 | In a Jakarta Authorization 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). | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:158 | 4 | 9.4 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:159 | 4 | 9.4 | The call to secureResponse must not be made
                    if the resource throws an exception to the calling runtime. | true | 
 | false | technology | deprecated | false | 
        
            | JASPIC:SPEC:160 | 4 | 9.4 | 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. | true | 
 | false | technology | deprecated | false | 
        
            | JASPIC:SPEC:161 | 4 | 9.5.2 | A new clientSubject must be instantiated and
                    passed in any calls made to validateRequest. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:162 | 4 | 9.5.3 | 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 | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:163 | 4 | 9.5.3 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:164 | 4 | 9.5.3 | 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 | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:165 | 4 | 9.5.3 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:166 | 4 | 9.5.3 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:167 | 4 | 9.5.3 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:168 | 4 | 9.5.3 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:169 | 4 | 9.4.3 | 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. | true | 
 | false | technology | deprecated | false | 
        
            | JASPIC:SPEC:170 | 4 | 9.5.3 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:171 | 4 | 9.5.3 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:172 | 4 | 9.5.3 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:173 | 4 | 9.5.3 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:174 | 4 | 9.5.3 | 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). | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:175 | 4 | 9.5.4 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:176 | 5 | 1 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:177 | 5 | 1 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:178 | 5 | 1 | If the ServerAuthModule passes a Subject to
                    the LoginContext constructor, it must pass its client Subject. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:179 | 5 | 1 | The ServerAuthModule must pass a
                    CallbackHandler to the constructor and the passed CallbackHandler must conform to the requirements
                    of Section 5.3, Standard Callbacks. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:180 | 5 | 1 | A new LoginContext instance should be created
                    for each new request, and a LoginContext instance should not be shared across different requests. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:181 | 5 | 1 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:182 | 5 | 2 | A LoginModule must only perform
                    protocolindependent security processing (for example, verifying a username/password that was
                    transmitted in the request). | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:183 | 5 | 2 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:184 | 5 | 3 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:326 | 5 | 3 | If the ServerAuthModule passes its client
                    Subject to the LoginContext constructor, the CallbackHandler provided to the LoginContext
                    constructor must also support the GroupPrincipalCallback. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:185 | 5 | 4 | If authentication succeeds, a LoginModule may
                    update its Subject instance with authenticated Principal and credential objects. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:186 | 5 | 4 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:327 | 5 | 4 | 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.) | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:187 | 5 | 5 | When ServerAuthModule.cleanSubject is called
                    on the client Subject, the cleanSubject method must invoke the LoginContext.logout method. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:188 | 5 | 6 | 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. | true | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:189 | 6 | 1 | The message layer value used to select the
                    AuthConfigProvider and ServerAuthConfig objects for this profile must be JMS | false | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:190 | 6 | 2 | 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. | false | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:191 | 6 | 3 | 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 instanceof javax.jmx.Message. | false | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:192 | 6 | 4 | The getSupportedMessageTypes method of all
                    authentication modules integrated for use with this profile, must include jakarta.jms.Message in its
                    return value. | false | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:193 | 6 | 6 | 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. | false | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:194 | 6 | 6 | For each JMS Destination for which it is
                    servicing requests, the runtime must call getConfigProvider to acquire the corresponding provider
                    object. | false | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:195 | 6 | 6 | 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. | false | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:196 | 6 | 6 | 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. | false | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:197 | 6 | 7 | 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). | false | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:198 | 6 | 7.1 | 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. | false | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:199 | 6 | 8 | The following must be satisfied by a runtime
                    operating in the client role: A runtime may operate in both the client and server roles. | false | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:200 | 6 | 8.4.1 | 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. | false | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:201 | 6 | 8.4.1 | 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. | false | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:202 | 6 | 8.4.3 | 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. | false | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:203 | 6 | 8.4.3 | 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. | false | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:204 | 6 | 8.4.3 | 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. | false | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:205 | 6 | 9 | 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 | false | 
 | false | technology | active | false | 
        
            | JASPIC:SPEC:206 | 6 | 9.4.1 | 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. | false | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:207 | 6 | 9.4.1 | 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. | false | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:208 | 4 | 8.1 | 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 | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:209 | 4 | 9.1 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:328 | PackageHead -
                    jakarta.security.auth.message.config | AuthConfigFactory | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:329 | PackageHead -
                    jakarta.security.auth.message.config | AuthConfigFactory | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:330 | PackageHead -
                    jakarta.security.auth.message.config | AuthConfigFactory | getFactory(): The fully qualified class name
                    of the default factory implementation class is obtained from the value of the
                    authconfigprovider.factory security property. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:331 | PackageHead -
                    jakarta.security.auth.message.config | AuthConfigFactory | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:332 | PackageHead -
                    jakarta.security.auth.message.config | AuthConfigFactory | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:333 | PackageHead -
                    jakarta.security.auth.message.config | AuthConfigFactory | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:334 | PackageHead -
                    jakarta.security.auth.message.config | AuthConfigFactory | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:335 | PackageHead -
                    jakarta.security.auth.message.config | AuthConfigFactory | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:336 | PackageHead -
                    jakarta.security.auth.message.config | AuthConfigFactory.RegistrationContext | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:337 | 2 | 1.1.1 | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:338 | PackageHead -
                    jakarta.security.auth.message.config | RegistrationListener | notify() The AuthConfigFactory will invoke
                    the notify method of the RegistrationListener if the corresponding provider registration is
                    unregistered or replaced at the factory. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:339 | PackageHead -
                    jakarta.security.auth.message.config | AuthConfigFactory | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:340 | PackageHead -
                    jakarta.security.auth.message.config | AuthConfigFactory | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:341 | PackageHead -
                    jakarta.security.auth.message.config | AuthConfigFactory | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:342 | PackageHead -
                    jakarta.security.auth.message.config | AuthConfigFactory | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:343 | PackageHead -
                    jakarta.security.auth.message.config | AuthConfigFactory | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:344 | PackageHead -
                    jakarta.security.auth.message.config | AuthConfigFactory | 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. | true | 
 | false | technology | active | true | 
        
            | JASPIC:SPEC:345 | PackageHead -
                    jakarta.security.auth.message.config | AuthConfigFactory | 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. | true | 
 | false | technology | active | true |