Merge pull request #2 from arjantijms/master

* Changed term "user store" to "identity store"
* Update identity store spec text after EG call

Author: arjantijms

src/main/doc/authenticationMechanism.asciidoc

@@ -157,7 +157,7 @@ The Java EE Platform already specifies mechanisms for authenticating users of we
 
 In addition, the Java Authentication SPI for Containers (JASPIC) specifies a general-purpose mechanism for securing messages sent between Java EE clients and servers. JASPIC defines an SPI called _ServerAuthModule_, which enables development of authentication modules to handle any credential type, or engage in interaction of arbitrary complexity with clients and third parties. JASPIC also includes the Servlet Container Profile, which specifies how JASPIC mechanisms, including _ServerAuthModules_, are integrated with the servlet container.
 
-While both existing mechanisms are important and useful, each has limitations from the point of view of an application developer. The servlet container's _login-config_ mechanism is limited to the _auth-method_ types defined by the Java Servlet Specification -- it doesn't support other credential types, or complex interactions with callers. It also relies on unspecified container mechanisms to associate user stores with applications. There is no way for an application to ensure that callers are authenticated against the desired user store, or, indeed, against _any_ user store.
+While both existing mechanisms are important and useful, each has limitations from the point of view of an application developer. The servlet container's _login-config_ mechanism is limited to the _auth-method_ types defined by the Java Servlet Specification -- it doesn't support other credential types, or complex interactions with callers. It also relies on unspecified container mechanisms to associate identity stores with applications. There is no way for an application to ensure that callers are authenticated against the desired identity store, or, indeed, against _any_ identity store.
 
 JASPIC, by way of contrast, is extremely flexible and powerful, but is limited by its complexity. Writing an _AuthModule_ and arranging for the web container to use it for authentication, is a non-trivial exercise. Additionally, there is no declarative configuration syntax for JASPIC, and there is no well-defined mechanism for a container to override an application's programmatically-registered _AuthModule_. A container can choose to register its own _AuthModule_, or to remove one registred by an application, but JASPIC will always use the most-recently-registered module -- the outcome is dependent on the order in which the application and the container attempt to register their respective modules.
 
@@ -213,7 +213,7 @@ The actual _HttpAuthenticationMechanism_ instance used at runtime is resolved vi
 
 It MUST be possible for the definition of an _HttpAuthenticationMechanism_ to exist within the application archive. Alternatively such definition MAY also exists outside the application archive, for example in a jar added to the classpath of an application server.
 
-The server MAY make available an _HttpAuthenticationMechanism_ other than one supplied by the application, and SHOULD provide configuration to allow control over whether a system _HttpAuthenticationMechanism_, or the application's, is chosen at runtime, when both are present. This enables an application to provide its own _HttpAuthenticationMechanism_, for use when the deployment environment is not configured with user stores for authentication, while allowing the same application to be deployed, unchanged, in environments where authentication against known user stores must be enforced.
+The server MAY make available an _HttpAuthenticationMechanism_ other than one supplied by the application, and SHOULD provide configuration to allow control over whether a system _HttpAuthenticationMechanism_, or the application's, is chosen at runtime, when both are present. This enables an application to provide its own _HttpAuthenticationMechanism_, for use when the deployment environment is not configured with identity stores for authentication, while allowing the same application to be deployed, unchanged, in environments where authentication against known identity stores must be enforced.
 
 === Relationship to other specifications