bcgov / ditp Goto Github PK
View Code? Open in Web Editor NEWDigital Identity and Trust Program Repository
License: Apache License 2.0
Digital Identity and Trust Program Repository
License: Apache License 2.0
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.
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.
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.
Non-Inclusive | Inclusive | |
---|---|---|
Whitelist | => | Allowlist |
Blacklist | => | Denylist |
Master / Slave | => | Leader / Follower; Primary / Standby; etc |
Grandfathered | => | Legacy status |
Sanity check | => | Quick check; Confidence check; etc |
Dummy value | => | Placeholder value; Sample value; etc |
This list is not comprehensive. If you're aware of other outdated nomenclature please create an issue (PR preferred) with your suggestion.
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:
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.
dormant
or retired
life cycle badge.Thank you for your help ensuring effective governance of our open-source ecosystem!
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 Lawyer 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 LSBC -- in dev, test and prod.
In concert, the verifiers of the LSBC credential, such as A2A, needs to be updated to accept the new creddef, along with the old one.
From a governance -- there needs to be a way to publish that a new CredDef is being issued. How do verifiers find out about it, and how do they know what to do about that? @3daniel1996
Assigning to @esune to start this one.
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.
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.
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.
A presentation request builder + Store presentation templates
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.
Unblocked - goal is to do this the week of March 13, 2023
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.Blocked by getting release pipeline producing multi-architecture containers (in progress -- Real Soon Now)
did:indy
-- Indy VDR PR 165Partially blocked by Indy VDR and AnonCreds work
did:indy
support.did:indy
AnonCreds method support (CWU in progress)did:indy
where possible (initialization, resolver, registrar)diddocContent
in ACA-Py
did:indy
support.did:indy
support.Partially blocked by Indy VDR and AnonCreds work
did:indy
support.did:indy
AnonCreds method support (CWU in progress)did:indy
where possible (initialization, resolver, registrar)diddocContent
in AFJ
did:indy
support.did:indy
support.Unblocked
did:indy
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.
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.
We’ll do this in conjunction with the Delivery team, and using a sandbox instance of Traction.
Initial tasks to be done:
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.
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).
Create location in bc-vcpedia GH repo to host OCA source, GH actions and OCA bundles
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.
OCA Bundle Builder Tool
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.
Create location in bc-vcpedia GH repo to host OCA source, GH actions and OCA bundles
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
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.
Knowledge transfer for items usually managed by @ianco, such as:
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.
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.
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:
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.
Document the architecture and technical requirements/steps necessary to perform load testing of VC issuance/revocation/verification.
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
AKA "I DON'T want to use the BC Wallet App"
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
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.
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!).
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.
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!!!
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.
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.
Short Code | Organization Name |
---|---|
AEST | Advanced Education, Skills & Training |
AGRI | Agriculture |
ALC | Agriculture Land Commission |
AG | Attorney General |
MCF | Children & Family Development |
CITZ | Citizens' Services |
DBC | Destination BC |
EMBC | Emergency Management BC |
EAO | Environmental Assessment Office |
EDUC | Education |
EMPR | Energy, Mines & Petroleum Resources |
ENV | Environment & Climate Change Strategy |
FIN | Finance |
FLNR | Forests, Lands, Natural Resource Operations & Rural Development |
HLTH | Health |
IRR | Indigenous Relations & Reconciliation |
JEDC | Jobs, Economic Development & Competitiveness |
LBR | Labour Policy & Legislation |
LDB | BC Liquor Distribution Branch |
MMHA | Mental Health & Addictions |
MAH | Municipal Affairs & Housing |
BCPC | Pension Corporation |
PSA | Public Service Agency |
PSSG | Public Safety and Solicitor General |
SDPR | Social Development & Poverty Reduction |
TCA | Tourism, Arts & Culture |
TRAN | Transportation & Infrastructure |
NOTE See an error or omission? Please create an issue here to get it remedied.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.