The current controller implementation does validate that it can connect on startup but the error is not well shown in the console.
This issue is to:
Add exception level log when the connection fails.
Add a sleep of 10 before starting the controller to ensure the agent is fully started before it attempts the connection.
Color the console response red from node when it fails.

• public site and email do not display correct url.
• admin email isn't on the email address (for more information email [email protected])
• correct the birthdate entry component to make it desktop friendly in the enter claims
• finish the expired / request new verification email route in the public site.
• Test with other (non-github) login types on the public app claims entry page.
• resending e-mail verifications fails (this is fixed on another branch)

We would like to build an Identity Kit that allows individuals to provide one-on-one demos of how we can enable government-issued verifiable credentials that citizens can use for their own purposes.

A design has been put forth, discussed and whiteboard'd. The approach and requirements will be added as tickets associated with this epic.

Goal is to complete this in two weeks.

I think the von-network link is meant to be https://github.com/bcgov/von-network ? current link is 404.

Some of the parameters used by the deployed web applications are currently not parametrized correctly (see #45). We should be instead using configurations that can be injected at runtime.

Consider using the config map currently holding the keycloak config to add new parameters, and store the configuration in the state service (or similar) after the application has started.

Please update the initialization of the Identity Kit issuer to use the existing BC Gov "verified person" schema that is on the test ledger by default, and provide some brief instructions on what would have to change from them to define and use their own schema. Include that if they use their own schema that makes changes to attributes of the schema, that they will also have to update the Issuer form. It is out of scope of this change to do anything other than say to them - "hey, you need to change the form". No need to provide guidance on how.

Please create the verifiable credential Issuer app as described here. Note the logic after the participant has been authenticated, as he or she may not be given access to the main demo based on the time limited GUID and the "ActiveYN" flag. Depending on why the participant is not given access results in a different flow for the user.

Demo feedback

1. Update the fields on the issue credential sign-up to include the specific verified person credential schema values
2. Split out the issue credential panes so that there are two cards on the landing page. 1 card with all the values that were acquired from the login process. The 2nd will be the values that must be entered to match the issuing credential schema.
3. Change the title of the verified person schema.
4. Add disclaimer on the keycloak page (specifically the text should be lorem ipsum...)
5. Add disclaimer box on the issue credential page (specifically the text should be a lorem ipsum...)

Currently, we use the data from the OIDC token to populate claims in the credential we will issue to the issuer via the ID Kit Issuer app. There are two special cases that we need to deal with:

• When the OIDC token is for the user "wa-admin" or "wa-user", instead of using data from the OIDC token, grab and map the data we have from the Admin app for the user into the credential-to-be claims.
• Likewise, when there is no OIDC token (because we are just using the time-limited GUID to control access), grab and map the data we have from the Admin app for the user into the credential-to-be claims.

Nice to have: In this scenario, when the data for the credential comes from the Admin data, it would be nice to have an config flag (env variable) that indicates if the pre-populated data can be edited or not. I'm not certain of there is a need for this, so minimal effort on this part.

If the agent has an API key protecting it's admin endpoint, the controller should add an x-api-key header containing the value of the key to each call made to the agent.

Use a desktop friendly date picker for birthdate on the public app (probably will used a masked input or tri-input setup)

Add a open in app button for streetcred on the QR code screen of the public site.

Please update the address fields of the form to use autocomplete. An example of it's use is here. We use the demo token from Canada Post for these proof of concepts, and that token is about 26 lines above the referenced line.

We'd like this done ASAP.

Per the plan outlined here, create a minimal version of the ID Kit Admin that eliminates the user management User Interface and just allows the user to add users, enter minimal information (just an email address), generates a time-limited GUID (persisting it) and then emailing it to the user. The GUID enables the invited participant to access the Issuer app to get a credential.

Add the text "Disclaimer: " after the checkbox and in front of the current string on the "Preview Credential" screen of the IKP user app.

We'd like the Id Kit issuer to be configured to be used in one of three ways:

• Integrated with Keycloak + the time GUID
• Integrated with OIDC + the time GUID
• No OIDC, just the time check on the GUID

If we can only do one of the first two, please implement the OIDC directly, bypassing Keycloak, and we'll figure out how to do the BC deployment separately, just as all other jurisdictions will have to do.

When there is no OIDC IdP used, hence no OIDC token, please update the Issuer screen to get the email address from the Id Kit database.

Another options is to go with the ID Kit only having the latter (no OIDC), plus instructions about how to add OIDC.

For my [email protected] invitation the link is expired even though I have my credential.

This may be a hold-over from the fact that my invite was made early in the development cycle when features were being coded and deplyed.

Will have to remove or make the 5 second wait on issuing the credential in issues.controller.ts on the post '/' route.

Add integration with BC Services Card

See #46

We need to add some documentation that is targeted to a developer that wants to play with the identity kit.

@watkinspd - it would be good to have a personna that we are targeting with this. Someone at 2Keys or Nova Scotia?

For the kit, the setup there should be instructions on either how to use the BCovrin Test network for playing so that they can use the Streetcred agent, or some other agent that they can use for playing. Not quite sure if you can use anything else to test this.

Documentation:

• Overview/purpose of the demo
• Pointer to verifiable credentials base documentation - perhaps the edX we created, but likely something shorter
• How to run the live demo.
• How to run the demo on docker locally (or Play with VON)
• How to update - typical things to be done

The identity kit issuance is not working right now. It does not proceed on the Streetcred app after the Credential Offer is accepted by the user.

On the web app side, all appears good - everything appears to have worked and the intended redirections occure. However, on the Streetcred/Mobile App side, no credential is ever received. I'm on the 1.6.2 version that is in the App Store.

It's been like this for a while.

Add an environment variable, on by default that indicates that the email should not be sent. When that variable is set, suggest having a flow like this:

• Display a message "Email is not configured to be sent from this instance of the Identity Kit. Click "View" to see the email text that would have been sent, or Cancel to return to the administrator application."

If they click "View" either show the email in a window or open a new tab with the text of the email.

Let me know if that is difficult and there are other easier ways to handle this. We could have another option that says "...been sent, "Instructions" for information on configuring email, or Cancel...". The instructions link would go to an MD file in the repo.

Sit down the with the Product Owner (@watkinspd) to review the current flow and interface.

Per @sukalpomitra the invitation from the issuer is not a URI - it's just the encoded invitation. That seems to work fine with the Streetcred agent, but is not correct. Please verify and if that is correct, adjust and verify it still works with Streetcred and with OSMA.

Example URI: http://iiwbook.vonx.io?c_i=gsgsgsgsg

What the issuer sends: gsgsgsgsg

Where gsgsgsgsg is the encoded invitation JSON.

We will need a simple "Hello World" service that demonstrates using a verified person credential. For example:

As a user with a verified person credential I want to experience how a digtial service requests my credential, how I receive the notice and authorize/reject providing it, and see that if I provide it, that it is received by the service that requested it.

As a developer I want to have a working code sample that shows the bare minimum that I need to do in order to request and receive a verified person credential so that I can jump-start my effort to create a proof of concept digital service without being bothered by the complexity of issuing credentials, or making a personal agent.

So:
identity-kit-hello.pathfinder.gov.bc.ca
It makes a request for verified person via the QR code and the clickable button
User scans QR with agent
identity-kit-hello starts runing the progress screen
Request is received
Credential is provided
identity-kit-hello shows that credential is received and shows the data it received
identity-kit-hello.pathfinder.gov.bc.ca shows progress is complete

Create an approver app as described here, including the picture and the flow of the approval process.

At some point an API around the database will be needed so that both the approver and issuer apps can get at the data as they need to.

The emails can be static for now, but eventually we'll add a template capability so that we can customize them based on the user data record.

As a government that does not have a login service, I need an issuing service that simulates the role of a government employee acting as an identity proofing and registration agent for the verifiable credential so that I can easily participate in the POC.

For example: the gov of x does not have any form of digital ID to leverage for the POC. They need to demonstrate how an authorized person in their organization could directly register a person or the POC and issue them with a POC digital ID for verifiable person.

A suggestion would be to clone identity-kit-admin and change the invitation making screens so that it allows an admin to enter in all of the data needed for a verifiable person credential. The resultant email link for the invitation would simply display the QR code and could be scanned with the agent. The admin is therefore showing the role of a person who is conducting an identity proofing and registration step - albeit for a proof of concept demo issuer.

Please deploy a new instance of a site that is similar to IIWBook but is for the DIACC Identity Kit. Users will go to this site after being issued their verifiedPerson credential.

Differences from IIWBook:

1. New Title/Wording on the front.
2. Display the QR code on the first page for the proof.
3. Use the verifiedPerson schema in the restrictions for the credential.
   • Do not ask for the email address, locality or street claims.
4. New wording on the "Here's what's happening..." screen.
5. After the verification of the proof, stop the processing - no IIWBook backend and issuance of a new credential.
6. Display a message "Hello " and then list the claims collected in the proof.

That's the end of the demo. No need to create all the extra items.

If we are able to do this in parallel with the work ongoing with the Admin and User apps for the IKP, it's OK to just use the verified email credential for the proof, and we'll update the code/config to use the other credential later.

Nice To Haves, but we need this fast:

• use the 1.0 Present Proof protocol instead of the v0.1 proof
• implement this as a new code base that is intended to be a starter kit for more deployments.
• use the aries-cloudcontroller-node instead of IIWBook
  • using this vs. IIWBook probably depends on who builds this.

I made a few edits to the email instructions.

As an admin I need to be able to outright delete an invited user in the event that wires got crossed and the person needs to re-start the whole process.

Example: The wrong person made use of the invite (such as an admin doing a demo and using the wrong invite URL), or the user wants to know that they have been entirely removed from the issuing service.

Please add additional documentation to the Id Kit README that covers the ngrok part of the local testing, so that people can do a full run.

Alternatively, define how to do it with ACA-Py as I think Sean was doing (?), but either way, we have to enable people to be able to run an end-to-end example on their workstation.

As a user I need to click on demo services using the same laptop or tablet that I was using for the issuing flow and know that a demo service will not inherit the login I may have used during issuing.

example: I click on invite link, login with github, complete the issuing flow, then click on law-society demo and it skips the prompt for verifiable credentials because github is a login option - I wind up in a tangle.

In the admin interface, added a new user. Clicked "Submit". Nothing happened - I think there used to be a modal pop-up about "add another?/Return to list". It's not coming up anymore. Hit submit again (Did I not click the button?) and when I went back to the list, I had 3 entries.

Expected to know I had added a user and not be able to click the submit multiple times to create multiples of the same user.

Please fix.

Provide in the instructions what to do if the user does not have an email service while testing. As needed, add code so the email does not send at all under some conditions, and ideally, some instructions on how a person could, for example, use their google account for sending messages while testing.

Alternatively for the latter case (developing and needing to see the email for testing), if possible (and easy) have an option to allow the email message to popup a window with the text of the email, so people can see the text without having to have an SMTP service available.

This came up as an issue by Lucas Tétreault of vivvo.

The Identity Kit was roughed out as an idea and implemented quite rapidly. It has been successful in it's initial role, but it needs a little bit of work as we use it in more use cases.

From a use case perspective, we implemented a single flow -- a BC-based administrator invites a user who receives an email, clicks on a link and is taken to an app to receive a verifiable credential. Now, we want to make the Starter Kit a redeployable component that can be used by multiple jurisdictions as a proof of concept. Further, we want such jurisdictions to be able to evolve the toolkit for their own use. For example, the current BC instance would be an artifact of the Starter Kit, rather than the basis, equal to a Quebec and Nova Scotia instance.

The effort:

• Walk through the flow with the product owner and some users to settle on a flow
• Walk through the user interface with the product owner to make the apps/email easier to use
• Make the overall kit easier to revise for other jurisdictions
  • Work with the product owner to define "easier"

Nova Scotia would like to have it's own instance of the full identity kit - including the admin and issuer web apps.

Please deploy new versions of the apps for Nova Scotia either in the same OpenShift projects or in a separate one. For now, the sites should be identical (albeit with different databases, URLs and associated configurations), but we will make some UI updates for the Nova Scotia instance. Likewise, use a variation on the current URLs for the deployment, but expect that we will acquire a DNS name for the deployment and use that for the production sites.

I expect that this will be needed within the next three weeks.

Is it possible to change the name used on the objects and notifications that winf up in StreerCred so they use the label BCGov-POC-Issuer instead of identity-kit-agent?https://app.zenhub.com/files/219878732/42b0d59e-b074-4d37-8efe-e9dc818e3be8/download

Since we can't alter the Keycloak page itself, we need to display a page before the Keycloak page with the disclaimer text. The page should display the following based on different conditions:

No valid guid

Means:

• no guid
• guid not in the database
• guid in the database but marked as "deactivated"

Display a generic page with no details of where you are.

Valid but expired guid

Display a message "Your email for accessing this service has expired. Click here to request another email with an active link"

On click, send an email to Peter Watkins saying who has requested a resend of the token (if you can...does the api allow that?). If not, add a field to enter an email address to the message above.

After the email has been sent, display a "Your request has been sent." message.

Valid, not expired guid

Display a title "DIACC Identity Kit Proof of Concept" and text showing:

• checkbox
• "Disclaimer: Loren ipsun..."
• A Submit button that is activated with the checkbox is sent.

On submit, go to the Keycloak screen.

Updated schema.

Fix tracker so that if the user doesn't have an _id it will re-direct the user to re-use their issue cred

Update webhook to respond to connections in a "response" state.

Create a new verified person schema version without email address and start issuing credentials with that new schema for BC and NS (so new cred defs), and update the identity kit demo to use.

Ideally, keep accepting the old schema and accept the new one as well. Eventually we'll get rid of both.

Make sure that with the BC Services Card flow there is no data to be altered.

Network Policies are required for deployments to work in newly-provisioned OpenShift namespaces.

Relates to #101, #105

Clean up Jenkinsfile(s) using the following as a reference;

• https://github.com/bcgov/jag-cullencommission/blob/master/jenkins/website/Jenkinsfile
• https://github.com/bcgov/jag-cullencommission/blob/master/jenkins/config.groovy
• https://github.com/bcgov/jag-cullencommission/tree/master/jenkins

Here is my first cut feedback on the Admin UI:

1. I don't yet know what the various status values are, so need that explained. The split between "invited" and "confirmed" is unclear. For now I think we just have one list, or perhaps, a list of active vs. deactivated users.
2. When adding:
   1. When leaving the email blank, the error message is "username invalid" - should be at least "email invalid".
   2. Not a fan of the Jurisdiction popup. Please make it inline like Authentication.
   3. Preset the Jurisdiction to BC and the Authentication to GitHub.
   4. Not previously requested but NTH - an optional "Name" field
3. On the submit screen:
   1. Don't show the URL on the screen. I'm guessing that's debugging stuff left in?
   2. The "Expiry" field should be a date/time and the value should be 24 hours from now.
   3. I assume that the "expired" (whatever is impacted by the "revoked") is not displayed but is part of the status?
4. The email didn't get sent. I assume that is expected? I'd like to see the email ASAP so that we can write the copy for it.

We would like to make the following use case possible with the Identity Kit:

• In the admin interface, an option allows the Admin to manually enter all of the claims information about the user being added.
  • Imagine this being used, for example, a driver's license in person session.
  • Since this is PII, we have to be concerned about the storage of the data and access to it.
• The link in the email that is sent to the user provides a reference (database ID) to the full set of claims data.
• Information in the email is sufficient to let the user log into the issuer
  • Not sure how to do this - to both protect access to the issuer AND to allow this type of issuer directly into it.
  • Perhaps the link in the email goes to an unprotected URL (having a valid GUID on the URL is the only protection) and on validation of the GUID, we immediately display the QR code to initiate the issuance process - e.g. the same as the email verification app.

When running ./manage start-dev, two containers (wa-public-dev_1, wa-admin-dev_1) had the following errors and failed to start:

wa-admin-dev_1             | 
wa-admin-dev_1             | > [email protected] start-docker /usr/src/wa-admin
wa-admin-dev_1             | > ng serve --host 0.0.0.0 --port 4250 --poll 2000
wa-admin-dev_1             | 
wa-admin-dev_1             | sh: 1: ng: not found
wa-admin-dev_1             | npm ERR! code ELIFECYCLE
wa-admin-dev_1             | npm ERR! syscall spawn
wa-admin-dev_1             | npm ERR! file sh
wa-admin-dev_1             | npm ERR! errno ENOENT
wa-admin-dev_1             | npm ERR! [email protected] start-docker: `ng serve --host 0.0.0.0 --port 4250 --poll 2000`
wa-admin-dev_1             | npm ERR! spawn ENOENT
wa-admin-dev_1             | npm ERR! 
wa-admin-dev_1             | npm ERR! Failed at the [email protected] start-docker script.
wa-admin-dev_1             | npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
wa-admin-dev_1             | npm WARN Local package.json exists, but node_modules missing, did you mean to install?
wa-admin-dev_1             | 
wa-admin-dev_1             | npm ERR! A complete log of this run can be found in:
wa-admin-dev_1             | npm ERR!     /root/.npm/_logs/2019-11-13T23_14_54_182Z-debug.log

As well this error occurred:

identity-controller-dev_1  | 
identity-controller-dev_1  | > [email protected] start /usr/src/controller
identity-controller-dev_1  | > nodemon
identity-controller-dev_1  | 
identity-controller-dev_1  | sh: 1: nodemon: not found
identity-controller-dev_1  | npm ERR! code ELIFECYCLE
identity-controller-dev_1  | npm ERR! syscall spawn
identity-controller-dev_1  | npm ERR! file sh
identity-controller-dev_1  | npm ERR! errno ENOENT
identity-controller-dev_1  | npm ERR! [email protected] start: `nodemon`
identity-controller-dev_1  | npm ERR! spawn ENOENT
identity-controller-dev_1  | npm ERR! 
identity-controller-dev_1  | npm ERR! Failed at the [email protected] start script.
identity-controller-dev_1  | npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
identity-controller-dev_1  | npm WARN Local package.json exists, but node_modules missing, did you mean to install?
identity-controller-dev_1  | 
identity-controller-dev_1  | npm ERR! A complete log of this run can be found in:
identity-controller-dev_1  | npm ERR!     /root/.npm/_logs/2019-11-13T23_14_57_301Z-debug.log
identity-kit_wa-public-dev_1 exited with code 1
identity-kit_identity-controller-dev_1 exited with code 1

See the drawing/flow in the Approver and Issuer apps on the setup of the keycloak protections needed for the two apps - document here.

Please add the keycloak protections to the apps and document how to manage the configurations, including the whitelist for the approvers app.