Details on the use of method-specific DID parameters

[brentzundel]

@peacekeeper moved from CCG (w3c-ccg/did-spec#200)

[talltree]

The issue relates to Section 4.3: Generic DID Parameter Names, and Section 4.4: Method-Specific DID Parameter Names. Please start by reading the issue description at w3c-ccg/did-spec#200. Also the two comments listed there.

I propose to start the discussion by focusing on these two questions:

1. Should we assume that generic DID parameter names are distinguished by having no prefix?
2. If so, what prefix should we use to distinguish method-specific parameter names?

The answers currently reflected in sections 4.3 and 4.4 are:

1. Yes, generic DID parameter names have no prefix.
2. The prefix for method-specific parameter names is the fully qualified DID method name. (This also explains why colons are the separator in method-specific parameter names.)

Are there other proposals?

[selfissued]

Related to this is #67 (comment) - making it syntactically evident which fields in a DID are about the DID and which are application data.

[dlongley]

I presume this issue is blocked on the matrix parameter discussion.

[kdenhartog]

I want to voice my opinion that while I think that these should be allowed, as an implementer, the use of these should be strongly discouraged unless absolutely necessary. This is to the point where for a method that opts to use many method-specific parameters, I'd likely not implement it in a resolver. In a universal resolver implementation, this leads to more complex code that needs to be written and I believe it could create feature silos (aka DID method A supports feature A but DID method B doesn't so they can't interoperate reliably without modifying assumptions between the DID methods).

Inclusion of this should note this in non-normative language.

[talltree]

This issue is now waiting on a PR from @peacekeeper and I on slight revisions to the ABNF to support the new approach to parameters, i.e., encoding DID parameters as query parameters. Once that's done, we can close on the question of what the prefix should be for method-specific DID parameters.

On the 2020-05-12 DID WG call, @kdenhartog noted that, with the addition of the DID Spec Registry, it should be easier for method-specific DID parameters to be supported, so it may address his concerns expressed above.

[OR13]

@csuwildcat ION and Element use Method specific initial-state parameters... we should provide an example for the working group when that becomes possible.

See https://identity.foundation/sidetree/spec/#long-form-did-uris

did:METHOD:<did-suffix>?-METHOD-initial-state=<create-suffix-data-object>.<create-delta-object>

[csuwildcat]

For method specific DID parameters, I propose we go with the convention -METHOD-some-param, wherein -METHOD- would be the leading prefix for the parameter some-param. This means all unprefixed parameters would be assumed to be generic DID parameters. The convention -prefix- is in keeping with the format of CSS prefixed properties, thus it would look familiar to developers. Additionally, implementers are extremely unlikely to purposefully add/have added a leading dash to their params, so I can't image we'd see collisions with any parameters in use today.

[kdenhartog]

My current understanding of how we'd process these would be that a dereferencing function would handle this in most cases. Would this mean that the dereference function is the one that's "compliant" with a did method?

[talltree]

Based on several recent conversations with implementers, and an in-depth discussion between the editors, we have come down in favor of not using any namespacing for DID parameters. This effectively means that there will only two categories of DID parameters:

1. Registered DID parameters are those registered in the DID Specification Registries. It will no longer matter whether a registered DID parameter was originally defined in the DID Core spec or in a DID method specification or by any other implementer. It will only matter that it is registered, as this is the best way to avoid collision with another DID parameter with the same name but different semantics.
2. Unregistered DID parameters. Any implementer can use their own unregistered DID parameter names with at the (hopefully small) risk that someone else could register that same DID parameter name with different semantics. To be clear, it is not a risk if the parameter name is registered with the same semantics as other implementers are already using. The only race condition is if someone else registers the parameter name with different semantics.

To the extent this encourages registration of common parameter names in the DID Specification Registries, that is perceived as generally helpful to interoperability.

If anyone has a strong objection to this resolution of the topic of method-specific DID parameters, please comment ASAP, otherwise Markus and I plan to submit a PR to "make it so".

[csuwildcat]

Awesome! Thank you to @talltree and @peacekeeper for driving this to a final resolution. When can we start the process of registering new DID parameters?

[talltree]

@csuwildcat That is a question for @OR13 and @msporny, the editors on the DID Specification Registries doc. But I believe the answer is that you could submit a PR at any point.

[peacekeeper]

@csuwildcat I also think you can just create a PR that adds a new DID parameter to this section: https://w3c.github.io/did-spec-registries/#parameters.

Similar to this one w3c/did-extensions#61 where I added the core DID parameters. You just add another one below those, with an example and a link to the normative definition.

[kdenhartog]

Thanks for driving this home @talltree and @peacekeeper I am satisfied with the proposed solution set out by Drummond above #36 (comment)

From what I can tell this wouldn't lead us to any sort of actions to be taken in the specification and it's up to parameter authors to register them properly (or add them to the spec as Markus pointed out).

Does this mean we can close this issue with no further action soon?

[peacekeeper]

I'm planning to work on a PR for this in the next few days.

[peacekeeper]

I believe this can be closed now that #378 has been merged, @talltree and others do you agree?

[brentzundel]

No comments since marked pending close, closing