Skip to content

Latest commit

 

History

History
252 lines (173 loc) · 9.58 KB

DID-spec-klaytn.md

File metadata and controls

252 lines (173 loc) · 9.58 KB
Raw

Klaytn DID Specification Draft v0.1

Abstract

This specification describes a new DID method for hosting DIDs on the Klaytn blockchain, also referred to as Klaytn DID. This specification conforms to the requirements specified in the DIDs specification currently published by the W3C Credentials Community Group.

Conformance and Terminology

This specification assumes a fair degree of understanding of W3C DIDs specification.

The key words "MUST", "MUST NOT", "SHOULD", "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF RFC 2119.

Klaytn DID Syntax

Klaytn DID is a URI conforming to IETF RFC 3986 and SHOULD be generated by each entity itself.

Klaytn DID is generated in conformity with W3C DIDs specification.

The ABNF grammar used to generate the Klaytn DID identifier is as follows:

klay-did   = "did:klay:" klay-specific-idstring
klay-specific-idstring = 40*40HEXDIG

did:klay: denotes that Klaytn DIDs are decentralized identifiers conforming to W3C DIDs specification, and are registered on the Klaytn blockchain.

Below is an example of a Klaytn DID:

did:klay:f269E60fF7280e3E11b7EEd7B76b5C005105D121

Klaytn DID Registration and Deactivation

Kalytn DID can be automatically generated without registration for each Kalytn address.

When a Klaytn DID is deactivated, all the related data including public keys, controllers, and other properties will be deleted and only a record of the Klaytn DID identifier will remain on the Klaytn blockchain.

A deactivated Klaytn DID can no longer be used and cannot be reactivated for use.

Klaytn DID Document

Each Klaytn DID will have a corresponding Klaytn DID Document, which is a set of data describing this Klaytn DID.

Below is the basic structure of the Klaytn DID Document:

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:klay:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
  "publicKey": [...],
  "authentication": [...],
  "controller": [...],
  "service": [...],
  "updated": "..."
}

Context

Klaytn DID Documents MUST include a @context property.

The value of the @context property MUST be one or more URIs, where the value of the first URI MUST be https://www.w3.org/ns/did/v1. For more information, see W3C DIDs specification.

Below is an example in which the @context property has two values:

{
  "@context": ["https://www.w3.org/ns/did/v1"]
}

Identifiers

Klaytn DID Documents MUST include an id property.

The value of the id property denotes the Klaytn DID subject that the Klaytn DID Document is about.

The value of id MUST be a valid Klaytn DID. A Klaytn DID MUST have exactly one DID subject.

{
  "id": "did:klay:f269E60fF7280e3E11b7EEd7B76b5C005105D121"
}

Public Keys

A Klaytn DID Document MAY include a publicKey property to specify a set of public keys linked to that Klaytn DID.

Public and private key pairs can be used for the identity management, authorization, and verification of Klaytn DIDs. A Klaytn DID can be linked to multiple public and private key pairs and one pair of public and private keys can also be used to manage multiple Klaytn DIDs.

Every public key object linked to the publicKey property MUST include the fields id, type, controller and specific public key properties, and MAY include other additional properties.

Each linked public key has its own identifier specified using the field id. The value of publicKey MUST NOT contain multiple entries with the same id.

Bound public keys can be revoked. Revoked public keys MUST NOT be reactivated, but can still possess the original id.

The value of the type field represents the corresponding public key type. Klaytn DID Documents support EcdsaSecp256k1RecoveryMethod2020 and EcdsaSecp256k1VerificationKey2019.

The value of the controller field which identifies the controller of the corresponding private key MUST be a valid Klaytn DID, implying that the public key is controlled by this Klaytn DID.

The encoding formats that Klaytn DID Documents support include publicKeyHex and ethAddress. Public keys of all types MUST be expressed in these two formats.

Below is a specific example of the publicKey property:

{
  "publicKey": [
	{
	  "id": "did:klay:f269E60fF7280e3E11b7EEd7B76b5C005105D121#keys-1",
	  "type": "EcdsaSecp256k1VerificationKey2019",
	  "controller": "did:klay:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
	  "publicKeyHex": "0xfbf38de9fb40edcdab412094d24fa39a314f3d3f52f5860e2509c32522eda30161fe70dfc9f90434d64bd976ede4f112d4f2d8e34d28fe48281663219d2ddac6"
	},
	{
	  "id": "did:klay:f269E60fF7280e3E11b7EEd7B76b5C005105D121#keys-1",
	  "type": "EcdsaSecp256k1RecoveryMethod2020",
	  "controller": "did:klay:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
	  "ethAddress": "0xf269E60fF7280e3E11b7EEd7B76b5C005105D121"
	}
  ]
}

