This issue is a kind reminder that your repository has been inactive for 483 days. Some repositories are maintained in accordance with business requirements that infrequently change thus appearing inactive, and some repositories are inactive because they are unmaintained.

To help differentiate products that are unmaintained from products that do not require frequent maintenance, repomountie will open an issue whenever a repository has not been updated in 180 days.

• If this product is being actively maintained, please close this issue.
• If this repository isn't being actively maintained anymore, please archive this repository. Also, for bonus points, please add a dormant or retired life cycle badge.

Thank you for your help ensuring effective governance of our open-source ecosystem!

The test and "prod" OpenVP-CANdy issuer services have been migrated to their respective ledgers now that we have a full set of CANdy ledgers and not just dev.

The migration included creating new DIDs for the services. The old DIDs and any credentials issued by those DIDs are still valid, so references to the existing credentials should be retained.

Details of the new (and old) DIDs can be found here; #124

Affects:

• https://github.com/bcgov/essential-services-delivery/blob/main/proof-configurations/es_org/test/es_org.json
• https://github.com/bcgov/essential-services-delivery/blob/main/proof-configurations/es_org/prod/es_org.json
• https://github.com/bcgov/essential-services-delivery/blob/main/proof-configurations/contact_address/test/contact_address.json
• https://github.com/bcgov/essential-services-delivery/blob/main/proof-configurations/contact_address/prod/contact_address.json
• https://github.com/bcgov/essential-services-delivery/blob/main/proof-configurations/es_access/test/es_access.json
• https://github.com/bcgov/essential-services-delivery/blob/main/proof-configurations/es_access/prod/es_access.json
• https://github.com/bcgov/essential-services-delivery/blob/main/proof-configurations/safe_entry_c19/test/safe_entry_c19.json
• https://github.com/bcgov/essential-services-delivery/blob/main/proof-configurations/safe_entry_c19/prod/safe_entry_c19.json

The services need to be deployed to the prod namespace.

Wallets need to be migrated over from the OCP3 namespace, and for services using a *.vonx.io vanity URL DNS migration and certificate installation needs to be performed as well.

@wadeking98 please proceed with deploying all the issuers in read only mode, using the wallets and secret values from OCP3.
Once ready, coordinate with @WadeBarnes to add the vonx.io routes and certificates, and switch the DNS entry to point to the new cluster.

TL;DR

Topics greatly improve the discoverability of repos; please add the short code from the table below to the topics of your repo so that ministries can use GitHub's search to find out what repos belong to them and other visitors can find useful content (and reuse it!).

Why Topic

In short order we'll add our 800th repo. This large number clearly demonstrates the success of using GitHub and our Open Source initiative. This huge success means its critical that we work to make our content as discoverable as possible; Through discoverability, we promote code reuse across a large decentralized organization like the Government of British Columbia as well as allow ministries to find the repos they own.

What to do

Below is a table of abbreviation a.k.a short codes for each ministry; they're the ones used in all @gov.bc.ca email addresses. Please add the short codes of the ministry or organization that "owns" this repo as a topic.

That's in, you're done!!!

How to use

Once topics are added, you can use them in GitHub's search. For example, enter something like org:bcgov topic:citz to find all the repos that belong to Citizens' Services. You can refine this search by adding key words specific to a subject you're interested in. To learn more about searching through repos check out GitHub's doc on searching.

Pro Tip 🤓

• If your org is not in the list below, or the table contains errors, please create an issue here.

• While you're doing this, add additional topics that would help someone searching for "something". These can be the language used javascript or R; something like opendata or data for data only repos; or any other key words that are useful.

• Add a meaningful description to your repo. This is hugely valuable to people looking through our repositories.

• If your application is live, add the production URL.

Ministry Short Codes

NOTE See an error or omission? Please create an issue here to get it remedied.

Following the recent updates to vc-visual-verifier, we should update the deployment configurations so that content from a configmap can be mounted on the container to customize the landing page.

The pattern to follow would be similar to what we already do for the components deployed using issuer-kit code, allowing the overrides to be defined by profile.

Several of the issuer agent instances are being throttled at >50% on average. Review and adjust the CPU resource allocations, primarily the CPU limit to reduce or eliminate the throttling. The goal should be to reduce throttling to <25% on average. For production an even lower average may be desirable.

These metrics can be easily reviewed using the Namespace Monitoring dashboard available through Grafana in our new monitoring stack.

Affected instances:

• Open VP
• Open VP CANdy

<This is a work in progress -- details are still being added>

We need to deploy three standard issuers and a verifier in sequence as a stand in for the BC Registries issuer as part of the ISED Business Banking Initiative. That initiative has a business owner receiving three credentials about their business from BC Registries and then using those credentials to open a business bank account.

