Remove all unspecified properties/functionality from the spec

[csuwildcat]

As I try to decipher rather basic things, like where to project public encryption keys in a DID Doc for basic encrypted message creation (which doesn't seem to be mentioned in any detailed way), there are numerous other properties (i.e. capabilities/delegation) that appear in the spec but have literally 0 definition (at least not that I could find).

If something isn't able to be concretely defined after a long time, or no one has cared to do so, can we just remove them from the spec and reduce how complicated the document is?

[selfissued]

I agree with this in principle. Can you add a list of the undefined and underspecified properties to this issue so a PR can be written to remove them?

[rhiaro]

Do you mean unspecified properties appear in the spec text, or in the examples? I agree we should remove any from spec text, outside of explanatory notes if relevant.

There are lots of examples which contain properties not in DID Core, but which appear (or will eventually, when we are caught up) in the DID Spec Registries. It may be the case that some examples just don't make sense without non-core nested properties - we'd either need to remove these examples altogether, or add an explanation of where to read about the extra properties nearby.

[csuwildcat]

@rhiaro capabilityDelegation, keyAgreement, and assertionMethod all appear exactly once, in a note in the spec that provides absolutely no definition of what they are, yet they float around in the community and folks talk about them as 'the right Assertion Methods to represent ____'. Without them having a specific, directed purpose defined in the spec, they shouldn't be in the spec or suggested to people for use. We may as well put derpabilityCelegation, ageyKreement, and mertionAssethod if we just want to mention random strings, know what I mean?

[kdenhartog]

The action item for #268 is for me to define proof purposes. Along with doing that I plan to provide details about keyAgreement and assertionMethod at the very least because these relate to usage of keys for protocols (keyAgreement) and signing stuff (assertionMethod).

I'm of the opinion capabilityDelegation and capabilityInvocation get moved to extensions (and removed from did-core completely) that can be defined in the registries and will have more details come about from the ZCAP-LD work. Not sure if that stance is shared by others, but was preparing to do the work first and discuss in or outs of stuff during PR review process.

[dlongley]

I'd rather see us express verification relationships to cover "verifying a proof that you want to take an action" (invoke a capability) or "verifying a proof that you want to delegate the authority to take an action" (delegate a capability) in DID core if we can. It will help with interoperability.

[kdenhartog]

I'd rather see us express verification relationships to cover "verifying a proof that you want to take an action" (invoke a capability) or "verifying a proof that you want to delegate the authority to take an action" (delegate a capability) in DID core if we can. It will help with interoperability.

My biggest issue with it is that I don't understand it well enough yet to feel like I can write about it or use it and I think that's a shared sentiment by others. I'll take a first pass attempt at least when doing the others and we can go from there. Given I'm we're not reliant on it so far, I don't have too strong of an opinion in either direction really. Main reason I was seeing it as an extension rather than a did-core property was because I've only seen support for it with did:v1 and did:key. Maybe adding additional details about it's purpose of usage would lead to more people using it though?

[rhiaro]

@kdenhartog there are one-liner definitions for these in https://w3c-ccg.github.io/security-vocab/, in case you missed it

[dlongley]

@kdenhartog, also for reference, some more in depth definitions were jotted down here:

https://gist.github.com/dlongley/c088db3582b4529b28ff0a7fac7a3e23

We're working on figuring out where they go.