From 1dd3212f7331d82b15914848b0429206781068fa Mon Sep 17 00:00:00 2001 From: Dmitri Cherkas <dmitricerkas@yahoo.com> Date: Mon, 6 Feb 2023 19:02:34 +0100 Subject: [PATCH] Words separation and font style improvements. --- spec/src/main/asciidoc/overview.adoc | 2 +- spec/src/main/asciidoc/revision-history.adoc | 2 +- spec/src/main/asciidoc/soap-profile.adoc | 8 ++++---- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/spec/src/main/asciidoc/overview.adoc b/spec/src/main/asciidoc/overview.adoc index 3290c96..8b3def3 100644 --- a/spec/src/main/asciidoc/overview.adoc +++ b/spec/src/main/asciidoc/overview.adoc @@ -417,7 +417,7 @@ acquisition of the authentication context. If the Subject is not null, additiona Appropriate to its point of processing in the messaging model, the messaging runtime uses the `MessageInfo` described in Step 3 to invoke a method of the authentication context obtained in Step 4. -At point (1) in the messaging model, the`clientSubject` may contain the credentials used to secure the +At point (1) in the messaging model, the `clientSubject` may contain the credentials used to secure the request, or the modules of the context may collect the client credentials including by using the callback handler passed through to them by the context. `MessageInfo` would contain a request message about to be sent. On successful return from the context, the runtime would extract the secured request message from diff --git a/spec/src/main/asciidoc/revision-history.adoc b/spec/src/main/asciidoc/revision-history.adoc index b826383..4b4790b 100644 --- a/spec/src/main/asciidoc/revision-history.adoc +++ b/spec/src/main/asciidoc/revision-history.adoc @@ -218,7 +218,7 @@ the request ==== Changes to API -. In abstract `AuthConfigFactory` class, made public the static permissions that are used to protect the static `getFactory` and `setFactory` methods, and improved documentation so users of the SPI can know which permissions are used. Also added an additional public `providerRegistrationSecurityPermission` and required that it be used by factory implementations to protect methods like `registerConfigProvider`. Removed incorrect assertion from javadoc of `getFactory`, both forms of `registerConfigProvider`, and `refresh`, that checked `AuthException` could be thrown (by these methods). Changed the javadoc of these four methods to indicate that the conditions for which they were expected to throw an `AuthException` should instead be handled within their existing declarations of throwing an (unchecked) `SecurityException`. Regenerated (mif) javadocs (embedded in spec) from html javadocs, which corrected definition for `layer` and `appContext`parameters of `getConfigProvider(java.lang.String layer, java.lang.String appContext, RegistrationListener listener)`. +. In abstract `AuthConfigFactory` class, made public the static permissions that are used to protect the static `getFactory` and `setFactory` methods, and improved documentation so users of the SPI can know which permissions are used. Also added an additional public `providerRegistrationSecurityPermission` and required that it be used by factory implementations to protect methods like `registerConfigProvider`. Removed incorrect assertion from javadoc of `getFactory`, both forms of `registerConfigProvider`, and `refresh`, that checked `AuthException` could be thrown (by these methods). Changed the javadoc of these four methods to indicate that the conditions for which they were expected to throw an `AuthException` should instead be handled within their existing declarations of throwing an (unchecked) `SecurityException`. Regenerated (mif) javadocs (embedded in spec) from html javadocs, which corrected definition for `layer` and `appContext` parameters of `getConfigProvider(java.lang.String layer, java.lang.String appContext, RegistrationListener listener)`. . In `AuthConfig`, and `AuthConfigProvider` interfaces, removed incorrect assertion from javadoc of refresh method that checked `AuthException` could be thrown, and changed javadoc to indicate that the conditions for which `refresh` was expected to throw an `AuthException` should instead be handled within its existing declaration of throwing an (unchecked) `SecurityException`. === Changes in Jakarta Authentication 3.0 diff --git a/spec/src/main/asciidoc/soap-profile.adoc b/spec/src/main/asciidoc/soap-profile.adoc index 148577f..f1aae62 100644 --- a/spec/src/main/asciidoc/soap-profile.adoc +++ b/spec/src/main/asciidoc/soap-profile.adoc @@ -162,7 +162,7 @@ role. A runtime may operate in both the client and server roles. ==== Client-Side Application Context Identifier The application context identifier used by a -client-runtime to acquire the `AuthConfigProvider`and ClientAuthConfig +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, @@ -226,8 +226,8 @@ In either event, the CallbackHandler must also support the requirements in <<a51 ==== AuthConfigProvider Requirements -If a non-null `AuthConfigProvider`is returned -(by the call to getConfigProvider), the messaging runtime must call +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 @@ -482,7 +482,7 @@ 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 +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.