Support DIDs as serviceEndpoint?

[peacekeeper]

One of DID Resolution's main purposes is to discover a serviceEndpoint URL for a DID, e.g.:

{
   "id": "did:example:123456789abcdefghi;hub1",
   "type": "HubService",
   "serviceEndpoint": "https://hub.myhost.com/1234"
 }

We could also support DIDs as the value for serviceEndpoint, e.g.:

{
   "id": "did:example:123456789abcdefghi;hub1",
   "type": "HubService",
   "serviceEndpoint": "did:example:xyz"
 }

This could serve as a "redirect", i.e. a resolver would execute a second ("child"?) resolution process to now resolve did:example:xyz in order to find an actual serviceEndpoint URL.

One advantage of this pattern would be that many DIDs could be updated effectively by updating a single DID Document.

[msporny]

Agreed that this would be a good feature. I don't think the did-spec prevents this at present... serviceEndpoint is syntactically any URL (where a DID is a type of URL). That said, we should detail this feature in the spec so that people know about it.

[csuwildcat]

The pattern we are thinking is that users add IdentityHub type descriptors to their DID Doc that specify a Host DID as the serviceEndpoint value, which, when resolved, leads to the Host's DID Doc, wherein there is an IdentityHubHost service descriptor with whatever actual endpoint the Host's instance resides at.

[peacekeeper]

Okay.. I'm wondering if this "DID redirect" pattern should be handled internally by a resolver, i.e. would an application invoke the resolver once and it would automatically start a child resolution cycle to follow the DID to the final result, or would an application invoke the resolver twice to find what it's looking for. I could see it both ways, or maybe configurable as resolver parameters.

[msporny]

would an application invoke the resolver once and it would automatically start a child resolution cycle to follow the DID to the final result, or would an application invoke the resolver twice to find what it's looking for.

I suggest we follow the pattern that curl uses for HTTP 301 Redirects. By default it doesn't redirect, but if you pass it the -L --location flag, it will follow the redirect. I'll also note that doing this will require clients to determine when they're in an endless redirect loop (e.g. through a simple redirect counter).

[talltree]

I agree with Manu that this is something we should call out in the editorial portion of the DID spec under the Service Endpoint section.

Note: in the third week of August I can schedule doing an editorial pass on the DID spec to catch these and other items I have been tracking.

=D

On Tue, Jul 31, 2018 at 6:17 AM, Manu Sporny notifications@github.com wrote:

Agreed that this would be a good feature. I don't think the did-spec prevents this at present... serviceEndpoint is syntactically any URL (where a DID is a type of URL). That said, we should detail this feature in the spec so that people know about it.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/did-resolution/issues/7#issuecomment-409217247, or mute the thread https://github.com/notifications/unsubscribe-auth/ADLkTaHuPunumsk2b6psNsPqqTMW4qnxks5uMFjdgaJpZM4VnwrU .

[TomCJones]

calling a did a service endpoint creates some conflict with the existing use of the term on the web. Service endpoints in all standards of which i am familiar require use of https:// scheme. I know that there is general disdain here for existing standards, but am just trying to avoid unnecessary confusion.

[dmitrizagidulin]

@TomCJones - can you say more about that? How does calling a service endpoint create conflict with existing standards?

[msporny]

I know that there is general disdain

That's a strange thing to say since a LOT of the work we're doing is built on top of existing standards (both W3C, ISO, and IETF). Can you elaborate?

[dmitrizagidulin]

I agree with @msporny that a) this is good feature (though not super urgent, I think?), and b) that it should follow existing redirect conventions (like curl).

Except that I think it should actually follow WHATWG fetch redirect convention, that is - default behavior is for the resolver to transparently redirect, unless disabled. (And count redirects so as to prevent loop, etc.)

[dlongley]

We're also interested in a similar proxy/redirect feature that would help offload potential GDPR issues. A service with a type of SomeProxyThing (TBD) and a service endpoint with an opaque address could redirect to another document with service descriptions that are not on an immutable ledger.

[TomCJones]

@dmitrizagidulin I must have been unclear in my comment which was meant to help direct the evolution of the use of a service endpoint. I know how to process and secure a service endpoint that uses the scheme https://. I would not understand the meaning or (or know how to process) a service endpoint with scheme did:

