• https://www.w3.org/TR/did-core/#verification-method-revocation

https://github.com/w3c/did-test-suite

#149

Revocation list

Need to implement globally-distributed service for revocation.

Designing revocation APIs that do not depend on submitting the ID of the credential. For example, use a revocation list instead of a query.

It is often useful for an [issuer] [VC-DATA-MODEL] to link to a location where a verifier can check to see if a credential has been revoked.

There are a variety of privacy and performance considerations that are made when designing, publishing, and processing revocation lists. One such privacy consideration happens when there is a one-to-one mapping between a verifiable credential and a URL where the revocation status is published. This type of mapping enables the website that publishes the URL to correlate the holder, time, and verifier when the status is checked.

This could enable the issuer to discover the type of interaction the holder is having with the verifier, such as providing an age verification credential when entering a bar. Being tracked by the issuer of a driver's license when entering an establishment violates a privacy expectation that many people have today.

How to implement Revocation list?

At the most basic level, revocation information for all verifiable credentials issued by an issuer are expressed as simple binary values. The issuer keeps a bitstring list of all verifiable credentials it has issued. Each verifiable credential is associated with a position in the list. If the binary value of the position in the list is 1 (one), the verifiable credential is revoked, if it is 0 (zero) it is not revoked. More https://w3c-ccg.github.io/vc-status-rl-2020/#core-concept

Revocation List 2020 spec by credential community group : https://w3c-ccg.github.io/vc-status-rl-2020/ & https://w3c-ccg.github.io/vc-status-list-2021/

Sample implementation in js is here : https://github.com/digitalbazaar/vc-revocation-list

Sample

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "https://example.com/VP/0987654321",
  "type": ["VerifiablePresentation"],
  "verifiableCredential": [
    {
     "@context": [
       "https://www.w3.org/2018/credentials/v1",
       "https://www.w3.org/2018/credentials/examples/v1"
      ],
      "id": "http://pharma.example.com/credentials/3732",
      "type": ["VerifiableCredential", "PrescriptionCredential"],
      "issuer": "https://pharma.example.com/issuer/4",
      "issuanceDate": "2010-01-01T19:23:24Z",
      "credentialSubject": {
        "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
        "prescription": {....}
      },
      "credentialStatus": {
        "id": "https://pharma.example.com/credentials/status/3#94567",
        "type": "RevocationList2020Status",
        "revocationListIndex": "94567",
        "revocationListCredential": "https://pharma.example.com/credentials/status/3"
      },
      "proof": {....}
    },
    {
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://www.w3.org/2018/credentials/examples/v1"
      ],
      "id": "https://example.com/VC/123456789",
      "type": ["VerifiableCredential", "PrescriptionCredential"],
      "issuer": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "issuanceDate": "2010-01-03T19:53:24Z",
      "credentialSubject": {
        "id": "did:example:76e12ec21ebhyu1f712ebc6f1z2",
        "prescription": {....}
      },
      "proof": {
        "type": "RsaSignature2018",
        "created": "2018-06-17T10:03:48Z",
        "proofPurpose": "assertionMethod",
        "jws": "pYw8XNi1..Cky6Ed=",
        "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21/keys/234"
      }
    }
  ],
  "proof": [{
    "type": "RsaSignature2018",
    "created": "2018-06-18T21:19:10Z",
    "proofPurpose": "authentication",
    "verificationMethod": "did:example:76e12ec21ebhyu1f712ebc6f1z2/keys/2",
    "challenge": "c0ae1c8e-c7e7-469f-b252-86e6a0e7387e",
    "jws": "BavEll0/I1..W3JT24="
  }]
}

Note revocationListIndex and revocationListCredential fields

Sample revocation implemetaation in solidity : https://github.com/uport-project/eip712-claims-experiments/blob/master/contracts/RevocationRegistry.sol

sample of Ontology

notice how credential Hash are being stored on the blockchain network. this is called on-chain attestation.
https://docs.ont.io/decentralized-identity-and-data/ontid/trust-mechanism

A verifiable credential includes the contents of the credential (that would vary depending upon the system), the digital signatures, and blockchain attestation records

How revocation is done?

https://docs.ont.io/decentralized-identity-and-data/ontid/trust-mechanism#revoking-verification

