w3c / did-test-suite

W3C DID Test Suite and Implementation Report

Home Page:https://w3c.github.io/did-test-suite/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Normative statements checklist: 5. Core properties

rhiaro opened this issue · comments

5.1 Identifiers

5.1.1 DID Subject

  • The value of id MUST be a string that conforms to the rules in § 3.1 DID Syntax
  • and MUST exist in the root map of the data model for the DID document.

5.1.2 DID Controller

  • The controller property is OPTIONAL.
  • If present, the value MUST be a string or a set of strings that conform to the rules in § 3.1 DID Syntax.
  • The corresponding DID document(s) SHOULD contain verification relationships that explicitly permit the use of certain verification methods for specific purposes.
  • 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.

5.1.3 Also Known As

  • The alsoKnownAs property is OPTIONAL.
  • If present, the value MUST be a set where each item in the set is a URI conforming to [RFC3986].

5.2 Verification Methods

  • The verificationMethod property is OPTIONAL.
  • If present, the value MUST be a set of verification methods, where each verification method is expressed using a map.
  • The verification method map MUST include the id, type, controller, and specific verification material properties that are determined by the value of type and are defined in § 5.2.1 Verification Material.
  • Verification methods SHOULD be registered in the DID Specification Registries [DID-SPEC-REGISTRIES].
  • The value of the id property for a verification method MUST be a string that conforms to the rules in Section § 3.2 DID URL Syntax.
  • The value of the type property MUST be a string that references exactly one verification method type.
  • the verification method type SHOULD be registered in the DID Specification Registries [DID-SPEC-REGISTRIES].
  • The value of the controller property MUST be a string that conforms to the rules in § 3.1 DID Syntax.

5.2.1 Verification Material

  • The publicKeyBase58 property is OPTIONAL.
  • ...If present, the value MUST be a string representation of a [BASE58] encoded public key.
  • The publicKeyJwk property is OPTIONAL.
  • ...If present, the value MUST be a map representing a JSON Web Key that conforms to [RFC7517].
  • ...The map MUST NOT contain "d", or any other members of the private information class as described in Registration Template.
  • ...It is RECOMMENDED that verification methods that use JWKs [RFC7517] to represent their public keys use the value of kid as their fragment identifier.
  • ...It is RECOMMENDED that JWK kid values are set to the public key fingerprint [RFC7638].
  • A verification method MUST NOT contain multiple verification material properties for the same material.

5.3 Verification Relationships

  • any [verification method] properties used SHOULD be registered in the DID Specification Registries [DID-SPEC-REGISTRIES].

5.3.1 Authentication

  • The authentication property is OPTIONAL.
  • If present, the associated value MUST be a set of one or more verification methods.

5.3.2 Assertion

  • The assertionMethod property is OPTIONAL.
  • If present, the associated value MUST be a set of one or more verification methods. Each verification method MAY be embedded or referenced.

5.3.3 Key Agreement

  • The keyAgreement property is OPTIONAL.
  • If present, the associated value MUST be a set of one or more verification methods.

5.3.4 Capability Invocation

  • The capabilityInvocation property is OPTIONAL.
  • If present, the associated value MUST be a set of one or more verification methods.

5.3.5 Capability Delegation

  • The capabilityDelegation property is OPTIONAL.
  • If present, the associated value MUST be a set of one or more verification methods.

5.4 Services

  • The service property is OPTIONAL.
  • If present, the associated value MUST be a set of services, where each service is described by a map.
  • Each service map MUST contain id, type, and serviceEndpoint properties.
  • The value of the id property MUST be a URI conforming to [RFC3986].
  • A conforming producer MUST NOT produce multiple service entries with the same id.
  • A conforming consumer MUST produce an error if it detects multiple service entries with the same id.
  • The value of the type property MUST be a string or a set of strings.
  • In order to maximize interoperability, the service type and its associated properties SHOULD be registered in the DID Specification Registries [DID-SPEC-REGISTRIES].
  • The value of the serviceEndpoint property MUST be a string, a map, or a set composed of one or more strings and/or maps.
  • All string values MUST be valid URIs conforming to [RFC3986] and normalized according to the Normalization and Comparison rules in RFC3986 and to any normalization rules in its applicable URI scheme specification.

I have performed a full review of the tests above. All tests with ticked checkboxes exist in the test suite. All tests that are not checked are not mandatory or are human-only tests and do not have active/associated tests in the test suite.