[TomCJones]

Your statement is not part of the spec. My suggestion was that if end points are defined that the scheme MUST be https://. I am trying to add rigor to the spec.

[jandrieu]

A service endpoint should be able to be any valid URL. Which would include DIDs. Which allows a fairly useful trick for forwarding an endpoint from one DID to an endpoint in another.

[TomCJones]

I disagree with that statement for the reasons I gave above.

[ChristopherA]

I believe there will be a lot more schemes in the future besides https (and I am a co-author of https). Just because browsers today focus on that, it is not the long-term — Mozilla in new dev builds allows new schemes to be supported specifically so they can support web3 ideas.

Thus any resolvable URL could be an endpoint, and since a DID is a resolvable URL, it could be too. Not something I plan to support in near future, but should not be prohibited.

[peacekeeper]

@csuwildcat Wasn't it you who originally suggested this feature? So that e.g. many users of a shared hub service provider could just point to the hub service provider's DID in their DID document, instead of pointing to the actual HTTPS endpoint. And then the hub service provider's DID document would have the final HTTPS endpoint. This way the hub service provider could change their service endpoint, without having to update the DID documents of every single user?

[csuwildcat]

@peacekeeper yeah, good point, there is a double resolution from user DID to Hub DID and its related http (and possibly non-http) endpoints. Not sure how I forgot that 🤦‍♂️

I definitely don't understand/agree with Tom's "HTTP must be the one and only" argument, given new protocols like IPFS are already becoming prevalent.

[msporny]

"HTTP must be the one and only"

Strong -1 to HTTP-only for all the reasons mentioned by @csuwildcat and @ChristopherA ... services should be protocol agnostic.

[TomCJones]

I am strongly supporting only secure connections for service end points. The one that is well known and well supported today is TLS. Roll your own security is a known vulnerability. Let's avoid known vulnerabilities.

[csuwildcat]

@TomCJones please note we have one of the co-author's of the TLS spec working in this group, who has already commented on this thread.

Also realize DIDs provide a new means of highly secure connections between peers: the ability to do standards-based cryptographic connections/exchanges using keys that are provably backed by the party you intend to communicate with. This is a much more secure means of connection than schemes based on trusting a set of central authorities who are constantly competing with each other to see who can be featured in more "You had one job" memes.

[ChristopherA]

On Fri, Jan 25, 2019 at 9:28 AM tom jones notifications@github.com wrote:

I am strongly supporting only secure connections for service end points. The one that is well known and well supported today is TLS. Roll your own security is a known vulnerability. Let's avoid known vulnerabilities.

Endpoints are not a required part of the spec. You don't have to support any that you don't want until you feel they are mature. But onion: and richochet: are both strongly reviewed schemes and certainly has some security, IPFS may in near future, and more from W3C and IETF will be emerging.

-- Christopher Allen

[TomCJones]

I don't need the lectures, I owned crypto for windows at one time. The security around dids only applies to messages from the key owner, not to any other messages. That security will not apply to any redirects or other messages. I have no way to know what is required by the spec, there is no indication of which parts are normative. If the spec does not come with a security section, it will not get accepted. I suspect when you get to writing the security section all of these issues will arise again. Since security is not a concern of the group, this will be my last message.

[jandrieu]

Restricting a service endpoint to a single, current URL scheme would not only make the spec future-brittle, requiring https would tie us to the very certificate infrastructure we are working to fix. Why refuse the decentralized cryptographic foundation of DIDs for service endpoints? Any valid URL, by definition, describes how to resolve it. It's up to DID controllers to decide which protocols best meet their service requirements.

[peacekeeper]

@TomCJones Nobody ever proposed to encourage or support non-secure connections for service end points. This is not what this Issue is about. Having a DID as a service endpoint in a DID Document doesn't mean that there would be any insecure messaging. I agree with you that a Security section of the spec should address this case in detail.

I think you have valuable input on this and other Issues, and I hope with your help and experience we can make the specs better and more secure. But at the same time you need to stop provoking us with (false) statements about a "general disdain here for existing standards" or that "security is not a concern of the group".