for some reason ontology guys have nnot followeed w3c credentail spec. look at their sample VC here

The issue is, every time we call the create_did with same did then instead of new record, the existing record should be update. I mean it should be like upinsert - if did is not present, then insert otherwise update.

Create a RPC update-did under the module ssi module

Ref #25

https://w3c-ccg.github.io/vc-json-schemas/v1/index.html#versioning_guidelines

Revisions for model v1.0

did:work:abcdefghi;id=17de181feb67447da4e78259d92d0240;version=1.0 <> value
did:work:abcdefghi;id=17de181feb67447da4e78259d92d0240;version=1.1 <> value
did:work:abcdefghi;id=17de181feb67447da4e78259d92d0240;version=1.2 <> value

Fetch a Schema

GET https://hid-node/scchema/did:work:abcdefghi;id=17de181feb67447da4e78259d92d0240;version=1.0

Response
{
...
}

Fetch list of revisions for a particular schema model?

GET https://hid-node/scchema/did:work:abcdefghi;id=17de181feb67447da4e78259d92d0240

Response
did:work:abcdefghi;id=17de181feb67447da4e78259d92d0240;version=1.0
did:work:abcdefghi;id=17de181feb67447da4e78259d92d0240;version=1.1
did:work:abcdefghi;id=17de181feb67447da4e78259d92d0240;version=1.2

• @context is mandatory in DID doc structure. The DID Doc is in JSON-ld format which other systems understand. If we mess with this st, the other system would not recognize our did-doc.

Now, there is concept of Aliasing Keywords in json-ld spec by web3 but it is not for @context. we can have alias for other fields like @type -> type, @id -> id though but not for @context.

I have noticed people have work around to this problem in go lang.

• https://github.com/piprate/json-gold
• https://golangexample.com/simple-json-ld-in-go/

If we send schemaId, it should return the schema

• https://www.tyronzil.com/CRUD-operations/did-deactivate/

Apart from DID and Schema, I found these in Hyperldeger Indy project.

• CLAIM_DEF
• REVOC_REG_DEF

But none of these I could found in w3c spec. So we need to see how other projects are doing like Ceramic and Ontology etc.

https://www.w3.org/TR/did-core/#also-known-as

A DID subject can have multiple identifiers for different purposes, or at different times. The assertion that two or more DIDs (or other types of URI) refer to the same DID subject can be made using the alsoKnownAs property

alsoKnownAs (optional): A list of strings. A DID subject can have multiple identifiers for different purposes, or at different times. The assertion that two or more DIDs refer to the same DID subject can be made using the alsoKnownAs property.

Create a RPC create-did under the module ssi module

• Get count of schema and did
• Get list of schema (pagination)

1. Context https://www.w3.org/ns/did/v1 is common in all didDoc.
2. Use Context https://w3id.org/security/suites/ed25519-2020/v1 if signature type is Ed25519VerificationKey2020 Example

     {
       "id": "did:example:123#z6Mkw94ByR26zMSkNdCUi6FNRsWnc2DFEeDXyBGJ5KTzSWyi",
       "type": "Ed25519VerificationKey2020", // external (property value)
       "controller": "did:example:123",
       "publicKeyMultibase": "zHgo9PAmfeoxHG8Mn2XHXamxnnSwPpkyBHAMNF3VyXJCL"
     }
   

3. Use context https://w3id.org/security/suites/jws-2020/v1 if signature type is JsonWebKey2020. Example

         "id": "did:example:123#key-0",
         "type": "JsonWebKey2020",
         "controller": "did:example:123",
         "publicKeyJwk": {
           "kty": "OKP", // external (property name)
           "crv": "Ed25519", // external (property name)
           "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ" // external (property name)
         }
       }
   

4. List of all supported security suites can be found here https://w3c-ccg.github.io/ld-cryptosuite-registry/

Introduction

The Credential Schema is a document that is used to guarantee the structure, and by extension the semantics, of the set of claims comprising a Verifiable Credential. A shared Credential Schema allows all parties to reference data in a known way.

4 Perspective of schema

1. Author: An author creates a schema as a blueprint for a verifiable credential, specifying the shape and format of the data in such a credential.
2. Issuer: utilize schemas to provide structure and meaning to the data they issue as verifiable credentials.
3. Verifier: A schema always guarantees the structure of a credential. The described structure can be used by the Verifier to understand what data the Holder holds.
4. Holder: Holders, or those who are the subject of credential issuance, can make sense of the data they own -- values -- by viewing it against a schema -- keys.

