Knowledge transfer for items usually managed by @ianco, such as:

• BC Registries (business and issuer)
  • The upcoming BC Registries Upgrade
• ACA-Py Demo — details and updating
• ACA-Py Integration Tests — architecture, updating, extending
• ACA-Py PR Reviews and community support

Merged in a recent change to add new endpoints to the indy-tails-server that allow loading files based on the tails file hash vs. the revocation registry id.

• Test the change with the indy-tails-file integration tests
• Test the change with AATH
• Create a new release -- verify that it works
• Update AATH to use the new version
• Update ACA-Py docker-compose.yaml files to use the new version

PR: bcgov/indy-tails-server#55

Add a mechanism to the wallet to track in the database what ledger RevEntry writes are made and included that in a startup (or Admin API endpoint?) check that the wallet is in sync with the ledger.

The concern is that when a wallet must be restored from backups we have a way to check if the wallet is in sync with the ledger. For some objects (DIDs, Schema, Cred Defs, RevRegs), we can just check if the ledger objects created by the wallet exist on the ledger. However, I don't think that can be done for RevEntries. If it is not possible then let's make it possible by storing information in the database when we write a RevEntry.

Monitor the activities in the KERI (identifiers, sort of analogous to DIDs) and ACDCs (chained credentials analogous to VCs) built on KERI, and their use in the VCs for Organization ecosystem by GLEIF in their vLEIs (Verifiable Legal Entity Identifiers) program, and decide if these efforts should impact the DITP program.

In order to trigger the upgrade to a new Revocation Registry, we have determined that the best approach is to create a new Credential Definition for the Person credential.

We need to determine exactly how to do that. Presumably, we just set the new CredDef Tag in the Controller configuration and restart the agent, but that has to be verified and documented. Then, that needs to be applied to IDIM -- in dev, test and prod.

In concert, the verifiers of the IDIM Person credential, such as A2A, needs to be updated to accept the new creddef, along with the old one.

Assigning to @esune to start this one.

The dts-endorser-service instances used by BC Gov do not currently support auto-accepting connections from tenants in an "approved" managed instance (e.g.: Traction). This causes friction with tenants self-managing their settings, as well as delays in having an "enabled" issuer, especially for lower environments such as dev, test.

