Skip to main content

Mizuhiki DID Method Draft Specification [v0.0.1]

NOTE: This draft specification has not been submitted to W3C or other bodies. We will continue to update this specification throughout the duration of the private Kaigan testnet. Please check back for updates.

注：この仕様書は W3C または他の機関に提出されていません。Kaigan テストネットの期間中、この仕様書を継続的に更新していきます。更新情報をご確認ください。

注：この仕様書は、DID Methods W3C レジストリへの提出準備のため、現在英語のみでの提供となっています。

  • A "Mizuhiki DID" or "Mizuhiki DID Method" refers to the syntax, resolution, verification and authorisation of DIDs and DID documents that begin point to did:mizuhiki. - A Mizuhiki DID registry is an EVM smart contract registry which issues unique DIDs to users who have undergone KYC requirements under Japan AML law (Act on the Prevention of Transfer of Criminal Proceeds). - KYC is performed by a "Mizuhiki Controller", which must be a registered JPKI Service Provider.

Method Syntax​

method-name​

  1. The method-name that shall identify this DID Method is mizuhiki.
  2. A DID that uses this method MUST begin with the prefix did:. The method-name mizuhiki follows the first colon and terminates with a second colon, e.g., did:mizuhiki:

method-specific-id​

  1. The method-specific-id is composed of an EVM blockchain network string identifier where the respective Mizuhiki DID registry lives
  2. As of v1.0, the Mizuhiki DID method only supports the Kaigan testnet with the method-specific-idas kaigan.
  3. kaigan refers to the ephemeral Japan Smart Chain private testnet with RPC endpoint 000005826
  4. The method-specific-id proceeds the second colon after method-name and terminates with a colon.
  5. Normalisation is supported by the DID resolver. The did prefix, method-name and method-specific-id shall all be resolved to lowercase by default.
did:mizuhiki:kaigan:{subjectID}

Uniqueness of method-specific-id​

  1. The method-specific-id is to be unique within the Mizuhiki DID method and map 1:1 with the stringname of a blockchain network.
  2. The supported smart contract registries maintained will be explicitly stated in future versions of the specification, along with their respective globally unique RPC endpoints.

DID generation​

  1. The DID's {subjectID} parameter (i.e., a subject's unique identifier) generated by the Mizuhiki method conforms to the ULID specification to ensure uniqueness and sortability.
  2. The first 48 bits of the DID are generated by the UNIX time in millseconds at the time of the user's KYC through a Mizuhiki controller's endpoint.
  3. The latter 80 bits are generated by a source of randomness determined by the Mizuhiki controller.
  4. DIDs issued within the same millisecond can be lexicographically sorted with ulid.Monotonic which monotonically increases the entropy bytes for the sasme ULID timestamp.
 01AN4Z07BY      79KA1307SR9X4MV3
|----------|    |----------------|
 Timestamp           Entropy
  10 chars           16 chars
   48bits             80bits
   base32             base32

method-name registration in [DID-SPEC-REGISTRIES]​

The method-name is to be registered under the DID Methods W3C registry in the immediate future.

method-specific-id formatting​

  1. Currently, this specification only actively supports the Japan Smart Chain private testnet kaigan.
  2. As DID issuance is limited to those who have undergone a specific KYC verification determined by a Mizuhiki controller. As the controller has authority over which blockchains a Mizuhiki DID smart contract registry lives, the controller also determines method-specific-ids for each DID.
  3. Future supported blockchain networks supported by Mizuhiki should have a method-specific-id that ONLY INCLUDES %X61-7A (lowercase ASCII letters) and DIGIT (numbers 0-9)
  4. A colon must proceed the method-specific-id and is to be immediately followed by the userID. A method-specific-name without a proceeding colon and userID is not considered a valid DID.

Path​

  1. Path rules are to conform to the generic rules defined by path-abempty ABNF rule in RFC 3986, section 3.3.
did:mizuhiki:kaigan:{subjectID}/path

Query​

  1. Query rules are to conform to the generic rules defined by the query ABNF rule in RFC 3986, section 3.4.
