Updated public naming references where applicable

Signed-off-by: Emiliano Suñé <[email protected]>
openwallet-foundation · Dec 4, 2024 · 7bf5512 · 7bf5512
1 parent b71ccbb
commit 7bf5512
Show file tree

Hide file tree

Showing 14 changed files with 38 additions and 35 deletions.
diff --git a/README.md b/README.md
@@ -1,8 +1,7 @@
-[![img](https://img.shields.io/badge/Lifecycle-Maturing-007EC6)](https://github.com/bcgov/repomountie/blob/master/doc/lifecycle-badges.md)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](LICENSE)
 
-[![unit-tests](https://github.com/bcgov/vc-authn-oidc/actions/workflows/controller_unittests.yml/badge.svg?branch=main&event=push)](https://github.com/bcgov/vc-authn-oidc/actions/workflows/controller_unittests.yml)
-[![Coverage Status](https://coveralls.io/repos/github/bcgov/vc-authn-oidc/badge.svg?branch=main)](https://coveralls.io/repos/github/bcgov/vc-authn-oidc/badge.svg?branch=main)
+[![unit-tests](https://github.com/openwallet-foundation/acapy-vc-authn-oidc/actions/workflows/controller_unittests.yml/badge.svg?branch=main&event=push)](https://github.com/openwallet-foundation/acapy-vc-authn-oidc/actions/workflows/controller_unittests.yml)
+[![Coverage Status](https://coveralls.io/repos/github/openwallet-foundation/acapy-vc-authn-oidc/badge.svg?branch=main)](https://coveralls.io/repos/github/openwallet-foundation/acapy-vc-authn-oidc/badge.svg?branch=main)
 
 # Verifiable Credential Authentication with OpenID Connect (VC-AuthN OIDC)
 

diff --git a/demo/vue/app/frontend/src/router/index.js b/demo/vue/app/frontend/src/router/index.js
@@ -88,7 +88,7 @@ export default function getRouter(basePath = '/') {
         document.title = to.meta.title
           ? to.meta.title
           : process.env.VUE_APP_TITLE;
-      } else document.title = 'Demo VC-Authn-OIDC App'; // default title
+      } else document.title = 'Demo ACAPy VC-Authn-OIDC App'; // default title
 
       if (to.query.r && isFirstTransition) {
         router.replace({

diff --git a/demo/vue/app/frontend/src/views/Home.vue b/demo/vue/app/frontend/src/views/Home.vue
@@ -1,6 +1,6 @@
 <template>
   <v-container>
-    <h1 class="my-6 text-center">Welcome to vc-authn-oidc demo application.</h1>
+    <h1 class="my-6 text-center">Welcome to acapy-vc-authn-oidc demo application.</h1>
     <h2>Pre-requisites</h2>
     <br />
     <h4>Mobile Wallet</h4>

diff --git a/docker/docker-compose.yaml b/docker/docker-compose.yaml
@@ -1,7 +1,7 @@
 version: "3"
 services:
   controller:
-    image: vc-authn-oidc-controller
+    image: acapy-vc-authn-oidc-controller
     entrypoint: /bin/bash
     command: >
       -c "

diff --git a/docker/manage b/docker/manage
@@ -107,7 +107,7 @@ build-oidc-controller() {
   #
   echo -e "\nBuilding oidc-controller image..."
   docker build \
-    -t 'vc-authn-oidc-controller' \
+    -t 'acapy-vc-authn-oidc-controller' \
     -f './oidc-controller/Dockerfile' '..'
 }
 

diff --git a/docs/BestPractices.md b/docs/BestPractices.md
@@ -1,18 +1,18 @@
 # VC AuthN Best Practices
 
-This document is intended as a list of best practices and recommendations that are applicable when using `vc-authn-oidc` as means of authorization provider for web applications.
+This document is intended as a list of best practices and recommendations that are applicable when using `acapy-vc-authn-oidc` as means of authorization provider for web applications.
 
 ## Ensure the response for the right proof was received
 
-When using `vc-authn-oidc` to secure a web application, the request to the identity provider must include a `pres_req_conf_id` query parameter set to the id of the `vc-authn-oidc` configuration that must be used to authenticate with the Identity Provider.
+When using `acapy-vc-authn-oidc` to secure a web application, the request to the identity provider must include a `pres_req_conf_id` query parameter set to the id of the `acapy-vc-authn-oidc` configuration that must be used to authenticate with the Identity Provider.
 
 The query parameter - however - can be changed dynamically: this is a desired behaviour, as it allows web applications to dynamically request the proof-request for the circumstance/scenario that is more appropriate.
 
-Similarly to checking a user's roles, when an id token is received from vc-authn the application should check that the value of the `pres_req_conf_id` attribute on the id token matches the value of the query parameter submitted to the IdP in the first place. If this is not the case, the user authentication may have been successful, but it did not satisfy the initial requirements (another example could be a web application that allows authentication using multiple Identity Providers, but only one of those is authorized to provide extended privileges to the user).
+Similarly to checking a user's roles, when an id token is received from `acapy-vc-authn-oidc` the application should check that the value of the `pres_req_conf_id` attribute on the id token matches the value of the query parameter submitted to the IdP in the first place. If this is not the case, the user authentication may have been successful, but it did not satisfy the initial requirements (another example could be a web application that allows authentication using multiple Identity Providers, but only one of those is authorized to provide extended privileges to the user).
 
 ## Consume the claims produced by the proof-request
 
-Starting with `v2.0.0`, claims populated by values provided in a proof-request are no longer individually added to the root of the JWT issued by VC-AuthN. This decision was made to limit the number of attribute mappers required in systems with more than one proof-request configuration available for relying parties to consume when authenticating.
+Starting with `v2.0.0`, claims populated by values provided in a proof-request are no longer individually added to the root of the JWT issued by ACAPy VC-AuthN. This decision was made to limit the number of attribute mappers required in systems with more than one proof-request configuration available for relying parties to consume when authenticating.
 
 Instead, all claims are packaged in the `vc_presented_attributes` returned at the root of the JWT. Example:
 

diff --git a/docs/ConfigurationGuide.md b/docs/ConfigurationGuide.md
@@ -15,7 +15,7 @@ The first step is to add VC Authn as a new Identity Provider for our AIM system.
 3. We will now configure the Open Id Connect parameters for our new provider.
 
 [!NOTE]
-VC-AuthN exposes the `.well-known/openid-configuration` endpoint to provide systems that support it automatic discovery of the endpoints and features of the Identity Provider. If you decide to do so, switch on **Use discovery endpoint** and enter `{VC_AUTHN_PUBLIC_URL}/.well-known/openid-configuration` to proceed.
+ACAPy VC-AuthN exposes the `.well-known/openid-configuration` endpoint to provide systems that support it automatic discovery of the endpoints and features of the Identity Provider. If you decide to do so, switch on **Use discovery endpoint** and enter `{VC_AUTHN_PUBLIC_URL}/.well-known/openid-configuration` to proceed.
 
 To input settings manually, or review them:
 
@@ -25,11 +25,11 @@ To input settings manually, or review them:
 
 - **Disable User Info**: it is recommended to disable the user info endpoint, since VC Authn does not store/provide user information.
 
-- **Client ID/Client Secret**: these settings will be used to identify and secure the IdP integration between Keycloak and VC Authn. Make sure the **client secret** parameter is unique to your VC Authn instance. VC-AuthN supports two methods of client authentication: `Client secret sent as basic auth` and `Client secret sent as post`.
+- **Client ID/Client Secret**: these settings will be used to identify and secure the IdP integration between Keycloak and VC Authn. Make sure the **client secret** parameter is unique to your VC Authn instance. ACAPy VC-AuthN supports two methods of client authentication: `Client secret sent as basic auth` and `Client secret sent as post`.
 
 - **Default Scopes**: this must be set to `vc_authn` to instruct the AIM broker which scopes to request from the IdP.
 
-- **Validate Signatures**: if you want to have the signature of VC-AuthN validated by Keycloak, turn this on, flip the `Use JWKS URL` to true and set `JWKS URL` to `{PUBLIC_VC_AUTHN_URL}/.well-known/openid-configuration/jwks`.
+- **Validate Signatures**: if you want to have the signature of ACAPy VC-AuthN validated by Keycloak, turn this on, flip the `Use JWKS URL` to true and set `JWKS URL` to `{PUBLIC_VC_AUTHN_URL}/.well-known/openid-configuration/jwks`.
 
 - **Forwarded Query Parameters**: set this to `pres_req_conf_id`. This parameter is used by VC Authn to lookup in its database the configuration to generate presentation request to be displayed to the user and the AIM system needs to forward it when initiating the authentication.
 
@@ -39,7 +39,7 @@ Save the settings and take note of the generated **Redirect URI** and **Client I
 
 ### Configuring VC Authn
 
-VC-AuthN can be configured by using the API endpoints exposed on Swagger at `VC_AUTHN_PUBLIC_URL}/docs`. The `oidc_clients` namespace provides RESTful APIs to create/delete/update clients.
+ACAPy VC-AuthN can be configured by using the API endpoints exposed on Swagger at `VC_AUTHN_PUBLIC_URL}/docs`. The `oidc_clients` namespace provides RESTful APIs to create/delete/update clients.
 
 To register a new client, `POST` a request to the `/clients` endpoint with a payload containing the client id/secret and redirect URL noted at the previous step. Example:
 
@@ -68,17 +68,17 @@ The following is an example mapper configuration:
 
 ## Direct Configuration
 
-VC-AuthN 2.0 only supports confidential clients, and cannot be configured to be invoked directly from Single-Page applications. For back-end systems, however, the above instructions should still apply.
+ACAPy VC-AuthN 2.0 only supports confidential clients, and cannot be configured to be invoked directly from Single-Page applications. For back-end systems, however, the above instructions should still apply.
 
 ## Environment Variables
 
-Several functions in VC-AuthN can be tweaked by using the following environment variables.
+Several functions in ACAPy VC-AuthN can be tweaked by using the following environment variables.
 
 | Variable                  | Type                                   | What it does                                                                                                                                                                                                                                                                                                                                                                                                                                           | NOTES                                                                                                                                   |
 | ------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------- |
 | SET_NON_REVOKED           | bool                                   | if True, the `non_revoked` attributed will be added to each of the present-proof request `requested_attribute` and `requested_predicate` with 'from=0' and'to=`int(time.time())`                                                                                                                                                                                                                                                                       |                                                                                                                                         |
-| USE_OOB_PRESENT_PROOF     | bool                                   | if True, the present-proof request will be provided as a an [out of band](https://github.com/hyperledger/aries-rfcs/tree/main/features/0434-outofband) invitation with a [present-proof](https://github.com/hyperledger/aries-rfcs/tree/main/features/0037-present-proof) request inside. If False, the present-proof request will be use the [service-decorator](https://github.com/hyperledger/aries-rfcs/tree/main/features/0056-service-decorator) | **TRUE:** BC Wallet supports our OOB Message with a minor glitch, BiFold, Lissi, Trinsic, and Estatus all read the QR code as 'Invalid' |
-| USE_OOB_LOCAL_DID_SERVICE | bool                                   | Instructs VC-AuthN to use a local DID, it must be used when the agent service is not registered on the ledger with a public DID                                                                                                                                                                                                                                                                                                                        | Use this when `ACAPY_WALLET_LOCAL_DID` is set to `true` in the agent.                                                                   |
+| USE_OOB_PRESENT_PROOF     | bool                                   | if True, the present-proof request will be provided as a an [out of band](https://github.com/hyperledger/aries-rfcs/tree/main/features/0434-outofband) invitation with a [present-proof](https://github.com/hyperledger/aries-rfcs/tree/main/features/0037-present-proof) request inside. If False, the present-proof request will be use the [service-decorator](https://github.com/hyperledger/aries-rfcs/tree/main/features/0056-service-decorator) | **TRUE:** BC Wallet supports our OOB Message, BiFold, Lissi, Trinsic, and Estatus all read the QR code as 'Invalid' |
+| USE_OOB_LOCAL_DID_SERVICE | bool                                   | Instructs ACAPy VC-AuthN to use a local DID, it must be used when the agent service is not registered on the ledger with a public DID                                                                                                                                                                                                                                                                                                                        | Use this when `ACAPY_WALLET_LOCAL_DID` is set to `true` in the agent.                                                                   |
 | USE_URL_DEEP_LINK         | bool                                   | If True, in Mobile mode the BC Wallet deep link will use an encoded URL (`WALLET_DEEP_LINK_PREFIX?_url={redirect URL}`), otherwise will use the encoded connection invitation (`{WALLET_DEEP_LINK_PREFIX}?c_i={connection invitation payload}`)                                                                                                                                                                                                        | Default False/.. To control using the `?_url` handler                                                                                   |
 | WALLET_DEEP_LINK_PREFIX   | string                                 | Custom URI scheme and host to use for deep links (e.g. `{WALLET_DEEP_LINK_PREFIX}?c_i={connection invitation payload`)                                                                                                                                                                                                                                                                                                                                 | Default bcwallet://aries_proof-request                                                                                                  |
 | LOG_WITH_JSON             | bool                                   | If True, logging output should printed as JSON if False it will be pretty printed.                                                                                                                                                                                                                                                                                                                                                                     | Default behavior will print as JSON.                                                                                                    |
@@ -89,16 +89,16 @@ Several functions in VC-AuthN can be tweaked by using the following environment
 
 The basic structure of a proof-request configuration is described [here](README.md#data-model). Additional options are described via the Swagger document, and listed below:
 
-- `include_v1_attributes`: defaults to `false`, switch to `true` if root-level claims as presented in VC-AuthN v1 are still required for the proof-request.
+- `include_v1_attributes`: defaults to `false`, switch to `true` if root-level claims as presented in ACAPy VC-AuthN v1 are still required for the proof-request.
 
 ### Proof Substitution Variables
 
-Proof Request configurations (as described [here](README.md#data-model)) are pre-set records stored in the VC-AuthN database comprising of the details to make the proof request from.
+Proof Request configurations (as described [here](README.md#data-model)) are pre-set records stored in the ACAPy VC-AuthN database comprising of the details to make the proof request from.
 At runtime when the user is directed to the proof challenge, the appropriate configuration is fetched and the proof request built from that.  
 In certain use cases you may want the proof request to have a specific value in the proof (probably in a requested predicate) generated at that moment rather than preset. 
 
 An example could be using today's date, a "right now" timestamp, or an age-check (IE today's date minus 19 years).  
-To accomodate this, VC-AuthN **proof substitution variables** can be used as placeholders in the configurations. They can just be added as string in the configuration with a `$` prefix.
+To accomodate this, ACAPy VC-AuthN **proof substitution variables** can be used as placeholders in the configurations. They can just be added as string in the configuration with a `$` prefix.
 There are a handful of built-in options:
 
 | Substitution Variable     | Details                                                                                   |
@@ -157,7 +157,7 @@ variable_substitution_map.add_variable_substitution(r"\$today_plus_(\d+)_times_(
 For an example of this python file see `docker/oidc-controller/config/user_variable_substitution_example.py`
 
 All that is necessary is the adding of substitution variables.These
-changes will be applied by vc-authn during startup. The variable
+changes will be applied by ACAPy VC-AuthN during startup. The variable
 `variable_substitution_map` **will already be defined**.
 
 After loading the python file during the service startup each new user

diff --git a/docs/MigrationGuide.md b/docs/MigrationGuide.md
@@ -1,15 +1,15 @@
-# VC-AuthN Migration Guide
+# ACAPy VC-AuthN Migration Guide
 
-This document contains instructions and tips useful when upgrading VC-AuthN.
+This document contains instructions and tips useful when upgrading ACAPy VC-AuthN.
 
 ## 1.x -> 2.x
 
-The functionality has mostly remained unchanged, however there are some details that need to be acocunted for.
+The functionality has mostly remained unchanged, however there are some details that need to be accounted for.
 
 * Endpoints: `authorization` and `token` endpoints have changed, review the new values by navigating to the `.well-known` URL and update your integration accordingly.
 
 * Proof configurations: to be moved to a `v2.0` instance, the following changes need to happen in existing proof-configurations.
   - The `name` identifier for disclosed attributes has been deprecated, use the `names` array instead.
   - If backwards-compatibility with `v1.0` tokens is required, the `include_v1_attributes` flag should be switched to `true` (see the [configuration guide](./ConfigurationGuide.md)).
 
-* Client Types: VC-AuthN 2.0 currently only supports confidential clients using client id/secret. If public clients were previously registered, they will now need to use an AIM (e.g.: keycloak) as broker.
+* Client Types: ACAPy VC-AuthN 2.0 currently only supports confidential clients using client id/secret. If public clients were previously registered, they will now need to use an AIM (e.g.: keycloak) as broker.