How are Service Endpoints defined?

[kimdhamilton]

The current DID spec draft lists several examples of services, e.g. socialWebInboxService and credentialRepositoryService.

From what I can see:

1. In the DID LD-context, there are no terms related to services
2. The DID spec does not specify a data model for service endpoints, just examples like Extensible Data Interchange.

Is this correct? If so, then my current understanding of service endpoints is:

3. method specs define terms in their LD context
4. method specs define (or point to) the data model for service endpoints

Is this also correct?

[msporny]

In the DID LD-context, there are no terms related to services

Correct and we should decide if there are common services that do belong in there. For example, one could make an argument that credentialRepositoryService should go in there because a large subset of the population will have a Verifiable Claims Credential Repository.

The DID spec does not specify a data model for service endpoints, just examples like Extensible Data Interchange. Is this correct?

Correct, they're just nodes in the graph. The service endpoints themselves are probably specified in another specification (such as the Verifiable Claims spec).

method specs define terms in their LD context

Service endpoints are most likely not method spec specific (some may be, but most shouldn't be).

method specs define (or point to) the data model for service endpoints

Probably not, in general, you don't want to couple service endpoint descriptions with the DID or DID Method specs because that would put a constraint on innovation (requirement being that if you want your new service description in there, you MUST get it into the DID or DID method spec).

[msporny]

I think we can at least say these things at present:

• Service Descriptions probably belong in their own specs, or sections of other specs (like Credentials Handler API spec).
• Terms for Service Descriptions may eventually find their way into the DID JSON-LD context if they are broadly supported, and until they do, they can be defined in a JSON-LD context that is not in the DID context nor a DID Method context.

We need more discussion in the group before we can make a decision one way or the other.

The other interesting data point here is that this may be a stronger argument for a "keys" and "services" container since we'd be able to keep the DID Context from growing uncontrollably based on the standardized services discoverable via DID Documents.

[msporny]

The spec now contains a section on service endpoints:

https://w3c-ccg.github.io/did-spec/#service-endpoints

Closing this issue.