hypersign-protocol / hid-ssi-js-sdk Goto Github PK

https://www.w3.org/2018/credentials/v1

Use the following package to generate did doc
Did Key driver

wallet management (SSI)

1. SSI wallet should be managed inside SDK
2. SSI wallet's responsibility is not to persist the wallet(SSI)
3. Should be a recovery method and backup method (encrypted by asking a pin, ref: Identity wallet)

Take entity API key as a param to the SDK, if developer has passed, offlinesigner, then use offlineSigner as primary wallet otherwise, use API to do all on chain activities. This was, developer a) dont have to worry about understanding offline signer, b) The dont have to worry about HID wallet since it will be abstracted out with APIs. They only focus on
understanding doc of JS sdk.

This is a sample VC st. we have. But this has a small issue.

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    {
      "hsscheme": "https://ssi.hypermine.in/core/api/v1/schema/sch_3008d429-47fa-41fb-a2b0-6d9c294553d2"
    },
    {
      "name": "hsscheme:name"
    },
    {
      "email": "hsscheme:email"
    }
  ],
  "id": "vc_733a0ecd-889f-47be-978f-7a8702604cb5",
  "type": [
    "VerifiableCredential",
    "Hypersign Auth Credential"
  ],
  "expirationDate": "2022-01-24T08:57:34.975Z",
  "issuanceDate": "2022-01-24T08:57:35.004Z",
  "issuer": "did:hs:6c79a306-742a-4f80-bc66-128102f4cfe5",
  "credentialSubject": {
    "name": "Vishwas Bhushan",
    "email": "[email protected]",
    "id": "did:hs:6431d230-7580-4cb1-b6b5-7590e152b8f2"
  },
  "proof": {
    "type": "Ed25519Signature2018",
    "created": "2022-01-24T08:57:36Z",
    "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..6pPwoRuXvN7k9NODLqtl4cCJiPBM3F5X9KNSeSgwwyUF2kmasq7hGH4lHtz8zlhJBBz7UXeHkXCvSAcA-vIYCA",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:hs:6c79a306-742a-4f80-bc66-128102f4cfe5#z6MktpaZb9jpAu1gmNK9WQwCP8UC8Kj4wheNWbP8s5eF3MG9"
  }
}

Concept

in JSON-LD, ther desired schema location are listed in the @context property's value. Then the type property specifies which particular schema from those location are being used.

For example If you resolve https://www.w3.org/2018/credentials/v1 you will get list of properties and one of them is VerifiableCredential. Now notice the VerifiableCredential is mentioned in the type property of the VC.

Problem

But if you look at this location https://ssi.hypermine.in/core/api/v1/schema/sch_3008d429-47fa-41fb-a2b0-6d9c294553d2, there is no such schema called Hypersign Auth Credential which is being mentioned in the type property.

• Find the did and didDoc st.
• find the schema st.
• Find the credential registry st.
• Find the credential st.

List of wallets

HS-SSI-SDK

• Understand the flow of hs-ssi-sdk
• fix all the test cases
• fix the schema creation transaction

https://learn.mattr.global/tutorials/web-credentials/issue/issue-basic

give support for this credential

