Merge pull request #8 from jesse-gallagher/feature/oidc-typos

Fix some typos of “OIDC” and rename a config property to lessen confusion

docs/howto/IdP/configuringCertificates.md

@@ -67,7 +67,7 @@ To get valid certificates, use any of the following approaches:
 ```json
 {
   "jwt": {
-    "oicd": {
+    "my-idp": {
       "active": true,
       "algorithm": "RS256",
       "keyFile": "10-jwt.pubkey"

docs/howto/IdP/configuringIdentityProvider.md

@@ -99,7 +99,7 @@ The JSON file looks like this:
 {
   "disableJwtExpiryCheck": false,
   "jwt": {
-    "oicd": {
+    "my-idp": {
       "active": true,
       "algorithm": "RS256",
       "keyFile": "10-jwt.pubkey"
@@ -112,12 +112,12 @@ wherein:
 
 - `disableJwtExpiryCheck`: By setting the value to `true`, the enforcement of JWT expiration can be disabled. **DO NOT** do this on a production system (default is `false`).
 - `jwt`: Entry is related to JWT authorization.
-- `oicd`: The name you give your IdP. It could be `Rumpelstielzchen` but needs to be unique on your server.
+- `my-idp`: The name you give your IdP. It could be `Rumpelstielzchen` but needs to be unique on your server.
 - `active`: True/false.
 - `algorithm`: Currently supported: `RS256`.
 - `keyFile`: Path to public key file (PEM format), either relative to `keepconfig.d`or an absolute path.
 
-Domino REST API supports more than one IdP, distinguished by the name `oicd` in the example. Access checking takes longer the more identity providers you configure since Domino REST API checks every provider's key until it finds a match.
+Domino REST API supports more than one IdP, distinguished by the name `my-idp` in the example. Access checking takes longer the more identity providers you configure since Domino REST API checks every provider's key until it finds a match.
 
 ## Obtaining the public key directly from the IdP
 

docs/references/accesscontrol.md

@@ -19,7 +19,7 @@ The [Domino Developer](../references/usingdominorestapi/roles.md#domino-develope
 
 ## Application access
 
-The Domino REST API provides its own IdP (Identity Provider) implementation following OICD standards. Applications are configured using a `client_id` and a `client_secret` to request access on behalf of an user.
+The Domino REST API provides its own IdP (Identity Provider) implementation following OIDC standards. Applications are configured using a `client_id` and a `client_secret` to request access on behalf of an user.
 
 When an enterprise IdP shall be used, the resulting `AccessToken` needs to comply with the [Domino REST API JWT specification](../references/security/jwt.md).
 

docs/references/usingdominorestapi/keepapplications.md

@@ -72,7 +72,7 @@ When creating a new Application, enter the application name, application descrip
 
 When the application presents App ID and App Secret in the header of a request, it can access the databases, even when they're not defined as "Open Access". This information is required for an application to use an OAuth flow to gain access to data. Thus, an application server can have more access than a browser application.
 
-Domino REST API offers an OAuth/OICD controlled access.
+Domino REST API offers an OAuth/OIDC controlled access.
 
 ### Desktop applications
 

docs/references/usingdominorestapi/scopes.md

@@ -19,6 +19,6 @@ Scopes are a space-separated lists of values. By default, a user who authenticat
 
 A scope doesn't **open** access to a resource; that's the job of the database ACL. A scope **limits** access.
 
-Besides the default scopes of `MAIL`, `$DATA`, `$DECRYPT`, and `$SETUP`, any of the database aliases can be used as a scope term. This allows an IdP to ask a user for tailored permissions in an OICD flow to limit exact access required instead of having the full user spectrum.
+Besides the default scopes of `MAIL`, `$DATA`, `$DECRYPT`, and `$SETUP`, any of the database aliases can be used as a scope term. This allows an IdP to ask a user for tailored permissions in an OIDC flow to limit exact access required instead of having the full user spectrum.
 
 For more information, see [Scope](../../topicguides/understanding.md#databases-schemas-and-scopes).

docs/topicguides/architecture.md

@@ -113,11 +113,11 @@ Access to the Domino REST APIs requires a valid JavaScript Web Token (JWT), sign
 
 ### Justification
 
-Domino REST API is API only, so any dance that requires user interaction must happen before Domino REST APIs are accessed. The ability to use Domino credentials, including local users (note: _local users work in Notes client only_) to obtain a JWT token lowers the barrier to entry. JWT is an established [industry standard (RFC7519)](https://tools.ietf.org/html/rfc7519) and also is the end result of an [OpenID Connect (OICD)](https://openid.net/connect/) dance. So its use and risks are well understood and documented.
+Domino REST API is API only, so any dance that requires user interaction must happen before Domino REST APIs are accessed. The ability to use Domino credentials, including local users (note: _local users work in Notes client only_) to obtain a JWT token lowers the barrier to entry. JWT is an established [industry standard (RFC7519)](https://tools.ietf.org/html/rfc7519) and also is the end result of an [OpenID Connect (OIDC)](https://openid.net/connect/) dance. So its use and risks are well understood and documented.
 
 ### Alternatives
 
-We also looked at OICD, SAML, and Kerberos. They all require user interaction to authorize access. Since Domino REST API is API only and has no user interface, the application must authorize access.
+We also looked at OIDC, SAML, and Kerberos. They all require user interaction to authorize access. Since Domino REST API is API only and has no user interface, the application must authorize access.
 
 ### Implication