Credential Schemas are created and made available as immutable objects on a distributed ledger.

** id **

A globally unique identifier to locate the schema on a distributed ledger. This identifier is a Generic DID Parameter Name based upon the author of the schema. For example, if the author had a did like

did:work:abcdefghi

Metadata

• type
• modelVersion
• id
• schemaVersion
• name
• author
• authored

A possible schema ID the author created would have ID such as:

did:work:abcdefghi;id=17de181feb67447da4e78259d92d0240;version=1.0

Example

{
  "type": "https://w3c-ccg.github.io/vc-json-schemas/schema/1.0/schema.json",
  "modelVersion": "1.0",
  "id": "did:work:MDP8AsFhHzhwUvGNuYkX7T;id=06e126d1-fa44-4882-a243-1e326fbe21db;version=1.0",
  "name": "EmailCredentialSchema",
  "author": "did:work:MDP8AsFhHzhwUvGNuYkX7T",
  "authored": "2018-01-01T00:00:00+00:00",
  "schema": {
    "$schema": "http://json-schema.org/draft-07/schema#",
    "description": "Email",
    "type": "object",
    "properties": {
      "emailAddress": {
        "type": "string",
        "format": "email"
      }
    },
    "required": ["emailAddress"],
    "additionalProperties": false
  },
  "proof": {
      "created": "2019-09-27T06:26:11Z",
      "creator": "did:work:MDP8AsFhHzhwUvGNuYkX7T#key-1",
      "nonce": "0efba23d-2987-4441-998e-23a9d9af79f0",
      "signatureValue": "2A7ZF9f9TWMdtgn57Y6dP6RQGs52xg2QdjUESZUuf4J9BUnwwWFNL8vFshQAEQF6ZFBXjYLYNU4hzXNKc3R6y6re",
      "type": "Ed25519VerificationKey2018"
  }
}

Versioning

Revision
The addition or removal of an optional field is what constitutes a REVISION. Read more https://w3c-ccg.github.io/vc-json-schemas/v1/index.html#revision

Model

When a schema breaks historical data we call it a model change. The most common case of a MODEL change is the addition or subtraction of a required field.

An example of this rule is when the additionalProperties field’s value changes. Changing additionalProperties from false to true OR from true to false constitutes a breaking change, necessitating a MODEL increment.

This line was wrritten in https://hyperledger-indy.readthedocs.io/projects/node/en/latest/transactions.html#schema not sure why?

It’s not possible to update an existing schema. So, if the Schema needs to be evolved, a new Schema with a new version or new name needs to be created.

Reference

• https://w3c-ccg.github.io/vc-json-schemas/v1/index.html
• https://lists.w3.org/Archives/Public/public-credentials/2019Oct/att-0008/workday-credential-schemas.pdf
• https://hyperledger-indy.readthedocs.io/projects/node/en/latest/transactions.html#schema
• https://docs.serto.id/docs/main-concepts/schemas/
• https://schemas.serto.id/

Build an Block Explorer UI using the Big Dipper SDK

Link: http://docs.bigdipper.live/

• The objective is to find out what NDID has done.
• What all feature have they implemented at its blockchain node (see this repo - Its a cosmos sdk based SSI implementation)
• Execute end to end flow of NDID with authentcation use case.
• https://ndidplatform.github.io/docs/examples-authen-flow

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

A smart contract or application specific module should call this method at the time of didAuth

Similar to this functionality, implement verify didDoc proof on chain
https://github.com/hypersign-protocol/hs-ssi-sdk/blob/fa6818a41a14748bb21e65cc90ef39a445bd52e3/src/did.ts#L216

https://www.w3.org/TR/did-core/#did-document-properties

