Need to normatively define the service endpoint object for the DID Document

[kdenhartog]

I was looking over the answer for #90 and realized we haven't defined the service endpoint object for an Identity Hub yet. This is an issue to track the item.

I believe an example would be the following:

{
  "service": [{
    "id":"did:example:123#identityHub",
    "type": "IdentityHub", 
    "serviceEndpoint": "https://hub.example.com/"
  }]
}

I remember @csuwildcat talking about awhile back that the serviceEndpoint may be an Array of URL endpoints rather than a single string. If that's the case we'll want to add details about that and the selection process for which one should be chosen and when as well I believe.

[mahoekst]

Ah ok, so the id was used. I assumed the #identityhub was referencing the type only

[gobengo]

@kdenhartog I think this is resolved now? Latest example is here https://identity.foundation/decentralized-web-node/spec/#service-endpoints

[kdenhartog]

@gobengo not quite. That is essentially just saying it MUST be done and then pointing at a non-normative example. To do this properly in a spec such that it's not going to get messed up in DID Documents (I've looked at a lot of did methods and they mess simple stuff like this up often) the terms in the service object need to be normatively defined such that it's clear what the requirements are for each.

For example, is it legal to use any URL in the node dictionary or is it required to be HTTPS? Additionally, is it expected that the id property will always conform with only listing the fragment property which then means the @base property needs to be defined in JSON-LD to properly link the graph or is it expected that this id property could also be a fully formed DID URL like did:example:123#dwn.

By leaving this so loosely defined as it is right now you're making it so the test suite that tests this object becomes the method by which the logic for this is defined (which can't be registered in the did-spec-registries) or alternatively you're leaving this so loose that it won't be interoperable for some implementations.

[andorsk]

Discussed in DIF call:

related: https://github.com/decentralized-identity/decentralized-web-node/pull/228.

We will close this issue when the PR is merged.