Encrypted serviceEndpoint values?

[dmitrizagidulin]

Would it be possible to add a mechanism for encrypting the value of either a) serviceEndpoint URLs, or b) both serviceEndpoint and service types?

Context: this came up in the context of the Solid spec, where there's interest in adopting the DID Document mechanism to replace or augment the existing WebID Document mechanism. One of the service endpoints that Solid webid docs use is to point to the OpenID Connect Issuer endpoint (similar to how we have OpenIdConnectVersion1.0Service type endpoint in the DID spec examples).
And so, the question that came up was: so right now we point to the user's OIDC endpoint in plain text. Would it be possible to obfuscate or encrypt this, instead?

I realize that this opens up a lot of really difficult topics, like how to combine encryption and access control (so that the DID Doc is still useful for discovery, but not for everybody, only for those who have appropriate keys/credentials).

I'm curious if others have came up against this use case or requirement, and how you're thinking of handling it.

[dmitrizagidulin]

Related issue: #25 - (Partially) Encrypting DID Documents

[dlongley]

I think this problem would be better solved with a layer of indirection. So, specify some generic looking proxy service in your DID Document -- and it can map to something else where encryption (or whatever) can take place.

[dmitrizagidulin]

@dlongley I agree; that sort of privacy-preserving proxy will be a useful mechanism. I'd love to have at least a straw proposal of what that would look like (and what the protocol would be for interacting w it).

[peacekeeper]

@dlongley

.. specify some generic looking proxy service in your DID Document -- and it can map to something else

This has also come up in DID Resolution: https://w3c-ccg.github.io/did-resolution/#proxy, w3c-ccg/did-resolution#35. I think it's a good idea to support something like this. Not sure if any change is needed to the DID spec itself.

[dmitrizagidulin]

Recommend we close this issue.
As mentioned in earlier comments, this use case can be solved either via:

1. An anonymizing service endpoint proxy
2. Encrypting via a Hashlink or similar mechanism; out of scope for the DID Doc.

[jonnycrunch]

so, from my comments on the DID resolution calls, we have been overloading the #frag to add decryption data to handle this.

[dmitrizagidulin]

@jonnycrunch Good point.

Although the idea of this issue is not just encrypting the contents of the linked-to resource, but encrypting the link itself. Does ipld's usage of the hash fragment cover that use case?

[brentzundel]

marked pending close for over a week. Not seeing objections to close. Closing.