1. id: https://www.w3.org/TR/did-core/#did-subject
2. controller: https://www.w3.org/TR/did-core/#did-controller
3. alsoknownus: https://www.w3.org/TR/did-core/#also-known-as
4. verification method: https://www.w3.org/TR/did-core/#verification-methods
5. authenticaion: https://www.w3.org/TR/did-core/#authentication
6. assertion: https://www.w3.org/TR/did-core/#assertion
7. keyagreemetn: https://www.w3.org/TR/did-core/#key-agreement
8. capability invocation: https://www.w3.org/TR/did-core/#capability-invocation
9. capability delegation : https://www.w3.org/TR/did-core/#capability-delegation
10. services : https://www.w3.org/TR/did-core/#services

• https://www.w3.org/TR/did-core/#metadata-structure
• https://w3c.github.io/did-spec-registries/#did-document-metadata
• this is how cheqd have done https://docs.cheqd.io/node/architecture/adr-list/adr-002-cheqd-did-method#diddoc-metadata

{
  "created": "2020-12-20T19:17:47Z",
  "updated": "2020-12-20T19:19:47Z",
  "deactivated": false,
  "versionId": "1B3B00849B4D50E8FCCF50193E35FD6CA5FD4686ED6AD8F847AC8C5E466CFD3E",
}

Implement a RPC to store schema

key : schemaID
value : schemaStr

• A can be updated multiple times.
• There should be a way to track all changes done to the DID

• https://pr-preview.s3.amazonaws.com/w3c/vc-data-model/pull/847.html#differences-between-contexts-types-and-credentialschemas
• w3c/did-spec-registries#418

https://www.w3.org/TR/did-core/#service-properties

• The value linkedDomain come from here
• There are other types of services like DomainLinkageCredential, orgin, linked_dids etc.
• https://identity.foundation/.well-known/did-configuration/v1/

As of now, the only way to register DID in hid-node is through using the following CLI command:

hid-noded tx did create-did [did] [didDocString] [createdAt] --from <user's-public-key>

But, we have to build a wallet UI which would help users to easily register DIDs in the blockchain.

Cosmos has provided us with it's JavaScript SDK: https://github.com/cosmos/cosmjs , which needs to referred while building the wallet.

• https://www.w3.org/TR/did-spec-registries/#blockchainaccountid
• https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-10.md

account_id:        chain_id + ":" + account_address
chain_id:          [:-a-zA-Z0-9]{5,41}
account_address:   [a-zA-Z0-9]{1,64}

https://docs.ont.io/decentralized-identity-and-data/ontid

Given a key I should be able to fetch the schema json

#25

Design and document APIs using JSON-RPC 2.0 and Open Source tools. using https://open-rpc.org/

just like Ethereum JSON RPC spec

https://medium.com/@stevan.blog/using-openrpc-mock-server-to-test-against-an-ethereum-json-rpc-api-50b86b6d02d6
https://playground.open-rpc.org/

How to implement

Add controller property in DID data structure.
https://github.com/hypersign-protocol/hid-node/blob/main/proto/ssi/v1/did.proto#L11

As per spec

When a controller property is present in a DID document, its value expresses one or more DIDs.

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  "controller": "did:example:bcehfew7h32f32h7af3",
}

Any verification methods contained in the DID documents for those DIDs SHOULD be accepted as authoritative, such that proofs that satisfy those verification methods are to be considered equivalent to proofs provided by the DID subject.

Kindly see how cheqd is doing, it looks like data type of controller should be an array, but still get it verified once.

As per cheqd doc

controller (optional): A list of fully qualified DID strings or one string. Contains one or more DIDs who can update this DIDdoc. All DIDs must exist.

"controller": ["did:cheqd:mainnet:N22KY2Dyvmuu2PyyqSFKue"]

Test in different scenario

#45

Public gateways provide the necessary tools for any application (or user) to start reading from and writing to a blockchain immediately, without the need to run the complicated infrastructure of a full node.

These gateways expose a blockchain to “zero clients” (not merely thin clients). These zero clients are willing to trust the public gateway for the convenience of merely connecting to a JSON-RPC, REST or websocket endpoint.

Here zero client is reffered to wallet.

Public gateways are typically backed by a server farm of full nodes. The server farm consists of load-balanced groups of full nodes, that can be scaled horizontally to meet demand of thousands of zero clients.

In addition to providing the basic security of TLS enabled APIs, public gateways are typically enhanced with middleware to enable advanced routing, caching and tuning based on traffic patterns.

Some public gateways are even providing indexing of blockchains in separate data stores so that many of the incoming read requests do not have to read from a full node at all;