@esune -- I'll describe this using features we have today, but something to consider. Can we have the issuing happen from a single issuer using the same connection? No problem if not, but that would be neat :-)

The flow we'll be using is the following:

• Use the test services card to get into a "BC registries verified person" credential
• Use the "BC Registries verified person" VC to get a "registration" credential (about the business)
• Use the "BC Registries verified person" and the "registration" credential to get a "Verified Relationship" credential (the person to the business)
• Have "Visual Verifier" for the Bank that checks for all three VCs -- all data

The VCs we can start with are all defined here: https://github.com/bcgov/von-bc-registries-agent/blob/master/bcreg-aca/config/schemas.yml. We want to use:

• demo.verified_person.registries.ca
• registration.registries.ca
• demo.person_relationship.registries.ca

For a first cut, the Visual Verifier can grab interesting ones from all three -- registration_id, entity_name, entity_status (registration), First Name, Last Name, email address, phone number (verfied person) and Registration ID, Associated registration name, relationship_description, relationship_status (verified person relationship).

Add configuration to enable optional help text in issuer-web components.

The deployment configurations for the API component need to be updated to match the new configurations used in identity-kit/issuer-kit.

Dev:

• DID: Ui6HA36FvN83cEtmYYHxrn rooted on CANdy-Dev
• Update the DID with and Alias: CANdy - Unverified Person Issuer (Dev)
• Ensure the author's agent is configured to be an author on the ledger (role=null)
• Make sure all services connected to the author's agent, other than the wallet, are shutdown; controllers, apis, web interfaces.
• Ensure the author's agent configuration has been updated to support the endorser protocol settings.
• Update the author's agent settings to enable the endorser protocol.
• Ensure READ_ONLY_LEDGER=false on the author's agent.
• Accept TAA though the author's agent if needed. Switching to multi-ledger breaks existing TAAs
• Ensure the author's public endpoint has been written to the ledger.
• Register the agent with the BC Endorser Service using the ./manage registerAuthor script.
• Restart all services connected to the author's agent.

Test:

• Old DID: XZQpyaFa9hBUdJXfKHUvVg rooted on CANdy-Dev
  • Demote
• New DID: HTkhhCW1bAXWnxC1u3YVoa rooted on CANdy-Test
• Start out with ACAPY_READ_ONLY_LEDGER=true
• Migrate the OpenVP-CANdy DID to CANdy-Test. Create a new DID, the existing one is on CANdy-Dev as it pre-dates the CANdy-Test ledger. Use the CANdy-Test - Government of British Columbia - Endorser to write the new DID.
• Set the alias to CANdy - Unverified Person Issuer (Test)
• Ensure the author's agent is configured to be an author on the ledger (role=null)
• Make sure all services connected to the author's agent, other than the wallet, are shutdown; controllers, apis, web interfaces.
• Ensure the author's agent configuration has been updated to support the endorser protocol settings.
• Update the author's agent settings to enable the endorser protocol.
• Ensure READ_ONLY_LEDGER=false on the author's agent.
• Accept TAA though the author's agent if needed. Switching to multi-ledger breaks existing TAAs
• Ensure the author's public endpoint has been written to the ledger.
• Register the agent with the BC Endorser Service using the ./manage registerAuthor script.
• Restart all services connected to the author's agent.
• Ensure Schemas and Cred-Defs get written to the ledger.

"Prod":

• Old DID: 9wVuYYDEDtpZ6CYMqSiWop rooted on CANdy-Dev
  • Demote
• New DID: 4eCXHS79ykiMv2PoBxPK23 rooted on CANdy-Test
• Start out with ACAPY_READ_ONLY_LEDGER=true
• Migrate the OpenVP-CANdy DID to CANdy-Test (NOT CANdy-Prod). Create a new DID, the existing one is on CANdy-Dev as it pre-dates the CANdy-Test ledger. This VC is meant for testing purposes only. Such DIDs do not get written to production ledgers. Use the CANdy-Test - Government of British Columbia - Endorser to write the new DID.
• Set the alias to CANdy - Unverified Person Issuer (Prod)
• Ensure the author's agent is configured to be an author on the ledger (role=null)
• Make sure all services connected to the author's agent, other than the wallet, are shutdown; controllers, apis, web interfaces.
• Ensure the author's agent configuration has been updated to support the endorser protocol settings.
• Update the author's agent settings to enable the endorser protocol.
• Ensure READ_ONLY_LEDGER=false on the author's agent.
• Accept TAA though the author's agent if needed. Switching to multi-ledger breaks existing TAAs
• Ensure the author's public endpoint has been written to the ledger.
• Register the agent with the BC Endorser Service using the ./manage registerAuthor script.
• Restart all services connected to the author's agent.
• Ensure Schemas and Cred-Defs get written to the ledger.

