circlefin / verite Goto Github PK

The Verite blog dates seem to be getting overwritten or auto-populated. Today is Jun 14 and notice datestamp from blog written weeks ago. Also note sorting of blog posts on the LHS -- they are not in chronological order.

Do the following as a fast-follow to the already-too-large PR (each as separate PRs)

• Push changes to did-jwt-vc
• Add nested_paths testcase for VC with multiple Cs
• Increase unit test coverage
• Add documentation about Verite conventions (e.g., sample data) and data model clarity (credentials vs attestations)
• Expand out builder improvements
  • update areas of the codebase that can be simplified
  • add documentation
  • but also clarify that use is optional and pluggable at any desired layer (e.g. can reuse parts while pasting in fields). Also can continue to use or intermix json if preferred (examples in verite-credential-utils show how these can be mixed for convenience)

While running the npm run wallet , I'm getting this android bundling error after I downloaded the expo application in andriod phone and after scanning the QR code inside cli .
Following is the error shown on cli

Following is the error on the mobile app

did:pkh meets the guidelines for did method selection we've outlined. Would be great to add support:
https://github.com/w3c-ccg/did-pkh/blob/main/did-pkh-method-draft.md

Verite wallet currently assumes manifest input/output descriptor IDs have a 1:1 mapping to Verifiable Credential types. As there is no guarantee that every Verite SDK users will always assign globally unique input/output descriptor IDs, it should be improved. According to DIF standard, id property just needs to be a string that does not conflict with the id of another output descriptor in the same manifest.

I suggest to use schema property of output descriptor in the format of URI. And will register only output descriptor as the VC type instead of entire manifest which could include more than one output descriptors. This schema registry supports classification of VCs for the purpose of display and exchange in wallet.

Let me know your feedback. @kimdhamilton If you agree, I will make a PR accordingly.

In the Patterns -> Identifier Methods page, there is a link to the w3c on the did-method-key. However, that link is no longer valid. I tried to do a quick cursory search online, and could only find the github repo rather than the working group reference doc.

Currently we assume bitstring method for credential status; make this extensible

Do we need normative or non-normative guidelines on:

• issuer DIDs with more than 1 key
• issuing VCs with a kid in the header when issuer DID has more than 1
• issuer SHOULD provide a kid even if there's only 1 for systems that might fumble the resolution "to default"
  etc?

cc @ra-phael for noticing in our testing VC!

Upon trying to setup the demos with npm run setup from the tip of main [0efdfaf] the install gets into an infinite echo loop. It seems like it is thanks to the npm script build.

• Structure now looks like below
• Also need to snapshot/version supported libraries
• Additional followup
  • credential-fulfillment.ts: repair after making consistent with latest Credential Manifest
  • credential-fulfillment.test.ts: duplicate tests?

  "credential_response": {
    "id": "a30e3b91-fb77-4d22-95fa-871689c322e2",
    "spec_version": "https://identity.foundation/credential-manifest/spec/v1.0.0/",
    "applicant": "did:example:123",
    "manifest_id": "32f54163-7166-48f1-93d8-ff217bdb0653",
    "application_id": "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d",
    "fulfillment": {
      "descriptor_map": [
        {
          "id": "banking_output_2",
          "format": "jwt_vc",
          "path": "$.verifiableCredential[0]"
        },
        {
          "id": "employment_output",
          "format": "ldp_vc",
          "path": "$.verifiableCredential[1]"
        },
        {
          "id": "citizenship_output_1",
          "format": "ldp_vc",
          "path": "$.verifiableCredential[2]"
        }
      ]
    }
  },

From conversation with @bmuller :

https://github.com/centrehq/verite/blob/main/packages/docs/static/definitions/processes/kycaml/0.0.1/usa

occupations and source of funds verification not done by most IDV companies... AML should maybe be an optional additional cred!

Verite wallet has only one part - CredentialDetail component that depends on specific credential types (attestation schemas). Attestation properties are extracted according to the schema for display purpose.

Actually, it is unnecessary and redundant.
The properties are also extracted by a manifest utility function - getDisplayProperties in a schema-agnostic way.
And since PR #458 (this is a super superb update, congrats 🎉) allowed user-defined types of credentials, I recommend removing the dependency on schemata.

E.g. verify-a-verifiable-credential.md

This issue to help track and remember to update the docs where there is currently a placeholder. In the Patterns -> Schema section, there's a placeholder that says:

TODO: LINK TO BITSTRING DOC

This issue is to track the updating of that part of the docs with the relevant link.

Need better abstractions for did methods. As mentioned in #378, also add support for other methods. (did:ion as well?)

• APIs of verite library (core functions, even if very high-level)
• function to test VC verification in isolation (for testing) - is this in the underlying veramo VC-JWT library?

Names like "issuer", "verifier" are confusing. The current file grouping would make more sense as something like this, because the functions are intended to be called by both sides (issuer/holder)

