BC Wallet to hold Verifiable Credentials
License: Apache License 2.0
Before running the mobile app it is expected to the following services up and running. (Either locally or hosted somewhere on the internet.)
How BC Wallet Mobile App fits in a larger picture?
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
Refactor the Terms and Conditions screen as per the mockups:
https://xd.adobe.com/view/93c2d0e1-081a-4f62-b358-4e3d9b9a8847-c691/grid/
Review the current iteration of the verified-person user experience to suggest improvements.
We are aiming for WCAG 2.1 AA compliance level
AFJ depends on the Indy SDK to communicate with ledgers. This SDK compiles for Arm architecture but not x86 architecture. It would be good to have it compile for both so that it can run on iOS simulators to speed up development and testing.
User Stories
Background
Credential revocation will be supported in v1.0.
Once an issuer revokes a credential and the ledger is updated, there are three options for the wallet to identify that a credential it holds has been revoked:
Use an existing connection between the holder and the issuer, where the issuer proactively notifies the holder that the credential has been revoked. There is no protocol for this in AIP 1.0 but there is in AIP 2.0, so this is not a workable Wallet v1.0 approach.
Have the wallet poll the ledger at regular intervals, and/or when certain wallet actions are taken. For example, the wallet could poll the ledger once a day, or upon opening / waking.
(Required as part of AIP 1.0 protocols) When a presentation is sent, the verifier agent may inform the wallet that the presentation failed because one or more credentials was identified as revoked. The wallet then updates its registry of credentials to mark the appropriate VCs as revoked, and the user is informed.
(Note: a verifier may still choose to accept a revoked credential as part of a presentation.)
Given the nuances of these three options, Wallet v1.0 will definitely support (3) and likely support (2).
Wireframes:
See Adobe XD file "Collective Digital Wallet UI Design concepts" and go to "credential list" and "credential details" section to see credential UI for revoked credentials.
Summary revocation convo with Ian:
https://docs.google.com/document/d/19MxZrZ519Vkrf-bx9oyRegIt2TpSixM8GN_j7Jxkahk/edit?usp=sharing
Out of Scope:
Issuer: Law Society of BC
Verifier: Court Services
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.
What is the BCLS test environment?
What is the Court Services test environment?
https://github.com/bcgov/law-society-demo/blob/master/docs/Demo.md
User stories
As a holder I want the proof request or credential offer to be presented automatically right after scanning a QR code from a verifier or issuer so that I don't have to manually open the request or offer myself.
Background
User research has observed moments of confusion in between the process of scanning a QR code and receiving a credential offer or proof request. Many factors play into this confusion:
The purpose of this ticket is to linearize the process in receiving a credential or accepting a proof request. Users are taken to a loading screen. This loading screen is when the wallet and the issuer or verifier is making a connection and then sending them either a credential offer or proof request that opens automatically (no notification is received from the perspective of the user. From their perspective, they automatically are taken to the intended flow). This solution removes the confusion of when a flow is complete with loading screens and eliminates the unnecessary selection of a notification to open up the offer or request.
Given Wallet has been setup
When holder scans a QR Code to connect
Then the user is taken to the "Connecting..." screen, AND waits for presentation request
AND then automatically taken to a the "presentation request" screen
AND there is an "Approve" Button
AND there is a "Decline" Button
Given Wallet has been setup
When holder scans a QR Code to connect
Then the user is taken to the "Connecting..." screen, AND waits for a credential offer
AND the automatically taken to a the "credential offer" screen
AND there is a "Accept" Button
AND there is a "Decline" Button
Note: Is there any hint for the purpose of establishing a connection? For Issuing credential, or for verifying credential?
Reference:
https://github.com/hyperledger/aries-rfcs/blob/main/features/0023-did-exchange/README.md
https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0519-goal-codes/README.md
Required Testing Features:
Sauce Labs Subscription:
Estimation:
$249 USD / month (or $ 2988 USD / year)
As a PO/Tester/Early Adopter
I need access to the most recent (cutting edge) Android app (apk)
So that I can test it, or do demos
User stories
Background
Activity History is a historical log of all the actions/transactions that took place. These may include:
Issued/received credentials and by who
Shared/providing credentials with who
Declined credential offer and by who
Declined proof request and by who
Remove credential
Revoked credential
Added connection
Forget connection
Proof request failed
Issued credential failed
Added connection failed
Deferred ID verification sent(?) - QC*
Deferred ID verification accepted - QC*
Deferred ID verification refused - QC*
Questions:
Out of Scope:
Ceremonies
Definition of Ready
Definition of Done (Dev team)
Definition of Review/QA
Definition of Closed (Product Owner)
Team Agreements
Definition on what is a "bug"
Tools
Guiding Principles
Estimation (Story Points)
Epics (do they go to print backlog) vs Tasks vs Stories vs Spike
Labels:
Backlog Management
Glossary:
We want to add some additional functionality to AFJ so that it supports v2 credentials. We'll do this with Timo and Ontario as they both have interested in this also. Initial work will be planning to see who will be doing what.
User flows can be found in this Mural Board: https://app.mural.co/t/digitalidentityandtrust0399/m/digitalidentityandtrust0399/1634147263262/84c4b0f485a1366bd5cd451bed26c833fb14a621?wid=0-1635861117847
Use the connection to exchange generic messages (e.g.: text, picture,...)
User Stories
Wiredframes/mockup: https://xd.adobe.com/view/74b73461-45e5-4f2b-b219-79ffe9c852a7-21e4/
Given the Holder does not have any existing Member Certificate from LSBC in their wallet
When the Holder receives a proof request from a verifier
Then the Holder is presented with a proof request stating that that the credential is "Not available in your wallet"
And a message that states "[verifier name] requested something you don't have available"
And is presented with the "Decline" button
Wireframes: https://xd.adobe.com/view/51cab5b3-ada1-4393-9b8f-1b6820164ccd-0499/
Given the Holder does have an existing Member Certificate from LSBC in their wallet
And it is revoked
When the Holder receives a proof request from a verifier
Then the Holder is presented with a proof request stating that that the credential is "Revoked"
And is presented with the "Decline" button
Wireframes: https://xd.adobe.com/view/51cab5b3-ada1-4393-9b8f-1b6820164ccd-0499/screen/95ca2a5a-1601-4240-8aae-f61eca4cb156
Given the Holder does have an existing Member Certificate from LSBC in their wallet
When the Holder receives a proof request from BCCS
Then the Holder is presented with a proof request with a list of requested proofs
And is presented with the "Approve" and "Decline" buttons
Wireframes: https://xd.adobe.com/view/51cab5b3-ada1-4393-9b8f-1b6820164ccd-0499/screen/a40439e0-2156-4a5e-8375-509ff2447971
Given the Holder has multiple existing Member Certificates from LSBC in their wallet
When the Holder receives a proof request from BCCS
Then the Holder is presented with a proof request with a list of requested proofs
And the most recent Member Certificate is used
And is presented with the "Approve" and "Decline" buttons
Not In Scope
Notes:
Whether biometrics is required (i.e. no app/device PIN fallback)
How we handle a biometrics failure: are they locked out forever? For a time?
If holder verification is needed before presenting or receiving VC
Questions:
Acceptance Criteria:
References:
Includes style guide and dev work to theme the variation build in the BC style.
Workaround:
There is a technique for extracting and processing the machine readable names and transform to human readable format
The work involved to align Ontario and Quebec in their concepts and design to ensure a consistent user experience and to maximize reusable components.
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.
User Stories
Wireframe/Mockup: https://xd.adobe.com/view/3db881d4-e963-42ec-a2c4-6b5ca23862a3-68eb/
How do we group credentials and present them to users that they now have versions of the same credential?
Receiving an updated credential of an existing one
Rework the on-boarding screens and workflow as per the existing mocks.
Wireframes:
BC Branded: https://xd.adobe.com/view/35c82052-5c29-4343-bab0-7dc84cebb129-609b/
Pan-Can Template: https://xd.adobe.com/view/93c2d0e1-081a-4f62-b358-4e3d9b9a8847-c691/
Focuses on application stability and functionality with very small UX improvements (in comparison to other wallets)
In Scope:
Out of Scope:
Acceptance Criteria:
Our goal is to develeope a wallet app capable of holding verifiable credentials that is based on Aries Bifold.
We will base our work of Aries Bifold so that we may leverage the collective comunity development effort to reduce the work of any single team.
We will default to the most simple solution that allows us to acomplish our goals with no imediat long term issues. When the solution no longer works, we will make small iterative changes to overcome said issue as they arise.
Our initial requirements include a release of Aries Bifold, AS-IS, to the Google Play and Apple iTunes store with the following customizations:
ca.bc.gov.BCWalelt; andTo meet our initial requriements we will:
We're not sure if we shoulf fork or just push existing bifold code to our BC Wallet repository. Forking would require us to re-create all our issues and cannot be broken easily in the future.
For the time being we'll continue with our seporate repo with matching history.
We will implement the 4 requirements above and have apply them as a patch during the build process. They will not be a permanent change commited to the up-stream (Hyperledger) repo.
When this strategy is no longer viable we will iterate to the next least complicated and sustanable strategy to solve our issue.
We will continiously pull up-stream changes into our "fork" so that we are in sync.
There is quite a bit of work to solve "the last mile" distribution of the BC Wallet.
We need solve application signing in a secure and reliable way so that the build process can produce an artifact accepted by Apple and Google.
We need to solve automated upload to both iTunes and Google Play so the signed artifact can be distrubted to testers or released for public consumtpion.
Give we're doing infrequent builds and its not overly complicated to do we'll adopt the same process we used for the BC Smart Health Card Wallet PoC: Manual builds on developer laptops. This will let us solve our imediate problem now, while working on the fully automated sultion as needed.
Acceptance Criteria:
Add the On-Boarding screens as per the initial designs:
https://xd.adobe.com/view/93c2d0e1-081a-4f62-b358-4e3d9b9a8847-c691/grid/
User Stories
As a holder I need to be temporarily notified within the app, in an unobtrusive way, when certain processes are successfully completed.
As a holder I need temporary notifications to be easily dismissed at a time of my choosing, so I can ensure I've read the notification before it is removed.
As a holder I need to be notified within the app when there are things that require my attention and action, such as approving a presentation request or receiving an offered credential.
As a holder I need to be notified by my device's OS when there are in-app notifications that require my attention and action but I'm not currently using the wallet app.
As a holder I want notifications outside of the app to take me directly to the in-app notification that needs my attention, so I minimize the number of steps required to take action.
As a holder I need to be able to easily review all the notifications that need my attention and attend to them in an order of my choice, so I can prioritize actions as I see fit.
As a holder I need to browse my notifications in reverse chronological order, so I can make better assessments of what notifications to address first.
As a holder I expect quick access to the most recent notification so I can take quick action on what is likely to be at the forefront of my mind.
As a holder I need to see an informative summary of a notification before I go into its detail and get asked to take action on it.
As a holder I want to be notified when the state of my wallet is notably changed, or changed or used in a way I might not reasonably expect as part of my current actions, so I always feel secure and in control of my wallet.
Background
The user needs to be notified of various wallet activities and requests.
Notifications will take three forms:
Temporary notifications. These are about events that have just occurred, and are for events small enough to not warrant a formal step in a process. For example: "Changes to settings saved √". They may also be used to signpost the user to a permanent notification, for example: "New credential offer". These notification types are likely not reflected in the wallet's history and do not have a home anywhere in the app. They may be implicitly dismissed by a user action that moves away from the current screen.
Appearance: some form of overlay to the screen the user is currently on.
Action type: Dismiss informally (e.g. swipe away or tap 'X'), or single action (e.g. go to screen about a new credential offer).
Queued notifications. These notifications live in a permanent home in the app, and stay there until actively dismissed or interacted with. They may be used to handle VC actions (e.g. agree to receive an issued VC), or to be notified of bigger wallet changes (e.g. VC has been revoked). These are likely to be reflected in the wallet's history.
Appearance: (a) badge indicator in tab bar (number in red circle), (b) summary on app Home Screen, and (c) notification details on app's Notifications screen. Note: (a) and (b) stay visible until the notification is interacted with and completed.
Action type: Dismiss formally (e.g. 'Dismiss' or 'OK') or take action (e.g. 'Review credential').
Push notifications. These notifications are OS-level only, i.e. either iOS or Android. They show up using the OS notification systems, such as an app icon badge and/or on the Lock Screen. They have a direct correlation to the queued notifications: each push notification corresponds to a queued notification.
Appearance: dictated by OS.
Action type: links directly to notifications screen inside app.
Support for credentials and connections from multiple ledgers.
Maybe a developer switch for enabling dev networks
Multi-ledger support has been added to AFJ. AFJ strategy currently checks on all ledgers
Scenarios
During the Aries Mobile Summit call Jason volunteered to create some documentation around the favoured approach of using HTTPS for agents. Steven suggested this location for said change:
https://github.com/hyperledger/aries-rfcs/tree/main/features/0025-didcomm-transports
When issuer and verifiers are in different ledgers
E.g.: Issuer, Schema, and Credential Definition is on CANDY, but verifier is from SOVRIN
Can we we have Schema in one ledger and Credential Definition on another ledger pointing to the same schema?
Just create a repo in the BCGov organization and grand appropriate access.
Auto receive new or updated credential from an issuer
We recognize that AnonCreds are lacking some capabilities that would make them more human and machine consumable. We will be looking into Overlay Capture Architecture as a suitable overlay to augment said credentials.
In the spirit of community well worth through this issue with Ontario & Quebec.
As a holder, I would like my old/revoked credentials to be organized so that I can focus on my current credentials and manage old credentials.
Ability to edit existing auto-presentations
Ability to create new auto-presentations
Whether auto-present is a combo of cred/issuer/verifier, or some subset
Whether an auto-present is auto-deleted if issuer/verifier was connected, and now they're not
Whether an auto-present is auto-deleted if cred is deleted / reissued
Questions:
React
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
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
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.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.