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.

We need to adjust the ISED Business Banking Initiative verifiable credential issuers. The model has changed a little, so here is the sequence that I would like to issue. @esune -- please review and let me know what we have in place and what we need to change. @alexgmetcalf , I'd appreciate it if you can do the words at the landing page (what to do) and post-issue page (what to do next). This issue covers what is in place, what has changed in the demo, what minimum changes that we need to do. I was going to add a thing about being able to minimize the QR codes in use, but I don't think that's realistic.

What Is In Place?

A sequence of three issuers:

• Issuer: https://bcreg-issuer-dev.pathfinder.gov.bc.ca/
  • Authentication is Test Services Card, issue is of a "Verified Person" credential from BC Registries
• Issuer: https://bcreg-registration-issuer-dev.pathfinder.gov.bc.ca/
  • Authentication is "Verified Person" credential, issue is of a "Verified Registration" credential from BC Registries
• Issuer: https://bcreg-relationship-issuer-dev.pathfinder.gov.bc.ca/
  • Authentication is "Verified Person" and "Verified Registration" credential from BC Registries
• Verifier: https://bcbank-verifier-dev.pathfinder.gov.bc.ca/
  • Authentication is all three issued credentials.

What is Changing

The first credential is going to be issued by IDIM -- Citizen Services -- instead of BC Registries. As well, there will be no unique identifier associated with the verified person -- just as there is no identifier in the DIACC/Peter Watkins verified person implementation.

@esune -- will use the site listed above updated, or will you use the DIACC/Peter Watkins site? I see pros and cons for both.

As well, the contents/attribute names in the credentials have changed and will be provided.

Minimum Changes

Change the first issuer to be from BC Citizen Services, the identifier removed, and change all of the subsequent authentications to use that credential. As such, there needs to be a different DID from the BC Registries DID. As well, change the value of the "identifier" for the "verified person" in the "verified relationship" credential to be the full name, since there is no longer a number to use.

Documentation:

Here is the flow I'm thinking we should follow:

• We give the person the URL for the BC Registries "Verified Organization" landing page. On that, we tell them that they need a "Verified Person" credential to proceed and a link to that site to open a new page/tabl, leaving the existing one open. The instructions should tell the user to come back to this site when done.
  • Alternatively, we should have a landing page for the whole process
• The verified person should have instructions to get that, including about the need to use the Services Card mobile app.
  • In an inside voice -- we can explain how to do this on the dev/test site with the test BC Services Card IDs that we have.
• The "Verified Person" "post issue" page should not be specific to the ISED Business Banking Initiative use case, but generic, so the user will have to remember to go back to the BC Registries page...
• The user will continue through the issuing process on the "Verified Organization" Issuer.
• On the "post-issue" page, the instructions should say that "Normally, the Verified Relationship credential should be automatically issued, but for this we have to do another authentication and issue process" and put in a link to the "Verified Relationship" issuer.
• On the Verified Relationship issuer page, explain the rest of the process and that there should not be extra QR codes.
• On the "post-issue" page, talk about using the credentials now held to open a bank account, and provide a link to the sample verifier.
• On the landing page for the verifier, make it like you are on a website to create a bank account.

We should probably have that site create a bank account and issue a credential for the bank account....

@alexgmetcalf -- could you please do the text for the examples -- using language that is helpful to business owners. The whole "verified relationship" thing is not needed.

Also worthwhile is going through the issuance of the last two creds twice to simulate a person that has more than one company. What does the holder experience look like when you have credentials for multiple companies?

See the bottom of this document for the new attributes in the credentials and how to populate them.

The Verifiable Credentials

The following cover the new attributes and how to populate them. I have put "blank" to indicate the field is not populated. Ideally, that will be either "" or null (which I think might be implemented -- at least in Aries Cloud Agent Python). If it has to have a value, please put "Not Issued".

Verified Person

