Should "id" be mandatory for "service" and "publicKey"?

[brentzundel]

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

[dlongley]

We should be careful not to bias expressing services based on whether or not people are using DID URLs to refer to them. Just because some services may benefit from being referenced via a DID URL, others may not -- and for those services, IDs may be an unnecessary burden.

[selfissued]

The key ID should be expressed using the JWK "kid" field and not duplicated elsewhere.

[peacekeeper]

My rationale for raising this PR were considerations around how DID methods work internally. There are some good opinions and usage patterns on the use of IDs (e.g. about fragment immutability - see w3c-ccg/did-spec#238), but ultimately it's up to the DID method how IDs work.

• In some DID methods, the controller may be able to arbitrarily assign IDs inside the DID Document.
• In some DID methods, the IDs may be deterministically set by the DID method (e.g. sequential numbers, content addresses, etc.)
• And I believe there may also be DID methods that don't support IDs for services and public keys at all.

I think all of the above should be supported by the spec.

[dlongley]

I agree with @peacekeeper and we should keep things as they are now (I believe IDs are presently optional) and just make sure the spec is clear on this matter. If it turns out that we have consensus from the group on this, then we should also close issue #46 once this issue is closed.

[peacekeeper]

(I believe IDs are presently optional)

No the spec says each public key and service endpoint MUST include id. I propose to change this, but I also think we should get some more input first (e.g. @dhh1128 probably has opinions on this).

[dhh1128]

I don't have a strong opinion about the issue in the broader context of all DID methods. However, id is required for updatable DID docs in the did:peer method, as it interacts with CRDT semantics to provide important guarantees.

[peacekeeper]

The key ID should be expressed using the JWK "kid" field and not duplicated elsewhere.

@selfissued with regard to using JWK as a public key format (which may be a longer discussion, see #67), I believe making id in the current spec optional is a step towards alignment with JWK, since kid in JWK is also optional. Furthermore, it may be worth exploring adding a JSON-LD term called kid that maps to JSON-LD's @id, for even more alignment.

In any case, I think if we agree in principle that id/kid should be optional, then I think making this change now would also support the other discussion about public key formats?