Remove 'name' from service description

[msporny]

The current consensus in the group seems to be that service descriptions looks something like this:

{
  "id": "did:v1:1234567",
  ... // DID Document goes here ...
  "service": [{
    "type": "urn:foobar:MessagingService",
    "name": "messaging",
    "serviceEndpoint": "https://example.com/messages/398tuo"
  }]
}

... which could result in the following URL that uses the service above:

did:v1:1234567;messaging/somepath#somefrag3

I suggest that we remove name and move to a less error prone format:

{
  "id": "did:v1:1234567",
  ... // DID Document goes here ...
  "service": [{
    "id": "did:v1:1234567;messaging",
    "type": "urn:foobar:MessagingService",
    "serviceEndpoint": "https://example.com/messages/398tuo"
  }]
}

Note that we get rid of the name field and use id instead. This approach has the following benefits:

1. It fits with the JSON-LD model more cleanly,
2. doesn't require implementations to destructure a URL and look for specific properties (opaque identifiers),
3. avoids the creation of a scenario where the id and the constructed service URL can differ, and
4. enables us to use the semicolon syntax to address things that are not just service endpoints in the document.

[msporny]

I'll work on a PR that updates the service description and DID syntax parts of the spec to match this proposal so that the group has something to have a conversation around.

[peacekeeper]

How is this error prone? Also, my understanding is that in the DID resolution process, no URL is ever "constructed", only parsed. What else would you use the semicon for?

(Yes we can move this discussion to a PR when there is one).

[talltree]

I too am happy to move this to a PR when Manu has one. I can see the upside of his suggestion, but I also see at least one downside, which is that the ID of the service description block changes if/when you change the name of the service, which would not be true if you used a separate name property. But let's let Manu formulate his proposal and have the discussion there. (Also, mea culpa for still not having developed my own PR for service selection; I just emailed Manu about trying to coordinate that this week).

…

On Sun, Apr 22, 2018 at 9:47 AM, Markus Sabadello ***@***.***> wrote: How is this error prone? Also, my understanding is that in the DID resolution process, no URL is ever "constructed", only parsed. What else would you use the semicon for? (Yes we can move this discussion to a PR when there is one). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#72 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADLkTe4mbxIVE5LAqWUwGrsNeyLON88eks5trLQpgaJpZM4Te7Ox> .

[msporny]

How is this error prone?

If you set id to did:v1:1234567;messaging and name to messages, then what would be the appropriate thing to do when someone writes did:v1:1234567;messaging/foo/bar#frag? You have several options, and all of them result in more complicated processing rules.

The suggestion is to reduce the complicated processing rules by reusing id for the purpose for which it was intended (identifying graph nodes -- in this case, service descriptions).

Also, my understanding is that in the DID resolution process, no URL is ever "constructed", only parsed.

Software that builds DID-based paths may use services to construct URLs that are then passed to the DID resolution process in another system. It's the first part that may be concerning if the id and name didn't match. Rather than depend on two properties for constructing and destructuring service-based URLs, we gain simplicity by just using id, which meets all of our requirements, IIUC.

What else would you use the semicon for?

We may want to build other sorts of opaque strings from DID-based URLs in the future. While we don't have a very strong use case to do that right now, if we use name, we are painting ourselves into a corner. If we just use id, we don't paint ourselves into a corner AND meet all of our current requirements.

[msporny]

at least one downside, which is that the ID of the service description block changes if/when you change the name of the service

I'm not following why that's a downside, can you elaborate? For example, if the name of the service changes, wouldn't you expect folks to use the new name for service-based URLs? If we use id, we can still have two different "names" point to the same service endpoint (which enables a smooth upgrade path from old to new).

To put it another way, what's the advantage/use case for being able to use a name that is independent of id?

[talltree]

On Sun, Apr 22, 2018 at 4:17 PM, Manu Sporny ***@***.***> wrote: at least one downside, which is that the ID of the service description block changes if/when you change the name of the service I'm not following why that's a downside, can you elaborate? For example, if the name of the service changes, wouldn't you expect folks to use the new name for service-based URLs? If we use id, we can still have two different "names" point to the same service endpoint (which enables a smooth upgrade path from old to new). To put it another way, what's the advantage/use case for being able to use a name that is independent of id?

Ironically, I wrote that because reading the proposal triggered my instinctive reaction to any design that conflates a "persistent identifier" with a "reassignable name". Due to my two decades of trench warfare in identifierland, I have learned the wisdom of drawing a very clear line between the former—an identifier assigned to an entity that never needs to change (forever)—and the latter, which is an identifier that may change over time. To be extreme, this is the difference between a UUID and a domain name—the former typically designed to be assigned once and work forever, vs. the latter which can be assigned to one entity today and bought and reassigned to another entity tomorrow. So what I wrote was just a knee-jerk reaction to conflating the purpose of the id: property of a service block (persistent ID) with the purpose of the name: property (reassignable ID). All that said, I really haven't thought this through closely when it comes to identifying & selecting service blocks within a DID document, so please do write up your proposal and let's take look.

[msporny]

Surface this with the group once a PR is in place.

[msporny]

PR #75 is in place... community should discuss.

[kimdhamilton]

The semicolon syntax is not mentioned in this section: https://w3c-ccg.github.io/did-spec/#decentralized-identifiers-dids

Do we need to call that out, or is that not needed (due to DID schemes being a RFC3986-conformant URI scheme)?

[msporny]

The semicolon syntax is not mentioned in this section: https://w3c-ccg.github.io/did-spec/#decentralized-identifiers-dids

You're correct... that fix is waiting on an issue to be raised from @talltree to add services to the DID syntax and then a PR from @talltree to add it.