• verifiedPersonKey - blank
• givenName - from Services Card
• additionalName (Optional) - middle name from Service Card (if any) or "Not Issued"
• familyName - from Services Card
• streetAddress - from Services Card
• city - from Services Card
• province - from Services Card
• country - from Services Card
• postalCode - from Services Card
• dateOfBirth - "Not Issued"
• phoneNumber - "Not Issued"
• alternatePhoneNumber (Optional) - blank
• email - blank
• gender (Optional) - blank
• issuer - "BC Citizen Services"
• issueDate - date of issue from Services Card
• expirationDate - date of expiration from Services Card (or "Not Issued")
• credentialStatus - "Issued"
• levelOfAssurance (Optional) - blank

Verified Organization

• verifiedOrganizationKey - generate per BC RegID format
• businessNumber - generate - 9 digits
• entityType - BC Corp
• registeredLegalName - let the user type in the name
• homeJurisdictionLegalName (Optional) - blank
• alternateLegalName (Optional) - blank
• operatingName (Optional) - blank
• streetAddress - allow user to enter full address (autocomplete??? :-) )
• city
• province
• country
• postalCode
• legislation (Optional) - blank
• registeredJurisdiction (Optional) - "BC"
• homeJurisdiction - "BC"
• director001FullName (Optional) - user entered
• director001StreetAddress (Optional) - blank
• director001City (Optional) - blank
• director001Province (Optional) - blank
• director001Country (Optional) - blank
• director001PostalCode (Optional) - blank
• director001CanadianResident (Optional) - blank
• registrationDate
• director002FullName (Optional) - user entered
• director002StreetAddress (Optional) - blank
• director002City (Optional) - blank
• director002Province (Optional) - blank
• director002Country (Optional) - blank
• director002PostalCode (Optional) - blank
• director002CanadianResident (Optional) - blank
• registrationDate - today() or today() - random(1500)
• registrationExpiryDate (Optional) - registrationRenewalEffectiveDate + 1 year
• registrationRenewalEffective (Optional) - today() or today() - random(60)
• registeredLegalNameEffective - registrationDate
• homeJurisdictionLegalNameEffective - registrationDate
• entityStatus - "Active"
• entityStatusEffective - registrationDate
• issuer - "BC"
• issueDate - today()
• expirationDate - registrationExpiryDate
• credentialStatus - "Active"

Verified Relationship

• verifiedPersonKey - blank
• verifiedPersonIssuer - "BC Citizen Services"
• verifiedOrganizationKey - from Verified Organization
• verifiedOrganizationIssuer - from Verified Organization
• registeredLegalName - from Verified Organization
• relationship - "Director"
• relationshipDescription - blank
• relationshipStatus - "Active"
• relationshipStatusEffective (Optional) - registrationDate from Verified Organization
• issuer - "BC Registries"
• issueDate - today()
• expirationDate - blank
• credentialStatus - "Active"

Tweaks to the issuer kit functionality for the three items:

• Verified Person:
  • Set Identity Assurance Level to "3" and readonly
  • Make Phone Number, Alternate Phone Number, Email Address and Gender blank and readonly
    • That should remove any editing of the credential
• Verified Organization:
  • In "Director List", set to "familyName, givenName" using the data from the authentication claims -- readonly
    • Let me know if combining claims like that is possible in issuer kit -- or what it would take to make possible

This deployment uses three schemas that were defined at the ISED Business Banking Initiative level in the early days of the project. Recently, a new version of the Schemas has been defined. We need to update the Schemas to the new ones. That will include:

• Getting the new Schema defined in the config for this repo and published on the appropriate ledgers.
• Updating the default values that are being used to populate the SurveyJS forms for specific values.
  • Fields are populated via: data from the authentication process, populated by code snippets, typed in by the user.
  • Some of the existing fields will go away, others added and will need to be populated from a code snippet.
  • Note that some fields will just be renamed and in that case, the way the field is populated will remain the same.