Examples:

The examples of public gateways are too numerous to list, but two of the most popular are ConsenSys Media’s Infura and Cloudflare. The popularity of these public gateways are difficult to measure, but MetaMask uses Infura with a zero-client approach, serving over one million installed users.

cost of public gateway is trusting a remote public gateway

https://medium.com/swlh/the-client-server-peer-to-peer-blockchain-application-78cc893cb54c

The smart contract should be able to call this method to verify verifiable presentation sent by user

Similar to this functionality

• https://github.com/hypersign-protocol/hs-ssi-sdk/blob/fa6818a41a14748bb21e65cc90ef39a445bd52e3/src/credential.ts#L223
• https://github.com/hypersign-protocol/hs-ssi-sdk/blob/fa6818a41a14748bb21e65cc90ef39a445bd52e3/src/credential.ts#L184

• https://www.w3.org/TR/did-core/#service-properties

• #61

• Take a look at spec (https://www.w3.org/TR/did-core/#services)

  Services are used in DID documents to express ways of communicating with the DID subject or associated entities

  Due to privacy concerns, revealing public information through services, such as social media accounts, personal websites, and email addresses, is discouraged.

  {
    "service": [{
      "id":"did:example:123#linked-domain",
      "type": "LinkedDomains", 
      "serviceEndpoint": "https://bar.example.com"
    }]
  }
  

• see how cheqd has done

      {
        "id":"did:cheqd:mainnet:N22KY2Dyvmuu2PyyqSFKue#linked-domain",
        "type": "LinkedDomains",
        "serviceEndpoint": "https://bar.example.com"
      }
  

• The value linkedDomain come from here

• There are other types of services like DomainLinkageCredential, orgin, linked_dids etc.

• https://identity.foundation/.well-known/did-configuration/v1/

Tasks:

• Implement the logic for writing []*type.Signer when the VerificationMethod(in old standard, 'PublicKey') of DIdDoc is nil (x/ssi/keeper/verify.go)
• Implement adding fee payer value without the usage of msg.Creator field in func (msg *MsgCreateDID) GetSigners() (x/ssi/types/message_create_did.go)
• Once controller is used in the DIDdoc, implement the commented code which checks for controller length, and appends to []*Signers list in func (msg *DidDocStruct) GetSigners() (x/ssi/types/message_create_did.go)
• Configure the Regex Pattern in create-schema to test for proper version number in Schema ID
• The type used for property field in the message SchemaProperty (file: proto/ssi/v1/schema.proto) needs to be of type that can handle dynamic objects
• Current implementation requires all the DIDs present in the controller field to sign the didDoc. This needs to be changed into the case where either one of the DID Controllers are able to sign the DidDoc (Check VerifySignature() and VerifyIdentitySignature() in x/cheqd/keeper/verify.go)

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

The gRPC server has issues with parsing the url. Following are the discussions which are based around the issue:

1. cosmos/cosmos-sdk#8431 (comment)
2. regen-network/regen-ledger#208

One user suggested the following wrapper, where basically an extra semicolon is appended to the DID url

func wrapMux(h http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        if !strings.HasSuffix(r.URL.Path, "/") && !strings.HasSuffix(r.URL.Path, ":") {
            r.URL.Path += ":"
        }
        h.ServeHTTP(w, r)
    })
}

For now, we can simply send the GET request to DID resolve API by appending a semicolon. But, this needs some research on solving at the gRPC code level

Create a RPC did (Query) under the module ssi module

1. Authentication in DID-Doc is not always a string. It may contain and object of type PublicKey as well.

