Repository navigation
Support "proxy" service type? #35
Description
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.
Activity
pchampin commentedon Oct 17, 2024
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 commentedon Oct 18, 2024
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 commentedon Nov 14, 2024
Closing after today's DID WG meeting.