• The presentation requests will need to be updated to reflect the schema fields added or removed.

I'm working on the getting a list of the new fields and from there the delta between the old and new. This will include the attributes removed, renamed. left the same and added.

Heads up @wadeking98 -- this will be coming your way Real Soon Now.

Please review the deployment of this URL: https://bcreg-registration-issuer.apps.silver.devops.gov.bc.ca/

Why after clicking "Agree" (after checking the checkbox) we get a page with an {"error":"invalid_client"} error. Looks like perhaps something with the SSO config is wrong? URL issue?

Here is where we are getting the error: https://toip-vc-authn-controller.apps.silver.devops.gov.bc.ca/vc/connect/authorize?scope=openid+vc_authn&state=LftrR1-HY0lbIAvGFnWx9WH8L2WBRyAUGcEvya79se4.u1BqGsXBRrg.bcreg-registration-issuer&response_type=code&client_id=gzyg46lx-prod&redirect_uri=https%3A%2F%2Foidc.gov.bc.ca%2Fauth%2Frealms%2Fgzyg46lx%2Fbroker%2Fverifiable-credential%2Fendpoint&pres_req_conf_id=citz-verified-person&nonce=-3TebEiW6z19A9XBFEPhgA

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!

Now that routes using the vonx.io domain have been set-up for the tails servers, it would be nice to use those so that future migrations (hopefully this will not actually happen) can be seamless.

DEV: https://tails-dev.vonx.io
TEST: https://tails-test.vonx.io

I've noticed that the deployment is not working on production with the Trinisic Wallet. Please go through the deployment and try to figure out why it is not working with that wallet. Here is the set of production URLs:

• Get the Trinisic Wallet and initialize
• In the settings, for "Network", pick "Sovrin Staging"
• https://bcgov-citz-issuer.apps.silver.devops.gov.bc.ca/
  • Use the "Test Services Card" for authentication and "DIACC1001" and "98901" for testing (can also use 2, 3, 4, 5 for the last digits)
  • Fill in missing data (DoB, email, Gender -- I think that is all)
    • Bug: When I went in I found some fields that should have been empty were filled in (e.g. email address).
      • Seems like data from another session is being picked up?
      • To test this -- hit "Submit" without filling in anything to see what fields are empty -- should be the same everytime
  • Get a VP credential
• https://bcreg-registration-issuer.apps.silver.devops.gov.bc.ca/
  • Authentication: Presentation request for data from the VP credential
    • Issue: Sometimes this doesn't work -- seems VP is still in "Pending" state until I look at the credential.
  • Fill in more data -- any fields that are empty
  • Get the VO credential
    • Issue: This is the point the demo fails -- the connection is made and the Credential Offer sent, but nothing happens on the Mobile side.
• https://bcreg-relationship-issuer.apps.silver.devops.gov.bc.ca/
  • Authentication: Presentation request for data from the VP and VO credentials
  • Fill in data
  • Get the VR credential
• https://business-bank-verifier.apps.silver.devops.gov.bc.ca/
  • Authentication: Presentation request for data from the VP, VO and VR credentials
  • Done!!

Note that I tried this with the BC Wallet as well, and it also failed at the same point -- getting the VO credential from the second Issuer Kit instance.

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.

In order to decommission the demo, we need to complete the following steps:

• confirm there are no references in public-facing the BC Digital Trust website (@alexgmetcalf )
• save a back-up of the agent wallets (@WadeBarnes / @esune)
• spin down the deployments (@WadeBarnes / @esune )
• remove configurations from OCP (@WadeBarnes / @esune / @rajpalc7 )
• close this issue (@WadeBarnes / @esune )
• archive this repository (@WadeBarnes / @esune )

The shared wallet component can be upgraded to using Postgres 12. In OCP4, the image is available as: "kind":"ImageStreamTag","name":"postgresql:12","namespace":"openshift"

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.

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!