If an existing DID Document has a Service Endpoint fragment, what are the primary keys to be used if that Service Endpoint needs to be replaced, updated, or deleted?

[mwherman2000]

If an existing DID Document has a Service Endpoint fragment, what are the primary keys to be used if the Service Endpoint (or elements of the Service Endpoint) need to be replaced, updated, or deleted?

Context (from EXAMPLE 2):

  "service": [{
    "id":"did:example:123456789abcdefghi#vcs",
    "type": "VerifiableCredentialService",
    "serviceEndpoint": "https://example.com/vc/"
  }]

Questions

1. Because this fragment has an id subelement, is id the primary key for this Service Endpoint? ...for all subelement level updates and deletions?

2. Because this fragment has an id subelement, is id the primary key for this Service Endpoint for deleting the corresponding (entire) Service Endpoint from the DID Document?

3. If there was no id subelement, would it be a combination of type and servicePoint that would serve as the primary key for the above two use cases (questions 1 and 2)?

4. If there was no id subelement and no type subelement, would servicePoint alone serve as the primary key for the use cases/questions 1 and 2?

Sample Equals method code:

            if (this._didsvcDID.Length > 0)
            {
                if (this._didsvcDID != other._didsvcDID)
                    return false;
            }
            else
            {
                if ((this._didsvcDID.Length > 0) && (this._didsvcType != other._didsvcType))
                    return false;
                if (this._didsvcServiceEndpointUrl != other._didsvcServiceEndpointUrl)
                    return false;
            }

            return true;

[peacekeeper]

All of this is out-of-scope for the DID spec and method- or application-specific. Some DID methods may make use of the id property for their Update operation (e.g. the Peer DID method), but other methods may do this in different ways. There could be DID methods that will only ever have a single public key in their DID Document, so you don't really need an identifier in order to be able to update it.

I've raised a question on whether id should actually be required for public keys and services: #247

Also note that there has been some discussion on Immutability and security aspects, and on whether the id should change if the public key or service changes.

[mwherman2000]

Thank you for the pointers @peacekeeper ...the actual did-spec text (as of today) states (for Public Keys)...

2. The value of the publicKey property MUST be an array of public keys, and every public key property MUST be in the Linked Data Cryptographic Suite Registry.
3. Each public key MUST include id and type properties, and exactly one value property. The array of public keys MUST NOT contain duplicate entries with the same id.
4. Each public key MUST include a controller property, which identifies the controller of the corresponding private key.

Ditto for Service Endpoints.

The implication is that the id property is required and must be unique within a given array of public keys (or service endpoints). This reduces the number of use cases. The did-spec answers the above questions. Thank you.

[ChristopherA]

My presumption is that each DID method should have guidance/conventions for DID Resolvers when asking the resolver to construct a DID document. In the case of BTCR, the current standard is that the resolver name the current transaction key (mutable) used for authentication proofs (DIDCom for instance) as #satoshi, and then for all keys in the transaction chain (immutable) for use in assertionMethod proofs (VCs and VPs) are incrementally #key-0, #key-1, etc. The last #key-X will always be the same as the current #satoshi key.

I'm open to common naming conventions for these, in particular the transaction chain of assertionMethod that we call #keys-X, as we may have this in common with some other methods.

P.S. I'm also seeking the simplest possible way to mark status/revocation-ish information inside a DID Document for a key that was used an older DID Document, for instance #key-0 is no longer valid for VCs after date X, or all #key-0 are revoked for reason X, etc.

[mwherman2000]

@ChristopherA I think your comment is about a different topic and should be used to open a new issue.
Cheers.

[peacekeeper]

@ChristopherA I think your comment is about a different topic and should be used to open a new issue.
Cheers.

@mwherman2000, I think @ChristopherA 's comment is very relevant, since this current design of the BTCR method combines the advantages of both mutable identifiers (#satoshi) and immutable identifiers (#key-0). This explains why there may not be a primary key that can be used for the operations you mentioned.

[mwherman2000]

@ChristopherA In the BCTR method, can the same identifier for a key appear/be used for more than one key within a the same collection/array of keys?

I don't need a single primary identifier for a specific key ...just one that is unique in a given array (i.e. is not used for any other key in the array).

I.e. is this property still satisfied?

The implication is that the id property is required and must be unique within a given array of public keys (or service endpoints).

[jandrieu]

Closing because we've moved it to the DID WG did-spec repo. https://github.com/w3c/did-spec