did:mizuhiki:kaigan:{subjectID}?versionId=1

Fragments​

  1. DID fragments are to conform to the generic rules defined by the fragment ABNF rule from RFC 3986, section 3.5.
did:mizuhiki:kaigan:{subjectID}#public-key-0

Method Operations​

DID method authorization​

  1. A Mizuhiki DID controller is a limited set of EVM addresses (addresses derived from an ECDSA public key) stored in the smart contract registry. The Mizuhiki DID smart contract defines two roles: CONTROLLER (admin) and SUBJECT (public): A CONTROLLER is able to update the content of the resource returned from dereferencing a DID. Mizuhiki roles are defined in MizuhikiAccessManager.sol, based on the AccessManager (v5.x) standard by OpenZeppelin .
  2. Any one keypair of the CONTROLLER set have the ability to issue DIDs on behalf of subjects. This function is limited to the CONTROLLER set.
  3. Thus, any holder of the private key to one of the keypairs contained in the CONTROLLER set is able to make changes to a DID document.
  4. Issuance, updates and invalidation of DIDs are performed on the respective blockchain registry's Mizuhiki DID.sol smart contract.

DID and DID Document creation​

Mizuhiki DID Contract Deployment

  1. Upon deployment of the Mizuhiki DID smart contract, a did:mizuhiki:{method-specific-id}:controller string array is initialized.
  2. This did:mizuhiki:{method-specific-id}:controller array initially maps to the address of the contract deployer (msg.sender).
  3. The deployer's address is automatically assigned the CONTROLLER role within the smart contract. This role grants access to restricted functions, such as:
  • Issuing DIDs and DID Documents.
  • Updating DID Documents.
  • Adding or removing other EVM addresses from the CONTROLLER array.
  1. An address with the role CONTROLLER must be authenticated in order to access the restricted functions using a private key corresponding to an EVM address that maps to the CONTROLLER role.
  2. Mizuhiki Controller EVM addresses are subject to change, thus the did:mizuhiki:{method-specific-id}:controller array allows Mizuhiki DID resolvers to query the latest set of trusted Mizuhiki controller's when verifying Mizuhiki subject DIDs.

Issuance of a Mizuhiki Subject DID

  1. A Mizuhiki controller must be a JPKI Service Operator in order to perform KYC and receive authorisation to be a "Mizuhiki Attestor" by the Japan Smart Chain Foundation.
  2. A Mizuhiki subject must undergo KYC using a valid My Number Card, which the Mizuhiki controller must verify.
  3. Upon successful verification, the Mizuhiki controller calls the registerDID() function with the following parameters, which form the basis of a Mizuhiki DID document:
    • string memory did
    • uint256 expiryDate
    • bool exists
    • bool deactivated
  4. The provided did and expiryDate parameters, along with the caller's address (msg.sender - which, by definition, is the Mizuhiki controller's address), are then persistently stored. The exists and deactivated status are respectively set to true and false by default; these values are only able to be changed by calling the updateDIDValidity() function contained in the samrt contract and again restricted to the Mizuhiki controller set. Specifically, DID document details are recorded in a mapping (or hash map) within the Mizuhiki smart contract: the exists parameter enables the contract to be more easily resolved by the getDIDDocument() function (described below). The did string serves as the unique key, pointing to a data structure (e.g., a struct) that holds the expiryDate and the msg.sender address.
  5. Mizuhiki Subject DID issuance may be updated later to add verification method(s) by calling addVerificationMethod(), restricted to a Mizuhiki controller.

DID Method resolution​

As per the W3C DID Resolution working draft, a conforming DID resolver is any algorithm realized as software and/or hardware that complies with the relevant normative statements under 4. DID Resolution.

A conforming DID URL dereferencer is any algorithm realised as software and/or hardware that complies with the relevant normative statements in 5. DID URL Dereferencing

The getDIDDocument() function on any given valid Mizuhiki DID.sol smart contract returns the verificationMethods, expiryDate, and deactivation status.