"authentication": [
    // string
    "did:example:123456789abcdefghi#keys-1",
   // object
    {
      "id": "did:example:123456789abcdefghi#keys-2",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:example:123456789abcdefghi",
      "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],

2. Why there are two types of verification methods mentioned?

• type 1: https://w3c.github.io/did-core/#verification-methods
• type 2: https://www.w3.org/TR/did-spec-registries/#verification-method-properties (looks like we can also have [blockchainAccountId](https://www.w3.org/TR/did-spec-registries/#blockchainaccountid) field)

3. Make sure to update publickey with verificationMethod property

• w3c/did-spec-registries#394 (comment)

4. Make sure to check DID Doc data model properties

• https://www.w3.org/TR/did-core/#did-document-properties

5. publicKeyBase58 is deprecated in the favor of publicKeyMultibase or publicKeyJwk

https://w3c.github.io/did-spec-registries/#publickeybase58:
This property is deprecated in favor of publicKeyMultibase or publicKeyJwk. It's generally expected that this term will still be used in older suites and therefore needs be supported for legacy compatibility, but is expected to not be used for newly defined suites.

6. Make sure to cross check Security problems with json-ld diddoc

https://w3c.github.io/did-imp-guide/#security-problems-with-representation-foreign-entries

It is a common mistake to claim that "JSON-LD is just JSON", and to justify injecting the @context representation-foreign entry into a DID document in the application/did+json representation. This claim however is true only on the syntax level, but wrong and dangerous on the semantic level, especially when security-related properties are involved. In the example above, different consumer implementations are likely to come to different conclusions on how the DID can be controlled.

7. Cross check everythign from Hyperldeger-Indy

https://hackmd.io/@icZC4epNSnqBbYE0hJYseA/S1eUS2BQw

8. DID-Method evaluation using DID rubric

• https://www.w3.org/TR/did-rubric/
• https://docs.google.com/document/d/1jP-76ul0FZ3H8dChqT2hMtlzvL6B3famQbseZQ0AGS8/edit

9. DIDdoc representations JSON or JSON-ld

https://w3c.github.io/did-imp-guide/#benefits

• Implementers are NOT required to support all representations (JSON-LD, JSON, XML, CBOR etc). For example, an implementation might choose to only support application/did+json, and choose not to support application/did+ld+json, application/did+dag+cbor, application/did+xml, application/did+yaml, etc.

• DID methods that support both application/did+ld+json and application/did+json ought to return application/did+json with an @context, because it enables both representations to be used with tooling and standards that support semantics and because the default behavior of JSON processors is to ignore object members that are not understood.

• https://hackmd.io/@icZC4epNSnqBbYE0hJYseA/S1eUS2BQw#JSON-or-JSON-LD

The Indy ledger does not validate the JSON-LD on writing a NYM object to the ledger. It is the responsibility of the DID Controller to ensure that a JSON-LD DIDDoc is valid JSON-LD.

https://www.w3.org/TR/did-core/#verification-method-rotation

A DID controller is an entity that is authorized to make changes to a DID document. The process of authorizing a DID controller is defined by the DID method.

Note that authorization provided by the value of controller is separate from authentication

This is particularly important for key recovery in the case of cryptographic key loss, where the DID subject no longer has access to their keys, or key compromise, where the DID controller's trusted third parties need to override malicious activity by an attacker

• https://www.w3.org/TR/did-core/#did-controller
• https://www.w3.org/TR/did-core/#proving-control-and-binding
• https://www.w3.org/TR/did-core/#the-relationship-between-did-controllers-and-did-subjects

Two scenarios:

• The DID subject is a DID controller:
  • This is the case when an individual or organization creates a DID to self-identify.
• The DID subject is not the DID controller:
  • The second case is when the DID subject is a separate entity from the DID controller.
  • This is the case when, for example, a parent creates and maintains control of a DID for a child;
  • a corporation creates and maintains control of a DID for a subsidiary;
  • or a manufacturer creates and maintains control of a DID for a product, an IoT device, or a digital file.

Some important checks

• The id property value is immutable for the lifetime of the DID document.

• A schema may be updated multiple time,
• There will be various versions of schema that will be maintained
• We should be able see change history of schema

https://www.w3.org/TR/did-core/#verification-methods

Note: Verification method controller(s) and DID controller(s): The semantics of the controller property are the same when the subject of the relationship is the DID document as when the subject of the relationship is a verification method, such as a cryptographic public key. Since a key can't control itself, and the key controller cannot be inferred from the DID document, it is necessary to explicitly express the identity of the controller of the key. The difference is that the value of controller for a verification method is not necessarily a DID controller. DID controllers are expressed using the controller property at the highest level of the DID document (the topmost map in the data model); see § 5.1.2 DID Controller.

https://www.w3.org/TR/did-core/#verification-method-revocation

https://www.w3.org/TR/did-core/#verification-method-properties

https://w3c.github.io/did-imp-guide/#verifiable-timestamps