{
  "id": "c6667bb7-9442-49a5-bb0b-fce269e97fc6",
  "credential": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      {
        "@vocab": "https://w3id.org/security/undefinedTerm#"
      },
      "https://schema.org"
    ],
    "type": [
      "VerifiableCredential",
      "CourseCredential"
    ],
    "issuer": {
      "id": "did:key:z6MkndAHigYrXNpape7jgaC7jHiWwxzB3chuKUGXJg2b5RSj",
      "name": "tenant"
    },
    "issuanceDate": "2021-07-26T01:05:05.152Z",
    "credentialSubject": {
      "id": "did:key:z6MkfxQU7dy8eKxyHpG267FV23agZQu9zmokd8BprepfHALi",
      "givenName": "Chris",
      "familyName": "Shin",
      "educationalCredentialAwarded": "Certificate Name"
    },
    "proof": {
      "type": "Ed25519Signature2018",
      "created": "2021-07-26T01:05:06Z",
      "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..o6hnrrWpArG8LQz2Ex_u66_BtuPdp3Hkz18nhNdNhJ7J1k_2lmCCwsNdmo-kNFirZdSIMzqO-V3wEjMDphVEAA",
      "proofPurpose": "assertionMethod",
      "verificationMethod": "did:key:z6MkndAHigYrXNpape7jgaC7jHiWwxzB3chuKUGXJg2b5RSj#z6MkndAHigYrXNpape7jgaC7jHiWwxzB3chuKUGXJg2b5RSj"
    }
  },
  "issuanceDate": "2021-07-26T01:05:05.152Z"
}```

https://github.com/digitalbazaar/vc-js/blob/main/test/10-verify.spec.js

w3c universal wallet

universal wallet

Universal Wallet Spec

Blog by dock : https://blog.dock.io/decentralized-identity-foundation/

Wallet Rendering specification by DIF : https://identity.foundation/wallet-rendering/

Trinsic guide
swiss-ssi-group

Currently, no contorller param is being taken in this method, hence by default who ever is creating the did, becomes controller of this did in didDoc.

But what if, this DID is of some object/org/car/entity etc, in that case the controller will be the issuer of the DID. hence we should take controller as param to this method.

vc:hs:devnet:<uuid>
sch:hs:devnet:<uuid>

Selective Disclosure is a privacy featture that VCs can support. There are two recommended ways to achiveve this:

1. Including the absolute minimum number of proeprteos in single VC
2. By using ZKP

More on this can be read in page 140 of ssi book

https://github.com/digitalbazaar/security-document-loader

Extend the uniresolver so that it can resolve hid did. See how cheqd done. You can probably do it by adding our driver into undid resolver

Universal DID resolver

• https://dev.uniresolver.io/
• Add hid driver: https://github.com/decentralized-identity/universal-resolver/blob/main/docs/driver-development.md

Example of cheqd:

• https://learn.cheqd.io/overview/introduction-to-decentralised-identity/what-is-a-decentralised-identifier-did/how-do-you-resolve-a-did

master...signature-scheme-upgrade

Given a proof purpose, it should fetch the verification method

Example

didDoc.getVerificationMethod({proofPurpose: 'authentication'});

According to the wallet specification edv (https://w3c-ccg.github.io/universal-wallet-interop-spec/#interface)

Did creation methods

1. every did (public/private) should be generated deterministically

Public Did

1. If the user wishes to register on the blockchain, it is a public did
2. public did can create a schema

private did

1. If the user wishes not to register on the blockchain, it s a private did
2. private did cannot create a schema

1. We are not asking for any ver method id in signClientSpec() method, whereas in sign() we are asking ver method id, why? is it hardcoded like the fist property? Why to ask for address: string; property, instead we should ask for ver_method_id and then fetch walletaddress out of blockchainaccountid right?

2. Web3 latest version does not work; it works with "web3": "^1.6.0"

3. Method definition for sign() and signClientSpec() return types are differnt. For sign() we have Promise<ISignedDIDDocument>; whereas for signedClientSpec() we have Promise<{ didDocument: Did; signature: string }>: There should be consistency.

4. No explanation for ISignedDIDDocument for sign()

5. Use ether.js in frontend and test as well since most devs uses ether.js

6. Take entity API key as a param to the SDK, if developer has passed, offlinesigner, then use offlineSigner as primary wallet otherwise, use API to do all on chain activities. This was, developer a) dont have to worry about understanding offline signer, b) The dont have to worry about HID wallet since it will be abstracted out with APIs. They only focus on
   understanding doc of JS sdk. #95

7. Explain about verifiable Relationship

8. No explanation about clientSpec at all

9. Explanation of retrun type for generate() is not there. Its just written Promise<object>

10. Explanation of retrun type for sign() is not there. Its just written Promise<ISignedDIDDocument>

11. Explanation of retrun type for verify() is not there. Its just written Promise<object>

12. Explanation of retrun type for resolve() is not there. Its just written Promise<object>

13. Explanation of retrun type for createByClientSpec() is not there. Its just written Promise<object>

14. Explanation for IVerificationRelationships is missing

This is what we are doing

Run the credential.js file in /test1/ssi folder in the repo.

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    {
      "hs": "http://localhost:1317/hypersign-protocol/hidnode/ssi/schema/did:hs:092fe5aa-1e27-4705-9ed2-b389b962cd83;id=7266c2c6-aacd-47d7-83b7-37783894e8e8;version=1.0:"
    },
    {
      "email": "hs:email"
    },
    {
      "name": "hs:name"
    },
    {
      "modelname": "hs:modelname"
    },
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "vc_f85bc5ea-a5ed-4cfa-b668-93797bdf58eb",
  "type": [
    "VerifiableCredential",
    "Email Schema"
  ],
  "expirationDate": "2022-06-15T15:40:19Z",
  "issuanceDate": "2022-06-15T15:40:19Z",
  "issuer": "did:hs:092fe5aa-1e27-4705-9ed2-b389b962cd83",
  "credentialSubject": {
    "email": "[email protected]",
    "name": "Vishwas Anand Bhushan",
    "modelname": "abcd",
    "id": "did:hs:092fe5aa-1e27-4705-9ed2-b389b962cd83"
  },
  "credentialSchema": {
    "id": "did:hs:092fe5aa-1e27-4705-9ed2-b389b962cd83;id=7266c2c6-aacd-47d7-83b7-37783894e8e8;version=1.0",
    "type": "JsonSchemaValidator2018"
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2022-06-15T15:40:19Z",
    "verificationMethod": "did:hs:092fe5aa-1e27-4705-9ed2-b389b962cd83#z3Cn3AXpHMBWBfV14KSBwGqWnBdHEAf6zP74SR4JWuANT",
    "proofPurpose": "assertionMethod",
    "proofValue": "z3BWbCgcZMxT1YeY5ELYfdN7Tfpvfvf3bt2ALtc9rH1hrZTrWjVFmUjWAhLtEXbQFyW358tjxXUirDrJbmQWqhxmo"
  }
}

Note: we are adding schema in the context, which is not everyone is done. I do not know what is right. but if we look at other, they are simply adding schema in credentialSchema property which we also doing. This we had to do because of of digital bazar vc-js lib. Need to check why they enforsed schemaURl in the context.

This is how dock.io 's vc looks like

{
   "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
   ],
   "id": "uuid:0x9b561796d3450eb2673fed26dd9c07192390177ad93e0835bc7a5fbb705d52bc",
   "type": [
      "VerifiableCredential",
      "AlumniCredential"
   ],
   "issuanceDate": "2020-03-18T19:23:24Z",
   "credentialSchema": {
      "id": "blob:dock:1DFdyZkZnALDdCAp7crTRiaCq6KViprTM6kHUQCD8X6VqGPW",
      "type": "JsonSchemaValidator2018"
   },
   "credentialSubject": {
      "id": "did:dock:5GL3xbkr3vfs4qJ94YUHwpVVsPSSAyvJcafHz1wNb5zrSPGi",
      "emailAddress": "[email protected]",
      "alumniOf": "Example University"
   },
   "issuer": "did:dock:5GUBvwnV6UyRWZ7wjsBptSquiSHGr9dXAy8dZYUR9WdjmLUr",
   "proof": {
      "type": "Ed25519Signature2018",
      "created": "2020-04-22T07:50:13Z",
      "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..GBqyaiTMhVt4R5P2bMGcLNJPWEUq7WmGHG7Wc6mKBo9k3vSo7v7sRKwqS8-m0og_ANKcb5m-_YdXC2KMnZwLBg",
      "proofPurpose": "assertionMethod",
      "verificationMethod": "did:dock:5GUBvwnV6UyRWZ7wjsBptSquiSHGr9dXAy8dZYUR9WdjmLUr#keys-1"
   }
}

How can we support schema.org with our credential.

Steps to achieve

1. Get consent from users to store their SSI data
2. Ask for an encryption pin
3. Encrypt the data
4. store in any cloud storage associated with the Kepler publicKey
5. Recover when the user connects Kepler wallet
6. Ask consent, Verify consent
7. Ask for the pin
8. Decrypt the identity data

https://github.com/hypersign-protocol/hs-ssi-sdk/blob/fa6818a41a14748bb21e65cc90ef39a445bd52e3/src/did.ts#L92

• Pass urls in the form of config params at the time of initiating the sdk
• Refactor code properly to create and verifiy did, vc, vp etc.

• Update SDK to incorporate latest changes in hid-node
• Implement credential status #36
• Fix schema #33
• Present Multi Credential in one VP #18 #19
• Slective disclosure #20

All releated codes are present in knowledge hub

VP Req Spec

Note :- for Private did there is no necessary to send entire signed did Doc Read Spec

• We need to some how extend cosmos js (or other cosmos libray) so that other cosmos project start getting SSI feature.
• They should not feel that, they need to throw all their existing code to do so.
• One idea which I have is, imagine all zones has ssi module with them, now fronend conneting with those zone must already have wallet. We can give hs-ssi-sdk to the frontend dev and ask them to use the same wallet to avail ssi feature on your node.
• This way it will an addition of new feature in their project and they need not to delete their existing code.

A VC can contain multiple claims, where each claim is abut a difference credential subject.
For exampple, amarriage certificate VC could contrain one claim about subject Id x and another about subject ID y. The property of first cllaim should be married to subject ID y and of the second claim "married to subject ID x".

• https://learn.cheqd.io/overview/introduction-to-decentralised-identity/what-is-a-verifiable-credential-vc/what-is-a-verifiable-presentation
• https://identity.foundation/presentation-exchange/
• https://github.com/hyperledger/aries-rfcs/blob/main/features/0454-present-proof-v2/README.md

We should also support :

  "@context": ["https://www.w3.org/2018/credentials/v1", "https://schema.org/"]
  "id": "http://example.edu/credentials/332",
  "type": ["VerifiableCredential", "IdentityCredential"],
  "issuer": "https://example.edu/issuers/4",
  "issuanceDate": "2017-02-24T19:73:24Z",
  "credentialSubject": {
    "name": "J. Doe",
    "address": {
      "streetAddress": "10 Rue de Chose",
      "postalCode": "98052",
      "addressLocality": "Paris",
      "addressCountry": "FR"
    },
    "birthDate": "1989-03-15"
    ...
  },
  "proof": { 

 }
}

• Use devNet RPC in for did related services
• Use devNet RPC in for schema services
• Use devNet RPC in for vc services
• Write test cases for did related RPC
• Write test cases for schema related rPC
• Write test cases for vc related rPC

• https://github.com/hypersign-protocol/did-resolver
• https://github.com/decentralized-identity/universal-resolver
• https://uniresolver.io
• https://docknetwork.github.io/sdk/tutorials/tutorial_resolver.html

There may be case where mutiple proofs are need to be added in a VC. For example, a highly confidential or valuable VC might require two directors of the issuing company to sign it.

• Find the did and didDoc st.
• find the schema st.
• Find the credential registry st.
• Find the credential st.

Urls:

• https://certs.dock.io/
• https://docs.api.dock.io/#the-dock-certs-api

A users should not pay for create_did tx fee.

https://github.com/hypersign-protocol/hs-ssi-sdk/blob/52a3069a9a394755f945bece7a11c2ca74c3762a/src/did/didRPC.ts#L44

A DID URL is a network location identifier for a specific resource. It can be used to retrieve things like representations of DID subjects, verification methods, services, specific parts of a DID document, or other resources.

Implement did URL

https://www.w3.org/TR/did-core/#did-url-syntax

A user should be able to query the didDoc using these params

• did query
• did path
• did fragment

Examples

Note:Read page 167 of SSI book