Update dependent services and references:

Test - XZQpyaFa9hBUdJXfKHUvVg => HTkhhCW1bAXWnxC1u3YVoa

• Code references: https://github.com/search?q=org%3Abcgov+XZQpyaFa9hBUdJXfKHUvVg&type=code

  • bcgov/bc-wallet-mobile#806
  • bcgov/issuer-kit-demo-verifier-chat#84
  • bcgov/trust-over-ip-configurations#123
  • #125

• Discussions: https://github.com/search?q=org%3Abcgov+XZQpyaFa9hBUdJXfKHUvVg&type=discussions

"Prod" - 9wVuYYDEDtpZ6CYMqSiWop => 4eCXHS79ykiMv2PoBxPK23

• Code references: https://github.com/search?q=org%3Abcgov+9wVuYYDEDtpZ6CYMqSiWop&type=code

  • bcgov/bc-wallet-mobile#806
  • #125

• Discussions: https://github.com/search?q=org%3Abcgov+XZQpyaFa9hBUdJXfKHUvVg&type=discussions

Update URL for "PROD" environment

• https://openvp-candy-dev.vonx.io/ => https://openvp-candy.vonx.io/
  • Update Open Verified Person (OpenVP) Credential with new URL.

Please deploy a new instance of the Unverified Person instance of Identity Kit, but anchored on the CANdy Dev network.

We will need to get an Endorser DID for this, and ideally have an automated way to create and execute transactions. However, for now, we can manually endorse (e.g., have Wade B do them with the Indy CLI) create, endorse and execute the necessary transactions.

For the URL, I suggest that we use "unvp-candy.dev" and then plan on later having a test versions of the URL.

Let me know what else is needed to get this done.

This issue is a kind reminder that your repository has been inactive for 180 days. Some repositories are maintained in accordance with business requirements that infrequently change thus appearing inactive, and some repositories are inactive because they are unmaintained.

To help differentiate products that are unmaintained from products that do not require frequent maintenance, repomountie will open an issue whenever a repository has not been updated in 180 days.

• If this product is being actively maintained, please close this issue.
• If this repository isn't being actively maintained anymore, please archive this repository. Also, for bonus points, please add a dormant or retired life cycle badge.

Thank you for your help ensuring effective governance of our open-source ecosystem!

The project contains a number of deployments of both issuer-web and visual-verifier that use vc-authn directly as authentication method.

Please update the configurations (either value in a secret or config.json) to use the new OCP4 URLs, paying attention to use the correct instance of vc-authn for each one.

No Project Lifecycle Badge found in your readme!

Hello! I scanned your readme and could not find a project lifecycle badge. A project lifecycle badge will provide contributors to your project as well as other stakeholders (platform services, executive) insight into the lifecycle of your repository.

What is a Project Lifecycle Badge?

It is a simple image that neatly describes your project's stage in its lifecycle. More information can be found in the project lifecycle badges documentation.

What do I need to do?

I suggest you make a PR into your README.md and add a project lifecycle badge near the top where it is easy for your users to pick it up :). Once it is merged feel free to close this issue. I will not open up a new one :)

This issue is a kind reminder that your repository has been inactive for 181 days. Some repositories are maintained in accordance with business requirements that infrequently change thus appearing inactive, and some repositories are inactive because they are unmaintained.

To help differentiate products that are unmaintained from products that do not require frequent maintenance, repomountie will open an issue whenever a repository has not been updated in 180 days.

• If this product is being actively maintained, please close this issue.
• If this repository isn't being actively maintained anymore, please archive this repository. Also, for bonus points, please add a dormant or retired life cycle badge.

Thank you for your help ensuring effective governance of our open-source ecosystem!

Please update the "essential services" delivery instances to all use two ledgers for reading - Sovrin Staging (current) and CANdy-Dev (new). All of the existing instances should continue to write to Sovrin Staging (if necessary at all -- only those with revocation should need that). In doing this, all instances of ACA-Py need to be upgraded to 0.7.3-RC0 (for now) and 0.7.3 when available.

Per #108 -- please add a new deployment to this repo for a new unverified person, where that instance using both Sovrin Staging and CANdy-Dev (per the others), but that writes to CANdy-Dev.

In implementing these changes, please consider what improvements could be made to the management. What would change if we use a multi-tenant ACA-Py instance? What if we were using the (being designed) Traction API?

Agent deployments in the namespace seem to be affected by reaching the compute - long running quota, which causes new deployments to not roll-out.

Review and adjust resources as necessary.