Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support "proxy" service type? #35

Closed
peacekeeper opened this issue May 5, 2019 · 3 comments
Closed

Support "proxy" service type? #35

peacekeeper opened this issue May 5, 2019 · 3 comments
Labels
enhancement New feature or request pending-close Issue will be closed shortly if no objections

Comments

@peacekeeper
Copy link
Collaborator

Keeping track of a proposal here w3c-ccg/did-spec#90 (comment) that a DID Document could contain a "proxy" service type which would provide a mapping that needs to be followed in order to resolve to a final service URL.

@pchampin
Copy link
Collaborator

This was discussed during the did meeting on 17 October 2024.

View the transcript

w3c/did-resolution#35

markus_sabadello: I opened this a five years ago, there was an issue in the DID spec about potential privacy concerns associated with data in the DID Document itself, like service endpoints, idea was that if you include service endpoints, endpoints could be sensitive or correlatable, idea was to introduce a proxy service type where you could look up what is normally in the DID Document but use a remote service for looking up parts of the DID Document to not
… include correlatable information in the DID DOcument itself. Wonder what we should do with this?

markus_sabadello: We can mark this an enhancement for now... in five years, no one has worked on this, or had a real life need for this.

manu: Dave Longley wrote something about this, I don't think we have anyone working on that right now.
… We have a number of DIDs floating on the Web, and people use those DIDs to discover how to interact with the DID controller.
… But this is not how things operate now; DID controllers identify with their DID, then use some web service to start an interaction.

markus_sabadello: I agree, if anyone ever specifies/implements this, it's a service type so just like defining a different service type like DIDComm or OpenID, so probably be in a separate spec anyway and registered as an extension. Doesn't feel like something that needs to be in DID Resolution itself.

Wip: How do we process this issue? "lacks interest"?

markus_sabadello: I opened this, could add comment -- this could be useful as an extension, but doesn't need to be in DID Resolution.

Wip: That's all we have time for today, any particular issues that could deal with some attention next week?

markus_sabadello: Not sure right now, I'll look.


@peacekeeper
Copy link
Collaborator Author

Per yesterday's discussion, and considering that there hasn't really been any implementation related to this idea in the last few years, I now believe that this can be fully supported at some point by a separate specification if there is demand, but there is not really a need to include this in the DID Resolution spec. I therefore think that this can be closed.

@peacekeeper peacekeeper added the pending-close Issue will be closed shortly if no objections label Oct 18, 2024
@peacekeeper
Copy link
Collaborator Author

Closing after today's DID WG meeting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request pending-close Issue will be closed shortly if no objections
Projects
None yet
Development

No branches or pull requests

2 participants