We need to improve the endorser API (found in https://github.com/hyperledger/aries-endorser-service) to be potentially able to auto-accept connections from a whitelist (all agents in an agency will have the same public endpoint) in order to streamline this process.

I believe the following describes the desired state:

• an unknown agent requests to connect with the endorser (using its public DID): the connection request is approved/denied manually by an admin using the API
• an agent from an agency in an allow list (e.g.: Traction instance) requests to connect with the endorser: the connection request is accepted automatically.

In Traction we are deciding upfront whether a tenant can/cannot connect to an endorser and therefore become an issuer and have endorsement requests accepted. Once an agent is connected to an endorser, all endorsement requests will be automatically approved (i.e.: no admin should have to action an API to approve a new schema/creddef, etc.).

Governance question: does this reflect where we want to be with BC Gov (have we even thought about this?), or a different pattern has been envisioned? I think this is the path of least friction and effort to manage resources, and accepting the request for a tenant (and allowing them to be an issuer or not) will act as proper governance "gate".
Looking for input from @krobinsonca, @swcurran, @WadeBarnes and others.

Need a way for an Issuer to use existing schema/OC bundle for their configuration to be able to issue without recreating a new schema/OCA bundle

Create location in bc-vcpedia GH repo to host OCA source, GH actions and OCA bundles

https://github.com/bcgov/bc-vcpedia

AKA "I DON'T want to use the BC Wallet App"

Monitor the activities in the use of the IETF standards track BBS+ Signatures for Verifiable Credentials and decide if these efforts should impact the DITP program. Consider in the DITP's efforts in moving forward AnonCreds if/when effort should be put into a new generation of AnonCreds possibly based on BBS+ Signatures.

The following outlines the steps to get to did:indy, the elimination of unqualified and did:sov public DIDs, and their use throughout the community.

did-indy-networks

Unblocked - goal is to do this the week of March 13, 2023

• Create the did-indy-networks repo and populate it with genesis files from all known Indy Networks. This repository is the "discovery" mechanism for Indy networks that support did:indy.

Indy VDR

Blocked by getting release pipeline producing multi-architecture containers (in progress -- Real Soon Now)

• Release Indy VDR with support for did:indy -- Indy VDR PR 165

AnonCreds -- anoncreds-rs

• Complete anoncreds-rs code, build process and publish release artifact.

ACA-Py

Partially blocked by Indy VDR and AnonCreds work

• Update ACA-Py to Indy VDR version with did:indy support.
• Update ACA-Py to use anoncreds-rs, including using did:indy AnonCreds method support (CWU in progress)
• Rework the ACA-Py multi-ledger support to use did:indy where possible (initialization, resolver, registrar)
• Update DID registration process and resolver to use diddocContent in ACA-Py
  • Could do now using ATTRIB or blocked on Indy VDR with did:indy support.
• Transition deployments of ACA-Py use Aries Askar with did:indy support.

Aries Framework JavaScript

Partially blocked by Indy VDR and AnonCreds work

• Update AFJ to Indy VDR version with did:indy support.
• Update AFJ to use anoncreds-rs, including did:indy AnonCreds method support (CWU in progress)
• Rework the AFJ multi-ledger support to use did:indy where possible (initialization, resolver, registrar)
• Update DID registration process and resolver to use diddocContent in AFJ
  • Could do now using ATTRIB or blocked on Indy VDR with did:indy support.
• Update Bifold to use updated AFJ
• Transition deployment of Bifold to use Aries Askar with did:indy support.

Indy Network Deployments

Unblocked

• Deploy Indy networks to support Ubuntu 20.04 and did:indy
  • CANDY
  • BCovrin
• Others update Indy Networks:
  • Sovrin

We’ll do this in conjunction with the Delivery team, and using a sandbox instance of Traction.

Initial tasks to be done:

• Decide on the goals of the course — what should the participants come away with?
• Create a draft agenda
• Determine the starting point for the DT knowledge of the participants
• Decide on the technical level of the participants
• Create workshops for the participants

Although this instance of the workshop is geared towards verifiers, some of the content, especially the introductory parts, will be reused for workshops covering each of our services.

As we start hosting agents for third-party issuers, we also need to provide developers with tools for troubleshooting their interactions with the agents.

Accessing the agent(s) logs is necessary both during the initial implementation and when troubleshooting issues, and having to submit a request to see the logs, wait for someone to be available to pull them and support them generates a lot of overhead.

We could be looking into the possibility of providing access to the aggregated logs for theagent deployment (all the pods) using Kibana, the tool that is alrady built-in to OpenShift, if access to the logs is possible without also allowing access to the management console.

Another alternative could be building a dashboard using sysdig.

Acceptance Criteria:
Design document outlining how to achieve the above.

OCA Bundle Builder Tool

Document the architecture and technical requirements/steps necessary to perform load testing of VC issuance/revocation/verification.

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!

There are several efforts happening around JWS for VCs, including two jws-vc specs, plus work going on in the Activity Streams (aka Mastodon) communities. Monitor these happenings and decide if these efforts should impact the DITP program.

Courthouse Libraries of BC (CLBC) is looking into standing up a new we service based on Drupal. In this new web app they would like to look into integrating with LSBC Member Card as the most effectively way of identifying accredited lawyers in good standing.

Acceptance Criteria

• An OIDC gateway/proxy is setup for them which uses a proof request for authentication
• For the PoC, the proof request will be based on the Member Card issued by the showcase
• (Bonus) CLBC is able to configure the application endpoints themselves

The ToIP Trust Spanning Layer is a proposal to get to a single ToIP Layer 2 messaging protocol, much as the TCP/IP layers was created for the Internet. The idea is that we can all agree on a single Layer 2 protocol, with flexibility above and below, we can build interoperable digital trust applications.

Monitor the Trust Spanning Layer efforts and decide if and when they should impact the DITP program

Create location in bc-vcpedia GH repo to host OCA source, GH actions and OCA bundles

https://github.com/bcgov/bc-vcpedia

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 it's 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 it, 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.

Discussions have begin in the Aries community on what to include in Aries Interop Profile (AIP) 3.0 (initial draft HackMD document. AIP 3.0 is initially at least focused on extending AIP 2.0 to support DIDComm V2, perhaps using the WACI-DIDComm work that was done in 2021/22.

Monitor the activities in W3C and Aries on the use of W3C Verifiable Credentials Data Model Standard LD-Signature (aka Data Integrity Proofs) and BBS+ Signatures for JSON-LD credentials and decide if the activities should impact the DITP program. This monitoring may combine with the effort to issue AnonCreds verifiable credentials and verifiable presentations in W3C Verifiable Credentials Data Model Standard and possibly even issue verifiable credentials with both an AnonCreds signature and LD-Signature.

Monitor the activities in the OpenID Foundations' OpenID4VCs efforts (issuance and verification) and decide if these efforts should impact the DITP program. Include in that monitoring the SD-JWTs (Selective Disclosure JSON Web Tokens).

Mobile wallet apps needs access to ledger data (DIDDOC, Revocation Registry, ...). Access to ledgers are done via ZMQ on port 9702. That port is usually blocked in corporate firewalls.

Blocking:

• bcgov/bc-wallet-mobile#403

A presentation request builder + Store presentation templates

TL;DR 🏎️

Teams are encouraged to favour modern inclusive phrasing both in their communication as well as in any source checked into their repositories. You'll find a table at the end of this text with preferred phrasing to socialize with your team.

Words Matter

We're aligning our development community to favour inclusive phrasing for common technical expressions. There is a table below that outlines the phrases that are being retired along with the preferred alternatives.

During your team scrum, technical meetings, documentation, the code you write, etc. use the inclusive phrasing from the table below. That's it - it really is that easy.

For the curious mind, the Public Service Agency (PSA) has published a guide describing how Words Matter in our daily communication. Its an insightful read and a good reminder to be curious and open minded.

What about the master branch?

The word "master" is not inherently bad or non-inclusive. For example people get a masters degree; become a master of their craft; or master a skill. It's generally when the word "master" is used along side the word "slave" that it becomes non-inclusive.

Some teams choose to use the word main for the default branch of a repo as opposed to the more commonly used master branch. While it's not required or recommended, your team is empowered to do what works for them. If you do rename the master branch consider using main so that we have consistency among the repos within our organization.

Preferred Phrasing

Pro Tip 🤓

This list is not comprehensive. If you're aware of other outdated nomenclature please create an issue (PR preferred) with your suggestion.

Monitor the activities in the ISO mDL (mobile Driver's License) efforts on mDL itself, and the more general use of the mDocs digital credential format, and decide if these efforts should impact the DITP program.

Please create the repo and add myself, @WadeBarnes and @amanji as maintainers. Please activate DCO on the repo. I'll add content as soon as the repo is created.

Tasks

Acceptance Criteria

• Required - Mediator Service deployment in HA-fashion and running multiple replicas (3+)
  • This includes the Agent (auto-scaled), wallet (HA instance of Postgres), Proxy (auto-scaled), External Queue (HA instance of Redis or Kafka), Message Workers (auto-scaled).
  • Note regarding the Proxy, it would be nice to eliminate this layer, though it is useful for traffic control and rate limiting. However relying on it to route messages to the separate http and ws ports of the aca-py agents is undesirable.
  • With the use of web sockets auto-scaling is best performed on the basis of the web socket connections themselves. This helps to ensure that pods with active web socket connections are not terminated by the system scaling them down prematurely. There are several ways to accomplish this.
• Highly Desired - No session/cookie affinity: A agent may seamlessly connect and be served by any of the replicas
  • The use of web sockets defines the current need for session affinity. The socket is opened between a client and an agent/worker instance. Once established all traffic must be routed between the same client and agent/worker instance. This is a challenge in K8S/OCP, especially when to comes to HPAS.
  • Are there any alternatives to using web sockets?
• Required - Uptime/performance monitoring at Aries protocol level (not just http/s)
  • For example, the k8s compatible status endpoints on the agents do not provide sufficient information regarding the state and health of the websocket connections, nor do they provide any metrics on the durability and longevity of the websocket connections.

Blocked By:

• hyperledger/aries-cloudagent-python#2116
  • This PR addresses vertical scalability on a single instance mediator, it does not address any of issues encountered in an HA or horizontally scalable environment.

Additional Resources:

• aries-mediator-service - Load testing
• aries-cloudagent-loadgenerator