-
Notifications
You must be signed in to change notification settings - Fork 10
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
Should the HTTPS binding be mandatory? #93
Comments
This was discussed during the #did meeting on 16 January 2025. View the transcriptw3c/did-resolution#93wip: I'm going to go through these in order starting with Issue 93 markus_sabadello: interesting question, came up in comment earlier in working group related to different issue Wip: I think to me, I know Joe cares about this, if everyobody is exposing http url way to have interoperability <Zakim> JoeAndrieu, you wanted to say I think its methods, not the resolver that has the requirement Wip: challenge when I'm devoting resolvers locally that don't have to be ?? JoeAndrieu: I do think the best route for an ecosystem is for every method to have at least one http resolver so that if you run into such a DID there is a way your software already has the interfaces if there is already a resolver. don't think we need every one to have a binding, but there must be one that has that binding. markus_sabadello: agree with Joe that this is a conversation that happens around interoperability, if you have the https biding you do increase interop . . . where this feels strange is did: key and did:? Very weird to call a remote https endpoint to resolve did:key, who would host and be in charge of deploying a resolver Wip: I think it sounds like a good requirement to ask DID methods to maintain https, not sure where it should go. DID: Core Spec? DID: Resolver? pchampin: point to Markus about did:key, think it would make sense to include a https endpoint, if you don't know the DID method you can rely on ? but you can generate the did document from the DID itself. Not absolutely stupid in my opinion to have this service but suboptimal <Zakim> JoeAndrieu, you wanted to say software not service . . . not sure if we made it a requirement to have an http endpoint, but kind of thing that should be available in DID Method Registry / List, maybe criteria in Rubric, is it usable in one or several? JoeAndrieu: interesting disconnect in the way we're talking about this. I would be very opposed to this, could have a local, didn't realize that if you had to do https locally, that would be annoying. If you had to do did:key, not so much that someone would run a resolver for did:key, but a piece of software, note app or apache app Wip: next steps to move this from discuss to action <Zakim> JoeAndrieu, you wanted to say I don't think a URL for a resolver is the right solution. this, IMO, is a DID method requirement, hence part of did core markus_sabadello: not something that would be part of Method Spec. Think what Joe said was also interesting. Add to Extension Registry where ? Link in Registry to public resolver JoeAndrieu: very opposed to putting live URLs in registry to use for a resolver. Methods themselves, if we want this form of inter, goes into DID:Core - any DID method that wants to be conformant should have one resolver that you can access of HTTP <Wip> https://www.w3.org/TR/did-core/#methods Wip: would also feel uncomfortable putting it in Registry, would think it should go into did-core. But, can we make that change as a group? markus_sabadello: so requirement would be there has to be one piece of software or one implementation <Zakim> bigbluehat, you wanted to ask if we are talking about referencing HTTP software then? or some sort of protocol mapping? Wip: i was thinking more did methods SHOULD bigbluehat: I just want to clarify what we're talking about. When Joe talks about it t sounds like a piece of software, open source did protocol wrapper, which ? easy route would be for me to get that software and communicate over http, never implement more of the value of the DID method. If implementation is one for each method, raises questions Wip: first I will say is I want to move on from the discussion, didn't get to Actions, but appreciate if people can add their next steps to Issue. Could this be a pathway to interoperability to resolve it without having to implement ? kind of a fallback. Unless any final comments, would like to move on <pchampin> +1 to consider those as fallbacks |
This is a concrete question that has been identified in #83 (comment) and #83 (comment) on the question whether the HTTP(S) binding should be mandatory to implement.
What does mandatory mean in this case? Does this affect resolver, or DID methods, or something else?
The text was updated successfully, but these errors were encountered: