Skip to content

Latest commit

 

History

History
171 lines (113 loc) · 6.6 KB

DID-Method-NEAR.md

File metadata and controls

171 lines (113 loc) · 6.6 KB
Raw

NEAR DID Method Specification

Summary

Decentralized identifiers (DIDs) are a new type of identifiers that enables verifiable, self-sovereign digital identity. This NEAR DID method specification describes a new DID method, that is, NEAR DID and defines how NEAR blockchain stores NEAR DIDs and their corresponding NEAR DID documents, and how to do CRUD operations on NEAR DID documents.

This specification conforms to the requirements specified in the DIDs specification currently published by the W3C Credentials Community Group.

Motivation

NEAR uses readable account identifiers instead of a hash of a public key, and the accounts have some DID features, but not all. We have developed this specification to define a new DID method for hosting DIDs on the NEAR blockchain, also referred to as NEAR DID, and facilitate developers to work with related contracts.

NEAR DID Method Name

The namestring that shall identify this DID method is: near.

A DID that uses this method MUST begin with the following prefix: did:near. Per this DID specification, this string MUST be in lowercase.

The remainder of the DID, after the prefix, is its namespace-specific identifier specified below.

Namespace Specific Identifier (NSI)

The namespace specific identifier of NEAR DID is defined by the following ABNF:

near-did   = "did:near:" near-specific-idstring
near-specific-idstring = *( 1*idchar ".") 2*idchar
idchar    = %x30-39 / %x61-7A / "-" / "_"

The maximum length of near-specific-idstring is 64.

Example

A valid NEAR DID might be:

did:near:alice.near

CRUD Operations

The following section outlines the DID operations for the did:near method.

NEAR DIDs reside on the NEAR blockchain, and are mananged via the NEAR DID management smart contract.

For the sake of convenience, we refer to the NEAR DID management smart contract as 'the registry'.

Create (Register)

A Near account is needed to create a new NEAR DID,

NEAR DID creation is done by sending a transaction to the registry invoking the following method:

reg_did_using_account()

Upon invoking this method, a new NEAR DID is generated by concatenating "did:near:" and the NEAR account identifier.

The public key of the Near account's access key that was used to sign the transaction will be inserted into the publicKey property in the valid form and will be referred to in the authentication property.

This method will return true if the new NEAR DID is registered successfully.

Read (Resolve)

NEAR DID's associated DID document can be looked up by invoking the getDocument method of the registry.

To ensure the smart contract invocation result is trustworthy, the client could query a certain number of nodes and then compare the return values.

The interface method for resolving a NEAR DID document is defined as follows:

get_document()

Besides this full-fledged resolver, the NEAR blockchain provides other simple resolvers, such as fetching the authentication property.

NEAR DID Document Example

{
  "@context": ["https://www.w3.org/ns/did/v1",
			   "https://www.near.org/did/v1"
  ],
  "id": "did:near:alice.near",
  "publicKey": [
	{
	  "id": "did:near:alice.near#keys-1",
	  "type": "EcdsaSecp256k1VerificationKey2019",
	  "controller": "did:near:alice.near",
	  "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
	}
  ],
  "authentication": [
	"did:near:alice.near#keys-1"
  ]
}

Update (Replace)

To update a NEAR DID document, the corresponding NEAR DID subject just need to invoke relevant functions.

For instance, the NEAR DID subject can invoke the addController method to add a delegate which has the authorization to insert a new verification method into the authentication property of the delegated NEAR DID.

The interface method for adding a delegate NEAR DID is defined as follows:

add_controller(delegate: String)

The delegate parameter specifies the to-be-added controller.

Similarly, the interface method for removing a delegate NEAR DID is defined as follows:

remove_controller(delegate: String)

The delegate parameter specifies the to-be-removed controller.

We do not provide the full list of supported update methods here and will provide specific documentation which lists all of the related APIs.

Delete (Revoke)

To delete (or deactivate) a NEAR DID, it suffices to remove all the verification methods from its associated DID document. In this case, there is no authentication method that can be used to authenticate the holder's identity.

The interface method for deactivating a NEAR DID document is defined as follows:

deactivate_did(did: String)

The did parameter specifies the to-be-deactivated NEAR DID.

More importantly, the deletion of a NEAR DID implies this DID cannot be registered or reactivated again.

Security and Privacy Considerations

There are several securities and privacy considerations that implementers would want to take into consideration when implementing this specification.

The current NEAR DID implementation does not allow a NEAR account to have multiple NEAR DIDs, and if the NEAR DID is deactivated, the corresponding NEAR account cannot access the deactivated NEAR DID. Hence, it loses all capability to perform operations on that NEAR DID.

Since the delegates specified in the controller property can change the value of authentication, they have the same privileges as the DID subject.

NEAR DID documents should be limited to verification methods and service endpoints, and should not store any personal information.

Reference Implementations

The reference implementation is available here: https://github.com/ontology-tech/DID-NEAR-rust.

References

[1]. NEAR Protocol, https://www.near.org

[2]. W3C Decentralized Identifiers (DIDs) v1.0, https://w3c.github.io/did-core/