• issuer => issue
• verifier => verify

Also open to different groupings.

There is some reuse so we may also need something like common and/or payloads?

for blog post that went up today

Previously created an issue in did-jwt-vc where verifyVP was not verifying enclosed VCs: decentralized-identity/did-jwt-vc#92. It was closed as by-design.

We are verifying enclosed VCs in Verite, but here and more generally in the VC ecosystem, VC/VP verification logic may be spread out and not follow consistent patterns

Clarify, possibly using the framework started (in vc-http-api)

Considerations:

• Revisit/revise 3V, also in the context of the DIF specs, which spread some of the related data model aspects to Credential Manifests, etc (fitness for purpose, etc)
• Determine how we should clarify in Verite docs
• Determine whether a WIP standard-track proposal makes sense (in DIF, etc)
• Determine impacts to libraries — do we need better encapsulation of logic? More generally, how would we recommend improving/clarifying existing VC verification libraries (including did-jwt-vc, json-ld, transmute libraries)

Reported: In credentialStatus , there is a type field. In Centre document it is RevocationList2021Status. But VC Status List and VC-Data-Model documents name it differently as StatusList2021Entry and CredentialStatusList2017. Should we use RevocationList2021Status onward?

Recommended fix: Update to use the latest one in StatusList2021Entry

This issue represents my review of the entire monorepo and documentation that I'd personally like to see and will likely work on. It is ongoing, and I will edit this description as I continue to dive into the code.

No action is necessary from anyone else, but questions and feedback are always welcome :)

Notes:

• Type Documentation - working with Typescript is great when you have libraries that provided defined types...IF those libraries make it clear what all the available types are and when you use them. To avoid developers accidentally writing their own types when the core library has them already, we should document these types.
• @verity/core documentation - This is an over-arching bullet point, but we need an entry point to start documenting the @verity/core package.
• Tutorials - start to finish walkthrough of building an issuer app
• Tutorials - start to finish walkthrough of building a verifier
• Tutorials - start to finish walkthrough of building a credential wallet
• Docs on building a credential manifest from scratch (@verity/core supports KYC and credit score)
• Update verifier docs (I couldn't get verification working with the existing docs)
• In issuance documentation/tutorial, clarify that the verifiable credential should be the decoded value not the JWT.

Related to #437, determine if we need to lock to specific spec versions

In advance of the VC 2.0, a DIF working group has focused on harmonizing the VC-JWT format. They've developed a test suite and attempted to prove interoperability with the LD Proof suite that also uses JWS.

This is the test suite: https://github.com/decentralized-identity/JWS-Test-Suite

This work item involves:

• Updating the VC signatures to use harmonized VC-JWT signatures
• Bonus points for adding this to the implementations in the test suite
• Even more bonus points for fixing the did-jwt-vc library (which we currently use). Tracked here: decentralized-identity/JWS-Test-Suite#39

@OR13 would be delighted to answer any questions you have

Hi team,
I cloned the github repo https://github.com/centrehq/verite
and followed the instructions as given in the readme file.
It says it is required to use NodeJS14 and npm7 but Node14 comes with a default combination with npm6 and I can't use npm7 with Node14. I have also used higher versions of Node i.e above 14 in combination with npm7 and above. That also didn't work.
I'll be highly obliged if you suggest anything to me anything, so that I can run the sample.
I've attached the error screenshot too
Thanks.

Hi,

I'm trying to get the demo-issuer code up and running - I have made some changes so it uses my IP address rather than localhost, and I can successfully scan the QR code with the mobile wallet app and receive the manifest - but "Request" always results in an error in the console on the server side "TypeError: bad_key: Invalid private key format" - I have repeated the same test on my laptop, using the simulation buttons in the browser page, but - same error.

Just wondering if this is expected to work, or if I have missed a setup step along the way?

Thanks,
Iain

Note additional of applicant property as well as JWT embeds.
https://identity.foundation/credential-manifest/#embed-target-examples

In some areas of the docs, we've conflated roles of verifier service vs verifier frontend. See here for example: /packages/docs/verite/quick_start.md

Do an audit and fix to help avoid confusion

#346 followup:

• Ensure VP verification this verifies all nested credentials
• also accept PresentationPayload?

On any fresh install of the verite library from NPM, when I try to use the library, I get the error:

Error: Cannot find module 'tslib'

Manually installing the tslib dependency solves the problem, but it looks like that's a dependency that might need to be installed as part of verite's installation process?

https://docs.centre.io/verite/developers/issue-a-verifiable-credential

I cannot scroll content on chrome Version 98.0.4758.102 (Official Build) (x86_64) / macOS

also from conversation with @bmuller :

https://github.com/centrehq/verite/blob/main/packages/docs/static/definitions/processes/kycaml/0.0.1/generic--usa-legal_person#L26

new process object for issuers that don't do that check or just nix it?