- From: =Drummond Reed <drummond.reed@evernym.com>
- Date: Thu, 18 Apr 2019 00:56:15 -0700
- To: Credentials Community Group <public-credentials@w3.org>
- Cc: "Markus Sabadello (markus@danubetech.com)" <markus@danubetech.com>
- Message-ID: <CAAjunnb8XDjv=jRjZ2dPyLrOQFo1T8PJmxN4Da8CY=44_-A3Hw@mail.gmail.com>
Markus Sabadello and I have created this Google doc
<https://docs.google.com/document/d/1qnDExIVjU5bYc601qUdLZIi9UAs1ojlHyKnVoz2zlLM/edit?usp=sharing>
and propose it as one of our main topics for the weekly DID & DID
Resolution Spec call Thursday 13:00-15:00 PT (see meeting page
<https://docs.google.com/document/d/1qYBaXQMUoB86Alquu7WBtWOxsS8SMhp1fioYKEGCabE/edit?usp=sharing>
for logistics).
See below for a complete copy. Comments are welcome directly on the Google
doc (though substantive contributions can only be made by CCG members) or
via reply on the list.
Proposal for Revisions to Decentralized Identifiers Section of DID Spec
2019-04-17
This is a proposal for new text to replace the start of the Decentralized
Identifiers section of the DID spec v0.12
<https://w3c-ccg.github.io/did-spec/>. Once we have reviewed this via email
and the April 18 DID spec call and processing any comments, it will be
turned into a PR.
Decentralized IdentifiersThe Generic DID Scheme
The generic DID scheme
<https://pr-preview.s3.amazonaws.com/w3c-ccg/did-spec/pull/168.html#dfn-did-scheme>
is a URI scheme conformant with [RFC3986
<https://pr-preview.s3.amazonaws.com/w3c-ccg/did-spec/pull/168.html#bib-rfc3986>].
The DID scheme only specializes the scheme and authority components of a
DID URI—the path, query, and fragment components are identical to the rules
defined in [RFC3986
<https://pr-preview.s3.amazonaws.com/w3c-ccg/did-spec/pull/168.html#bib-rfc3986>].
Note that the term “DID” refers only to the identifier conforming to the did
rule in the ABNF below. Additionally, a DID can be used as a component in a
DID URL, defined by the did-url rule.
The following is the ABNF definition using the syntax in [RFC5234
<https://pr-preview.s3.amazonaws.com/w3c-ccg/did-spec/pull/168.html#bib-rfc5234>]
which defines ALPHA and DIGIT. All other rule names not defined in this
ABNF are defined in [RFC3986
<https://pr-preview.s3.amazonaws.com/w3c-ccg/did-spec/pull/168.html#bib-rfc3986>
].
did = "did" 1*( ":" method-name ) ":" method-specific-id
method-name = 1*method-char
method-char = %x61-7A / DIGIT
method-specific-id = 1*idchar
idchar = ALPHA / DIGIT / "." / "-" / "_"
did-url = did *( ";" param ) path-abempty [ "?" query ]
[ "#" fragment ]
param = param-name [ "=" param-value ]
param-name = 1*param-char
param-value = *param-char
param-char = ALPHA / DIGIT / "." / "-" / "_" / ":" /
pct-encoded
Generic DID Parameter Names
The ABNF above does not specify any parameter names (the param-name rule).
The following table defines a set of generic DID parameter names for
parameters that MUST operate uniformly across all DID methods.
(Method-specific parameter names are covered in the following section.)
Parameter Name
Definition
service
Selects a service JSON-LD object from the DID Document by id
service-type
Selects a service JSON-LD object from the DID Document by type
key
Selects a publicKey JSON-LD object from the DID Document by id
key-type
Selects a publicKey JSON-LD object from the DID Document by type
version-id
Specifies a specific version of a DID Document to be resolved (the version
ID could be sequential, or a UUIDs, or method-specific)
version-time
Specifies a certain version timestamp of a DID Document to be resolved
(i.e. the DID Document that was valid for a DID at a certain time)
content-type
Specifies a type of content object (other than a DID document) to be
returned from the target DID registry
content-id
Specifies the method-specific identifier of a content object (other than a
DID document) to be returned from the target DID registry
hl
A hashlink or resource hash as specified in Cryptographic Hyperlinks
<https://tools.ietf.org/html/draft-sporny-hashlink-02> to add integrity
protection to the resource identified by the DID URL
Note that there may be additional parameters or options that are not part
of the DID URL but instead passed to a DID resolver “out of band”, i.e.,
using a resolution protocol or some other mechanism. Such options could for
example control caching or the desired format of a resolution result. This
is similar to HTTP, where caching or result format are expressed as HTTP
headers rather than as part of an HTTP URL. The important distinction is
that DID parameters that are part of the DID URL control what resource is
being identified, whereas DID resolver options that are not part of the DID
URL control how that resource is dereferenced.
Method-Specific DID Parameter Names
A DID method specification MAY specify additional method-specific parameter
names. A method-specific parameter name MUST be prefixed by the method name
as defined by the
1*( ":" method-name ) rule.
For example, if the method did:foo: defines the parameter bar, the
parameter name must be foo:bar. An example DID URL using this method and
this method-specific parameter would be:
did:foo:21tDAKCERh95uGgKbJNHYp;foo:bar=high
Note that a method-specific parameter name defined by one DID method MAY be
used by other DID methods. For example:
did:example:21tDAKCERh95uGgKbJNHYp;foo:bar=high
Method-specific parameter names MAY be combined with generic parameter
names in any order.
did:example:21tDAKCERh95uGgKbJNHYp;service=agent;foo:bar=high
Just as DID method names may be hierarchical, so may method-specific
parameter names. This example DID URL shows both:
did:foo:baz:21tDAKCERh95uGgKbJNHYp;foo:baz:hex=b612
********* END OF CURRENT PROPOSAL *******
RFC 3986 <https://www.ietf.org/rfc/rfc3986.txt> Appendix A (Provided for
Reference)
The syntax path through the RFC 3986 ABNF used by the DID scheme is
highlighted in red below.
Appendix A. Collected ABNF for URI
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
URI-reference = URI / relative-ref
absolute-URI = scheme ":" hier-part [ "?" query ]
relative-ref = relative-part [ "?" query ] [ "#" fragment ]
relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-empty
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
authority = [ userinfo "@" ] host [ ":" port ]
userinfo = *( unreserved / pct-encoded / sub-delims / ":" )
host = IP-literal / IPv4address / reg-name
port = *DIGIT
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
IPv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
h16 = 1*4HEXDIG
ls32 = ( h16 ":" h16 ) / IPv4address
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
reg-name = *( unreserved / pct-encoded / sub-delims )
path = path-abempty ; begins with "/" or is empty
/ path-absolute ; begins with "/" but not "//"
/ path-noscheme ; begins with a non-colon segment
/ path-rootless ; begins with a segment
/ path-empty ; zero characters
path-abempty = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty = 0<pchar>
segment = *pchar
segment-nz = 1*pchar
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
; non-zero-length segment without any colon ":"
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
query = *( pchar / "/" / "?" )
fragment = *( pchar / "/" / "?" )
pct-encoded = "%" HEXDIG HEXDIG
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
Received on Thursday, 18 April 2019 07:56:53 UTC