Authentication

Klaytn DID Documents SHOULD include an authentication property to specify a set of verification methods.

A Klaytn DID subject could add the authentication property in its corresponding Klaytn DID Document to denote that the subject has authorized a set of verification methods for the purpose of authentication.

The associated value MUST be an ordered set of one or more verification methods. Each verification method in the authentication property MAY be embedded or referenced.

Below is an example which refers to authentication keys in the two way specified above:

{
  ...
  "authentication": [
	"did:klay:f269E60fF7280e3E11b7EEd7B76b5C005105D121#keys-1",
	{
	  "id": "did:klay:f269E60fF7280e3E11b7EEd7B76b5C005105D121#keys-2",
	  "type": "EcdsaSecp256k1VerificationKey2019",
	  "controller": "did:klay:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
	  "publicKeyHex": "03a835599850544b4c0a222d594be5d59cf298f5a3fd90bff1c8caa064523745f3"
	}
  ],
}

Authorization and Delegation

In a Klaytn DID Document, an OPTIONAL controller property is included to assign one or more delegates.

A Klaytn DID can be delegated to and controlled by one or more distinct Klaytn DIDs.

A Klaytn DID delegate has the necessary authorization to insert a new verification method into the authentication property of the delegated Klaytn DID.

It is worth noting that a Klaytn DID Document can assign controller without defining the value of authentication.

The Klaytn DID Document of the delegate SHOULD have a authentication property.

Below is a specific example representing that either did:klay:5Ee76017be7F983a520a778B413758A9DB49cBe9 or did:klay:9861eE37Ede3dCab070DF227155D86A7438d8Ed2 can act as a delegate of did:klay:f269E60fF7280e3E11b7EEd7B76b5C005105D121:

{
  ...
  "id": "did:klay:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
  "controller": [
	"did:klay:5Ee76017be7F983a520a778B413758A9DB49cBe9",
	"did:klay:9861eE37Ede3dCab070DF227155D86A7438d8Ed2"
  ],
}

Service Information

Klaytn DID Documents use an OPTIONAL service property to specify the service property.

Klaytn DID allows entities to add services and specify the relevant information of a service that is related to the particular Klaytn DID, including fields such as the type of service and service endpoint.

This part is derived directly from W3C DIDs specification.

Below is a specific example:

{
  ...
  "service": [
	{
	  "id": "did:klay:f269E60fF7280e3E11b7EEd7B76b5C005105D121#some-service",
	  "type": "SomeServiceType",
	  "serviceEndpoint": "Some URL"
	}
  ]
}

Created

Kalytn DID Documents do not include a created property as Kalytn DID can be automatically generated for each Kalytn address.

Updated

Klaytn DID Documents SHOULD include an updated property to specify a timestamp of the most recent change.

This part is derived directly from W3C DIDs specification.

Below is a specific example:

{
  "updated": "2019-06-30T12:00:00Z"
}

Appendix

A simple example of a Klaytn DID Document is as follows:

{
  "@context": ["https://www.w3.org/ns/did/v1", "https://www.eth.org/did/v1"],
  "id": "did:klay:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
  "publicKey": [
	{
	  "id": "did:klay:f269E60fF7280e3E11b7EEd7B76b5C005105D121#keys-1",
	  "type": "EcdsaSecp256k1VerificationKey2019",
	  "controller": "did:klay:f269E60fF7280e3E11b7EEd7B76b5C005105D121",
	  "publicKeyHex": "0xfbf38de9fb40edcdab412094d24fa39a314f3d3f52f5860e2509c32522eda30161fe70dfc9f90434d64bd976ede4f112d4f2d8e34d28fe48281663219d2ddac6"
	}
  ],
  "authentication": [
	"did:klay:f269E60fF7280e3E11b7EEd7B76b5C005105D121#keys-1"
  ]
}

Normative References

[W3C-DID]

Decentralized Identifiers (DIDs) v1.0. W3C. Jul 2020. Working Draft. URL: https://www.w3.org/TR/did-core/

[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119

[RFC3986]

Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. JANUARY 2005. Standards Track. URL: https://tools.ietf.org/html/rfc3986