Currently, the ./scripts/gen_ocabundlesjson.sh script looks specifically for Bundles exactly three levels below the OCABundles folder (e.g. in folders such as aries-oca-bundles/OCABundles/schema/bcgov-digital-trust/mines-act-permit-1_1_1).

Please update the script to scan the OCABundles folder and for every folder, regardless of depth if there is an OCABundle.json and a README.md file, process the two files to add their information to the root folder JSON files (ocabundles.json and ocabundleslist.json).

If the OCABundle.json file exists, but the README.md does not, suggest printing a warning message to standard out, and not processing the file (since there will be no identifiers for the JSON files).

In doing this, suggest looking for other issues with this script to work as well.

In the OCA Explorer, add an "Upload Image" box for each of the branding images. On upload:

• convert the image to base64
• turn the image into a "data:" url (see https://github.com/hyperledger/aries-rfcs/pull/780/files)
• Insert the "data:" URL into the image field -- noting the length (number of characters) in the field

On downloading the branding.json file, include the "data:" URL in the JSON.

The use of "data" URLs is already supported. w00t!!

OCA Explorer has been migrated to its own repo at bcgov/aries-oca-explorer. This ticket tracks the following tasks:

• Remove the OCA Explorer application from this repo
• Remove the associated GH action to deploy to GH pages
• (Optional) rename the OCABundles directory. (@swcurran if this step is unnecessary we can skip it)

The OCA Explorer is very cool, but mainly to experts. It would be great to have some improvements to the design of the page and the guidance for how to use it.

Acceptance Criteria:

• Update the Readme to include documentation about the OCA Explorer and how to use it
• Update the OCA Explorer page to include styling/branding: see https://bcgov.github.io/orgbook-bc-api-docs/ as an example
• Add tour-like functionality to walk the user through the application for the first time
  • Add control to recall the tour on-demand, if needed

GitHub action to be executed on opened PRs as check to validate the OCABundle.json to be added to the repository is - at least - syntactically correct (using a schema validator).

Acceptance Criteria:

• When a PR is opened, the action will check for the existence of a OCABundle.json file
• If the file is in the PR, schema validation will be executed and the check will succeed IF the bundled file matches the schema

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.

Do we need any sort of checksum or anything that signals a consumer (wallet app) that the bundle has been updated, and it needs to re-download the bundle and update the local cache?

Currently the OCA Bundle file in OCABundles/schema/bcgov-digital-trust/student-card and OCABundles/schema/qc_anig_demo/Attestation_numerique_didentite_gouvernemental are not validating against Schema.json file.

"secondary_background_color" needs to be added in Branding Overlay for OCABundles/schema/bcgov-digital-trust/student-card.

"background_image_slice": , "primary_attribute": and "secondary_attribute" needs to be added in Branding Overlay for OCABundles/schema/qc_anig_demo/Attestation_numerique_didentite_gouvernemental to fix the validation.

In order for linking to work, URLs must resolve to a unique value. This will require the Schema ID. Unless we think its a better idea to use the shasum value

Currently, a PR to update an OCABundle must execute the GHA to generate the root level JSON bundles — which is a pain. A better solution would be to have a GHA that does that on each merge. That too is a bit of a pain if the GHA has to push the result back to the protected main branch. I think a good way to resolve this is to have a GHA generate the files and push them to the gh-pages branch such that they get published to the GH Pages along with the OCA Explorer. They would be removed from the main branch.

The impact of this is that all of the software that relies on the current location of the JSON files would have to be updated to use the new location. That’s OK for now — we can manually keep the JSON files up to date on main as well for a short time while the transition is made.

• Update the repo README to reference the docs site
• Update the docs site README to talk about the structure of the data
• Add the OCA Bundles to the docs site to make the paths work
• Verify the links work on the published site
• Add text to the placeholder readme files

In the photo the logo appears blank as the image URL is invalid.

In displaying an OCA Bundle, include in the display the Meta overlay fields in the selected language from the OCA Bundle itself.

The settings for the GH pages need to be disabled for the OCA Explorer on this repo. This needs admin privileges.

We talked about what would be in an AnonCreds "presentation request" OCA Bundle such that the presentation request UX can be improved -- particularly in the areas of:

• Multilingual support
• An overall name/purpose for the presentation request
• A summary of the purpose/justification for the presentation request
• A label/information for the requested attributes, especially for predicates

This issue is written in the form of a spec (as if decisions have been made), but all aspects are open to discussion.

Context

A holder will receive a presentation request from a verifier. Before any UI is presented to the user, the holder's wallet will look into the holder storage to find the credentials that could be used to satisfy the presentation request. Once that is done, the possible response to the presentation request is put on the screen for the user. At that point the state of the flow could be:

• The Holder has exactly one set of credentials that satisfy the all parts of the presentation request.
• The Holder does not have a set of credentials that satisfy all parts of the presentation request.
• The Holder has more than one credential that satisfies some or all of the parts of the presentation request.

Further, for each credential that the Holder has, assume that they also have access to the OCA Bundle associated with that credential. As such, the Holder will already have access to a lot of OCA for Aries Bundles and the data therein. Of course, where there is no credential, or where there is no OCA Bundle, the holder would not have any extra information, other than perhaps the OCA Bundle from the presentation request.

OCA Presentation Request Data

We propose that the following OCA Overlays be included in the OCA Bundle for Presentation Requests. To help in understanding these, please see this set of Presentation Request templates that are currently in the BC Wallet.

• The ID of the presentation request should be used to find the associated OCA Bundle for the presentation request.
• Capture Base:
  • The list of all attributes in "name" and "names", plus the list of the attribute needed for each attribute.
    • The same attribute may be requested in multiple name/names entries.
    • For now, we will ignore that possibility, but keep in mind that we may need to differentiate the attribute names by where they appear in the presentation request.
  • The list of predicates in the form "predicate."
    • This is the item that will NEVER be in the source credential OCA Bundles so it is very important.
    • Like the attributes, the same attribute name could be used in multiple predicates, so we might need to do something about that.
  • As with all Capture Bases, the list of PII elements should be tracked.
• Meta Overlay (multilingual):
  • Name of Presentation Request
  • Description of Presentation Request
  • Justification for Request -- text about why the verifier is asking for the presentation request
• Label Overlay
• Information Overlay

There is no need for the other overlays that are used in OCA for Aries credentials because

• They are needed only when the holder has credentials (with data) to satisfy the request, and at that time, the holder will have the OCA Bundles for the credentials.

• The verifier may not be certain which credentials the holder will use to satisfy the request, so cannot know the data types anyway.

• For predicates, the data is always either a True or False.

• The branding is not needed, as the branding from the source credentials will be used.

  • This is the current suggestion, but should be considered further as we test using these OCA Bundles.

  On Screen Display

  The wallet will display for the user:

  • The name and possibly the description of the presentation request from the user, perhaps also with the Justification for request text inline or available via a popup.
  • For predicates, the label (and optional information popup) from the Presentation Request OCA Bundle
  • For any attributes that for which the holder does not have a credential, the Label (and optional information popup) from the Presentation Request bundle.
  • For all other attributes, the Label (and optional information popup) from the source credential to be used in satisfying the request.
  • For all attributes, a flag/indicator that the data element is sharing PII data, coming from OCA Presentation or OCA Source credential bundles.

Convert the current use of GH Pages to use mkdocs-material (or something equivalent) such that the OCA Explorer is just a part of the overall documentation. The focus should be on the overall OCA functionality, with the OCA Explorer just a part of it. I’m assuming that the OCA Explorer can be embedded into any GH-Pages structure.

Add support in the display of the attributes (see #34 ) to include displaying the photo attribute. Several existing OCA Bundles in the repository already have a photo attribute in them.

Add OCA bundles for:

• AuJrigKQGRLJajKAebTgWu:3:CL:209526:default
• 4xE68b6S5VRFrKMMG1U95M:3:CL:59232:default
• 2K2h7kf8VGTLtfoxJgWazf:2:Member Card:1.5.1
• 63ZiwyeZeazA6AhYRYm2zD:2:Member Card:1.5.1
• XUxBrVSALWHLeycAUhrNr9:2:Member Card:1.5.1
• 2K2h7kf8VGTLtfoxJgWazf:2:student_card:1.0
• 63ZiwyeZeazA6AhYRYm2zD:2:student_card:1.0
• XUxBrVSALWHLeycAUhrNr9:2:student_card:1.0
• 2K2h7kf8VGTLtfoxJgWazf:2:Person:1.0
• 63ZiwyeZeazA6AhYRYm2zD:2:Person:1.0
• XUxBrVSALWHLeycAUhrNr9:2:Person:1.0
• Ui6HA36FvN83cEtmYYHxrn:2:unverified_person:0.1.0
• HTkhhCW1bAXWnxC1u3YVoa:2:unverified_person:0.1.0
• YXCtXE4YhVjULgj5hrk4ML:2:unverified_person:0.1.0
• Mp2pDQqS2eSjNVA7kXc8ut:2:BC VC Pilot Certificate:1.0.1
• 4zBepKVWZcGTzug4X49vAN:2:BC VC Pilot Certificate:1.0.1
• E2h4RUJxyh48PLJ1CtGJrq:2:BC VC Pilot Certificate:1.0.1
• KCxVC8GkKywjhWJnUfCmkW:3:CL:20:Person (QA)
• 7xjfawcnyTUcduWVysLww5:3:CL:28075:Person (SIT)
• RGjWbW1eycP7FrMf4QJvX8:3:CL:13:Person

Currently the esc key allows one to exit the tutorial but it reactivates on a page load. Hitting the esc should be the same as skipping the tutorial.

The GHA to deploy the gh-pages is running on my local fork of the repo. Please update the GHA to only run on the Hyperledger fork.

Add support for displaying attributes as dates, as outlined in the OCA for Aries RFC.

Specifically:

• detect the date types
• for display, convert them to their components parts (e.g. YYYY, MM, DD, HH, MM, SS)
• display them according to the user and language settings of the user.
  • Not sure how to do that in OCA Explorer vs. in the Bifold Wallet -- this may need a further discussion

The Tutorial is restarting/continuing every time I load a new OCA Bundle — even after I say skip. Perhaps this is because I’m using Brave browser with the “Shields Up”. Whatever the reason it is quite intrusive.

I think the tutorial should be in an obvious place at the beginning, and the user can start it when needed vs. Activated automatically, and restarted each time I load a bundle.

I think addressing this is fairly urgent.

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 :)

Some links aren't working on the rendered site -- the issue is the lack of a site_url. Need to have it null (or commented out) when testing locally, but set when running in on gh-pages. Include in the genMkdocs.sh script -- commenting it out when run, uncommented when clean parameter is passed.

In fixing that, check for and clean up any other link issues.

Also fix the Lifecycle badge.

As per the Character Encoding Overlay in the OCA Specification, the per attribute field is unfortunately abbreviated as "attr_character_encoding". This is not aligned with other fields that use the full "attribute" name but until the OCA Specification is updated we will have to align our OCA bundles.

The success of using pure DID and Schema/CredDef identifiers as folder paths stops at Windows. This repo can't be cloned on Windows because of ":"s in the folder names. As such, I'd like to propose a change to how this repository works for Aries Wallets and Agents using it. Here is my proposal:

• Change the folder structure to the following:
  • OCABundles/schema/<publisher>/<schema>, where <publisher> and <schema> are up to the PR submitter.
  • OCABundles/credential/<issuer>/<credential>, where <issuer> and <credential> are up to the PR submitter.
• The README.md or REDIRECT.md file must contain a Markdown table of DID/Identifier pairs that use the OCABundle in the folder. The Markdown table MUST have the following columns:

| DID | Identifier | Ledger | URL |
| ---  | --------- | ------ | --- |
|<did>|<identifier> | [<ledger>] | [<URL for object>] |
|<did>|<identifier> |  [<ledger>] | [<URL for object>] |

• The table may contain multiple identifiers, and the identifiers may be either Schema or CredDef identifiers.
  • The need for the REDIRECT.md file is eliminated with this approach.
  • The ledger and URL values are optional per row and is for human use only.
    • ledger si only for legacy Indy DIDs, and should be in the form <network>[:<instance>] as defined in the did-indy specification for the namespace -- e.g., candy:dev or sovrin.
    • URL is a plain (non-Markdown) link to a ledger browser instance of the object.
• A single file in the root folder called ocabundles.csv is generated by traversing the OCABundles folder and extracting from the markdown table in the README.md files the DIDs and Identifiers.
  • The header for the ocabundles.csv file is: `"did", "identifier", "OCABundlePath"
  • The <OCABundlePath" excludes the server prefix as the client knows it already.
    • E.g, for this repository, the server prefix is: https://raw.githubusercontent.com/bcgov/aries-oca-bundles/main/
  • The ledger and URL columns from the markdown table are NOT included in the file.
  • The csv format is proposed because it is the most compact form of the data, but the data could be in JSON if that is easier for the clients and the compactness is not crucial.
• Multiple identifiers using this are accounted for in generating the file, so all identifiers point directly to the relevant OCABundle for a given DID/Identifier combination.
• A GitHub Action will execute on merge to execute the updates to the ocabundles.csv and produce a PR to update the file.

An option to this approach is to either:

• Add two fields issuer and name to the contents of the file to display where needed, such as in the OCA Explorer.
• Generate a second file ocabundles-extended.csv that adds the two fields issuer and name to the contents of the first file for display where needed. That way the ocabundles.csv is kept as short as possible.

Looking for comments/suggestions on this from @amanji @jcdrouin21 @TelegramSam @cvarjao

Please change the word 'Last' to 'End`

Ensure that image lives in the folder where static assets are served from and that the image src is pointing to the correct location.

When an inline image is used in a branding.json file, the genBundle.sh script in the ./scripts folder generates a JQ utility error. For example, currently in the repo:

• cd OCABundles/schema/bcgov-digital-trust/business-card/
• ../../../../scripts/genBundle.sh -x OCA.xlsx branding.json
• ERROR: line 97: /usr/bin/jq: Argument list too long

The error is coming from this line: ${JQ} ".[].overlays += $(cat ${BCKFILE})" ${OCABUNDLE} > ${TMPOCABUNDLE}

In this -- the ${BCKFILE} is the branding.json file.

This article found by searching for jq: Argument list too long seems to be the solution, but I just don't quite get it. I'm also thinking that if instead of cating the file, it was processed as a file, the jq command might work. Not sure.

Please investigate.

We want the BC Wallet (and other wallets) to use the GH Pages JSON files, so they can be generated vs. pushed to the repo. To do that, the OCA Bundles need to also be published to the GH Pages site. Currently they are not.

Update the genMkdocs script to add the Bundles to the repo.

Update the "Single Card" view in OCA Explorer to list below the card to include all of the attributes (labels, values at least) in the credential. This should mimic the same view in the BC Gov Wallet.

Based on the current design, I suggest limiting the width of the Branding data entry fields so that they use only have the screen space and have the Card attributes carry down beside those fields.

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.