Require HTTP GET binding and allow HTTP POST #192
Conversation
ottomorac
requested review from
ChristopherA,
danpape,
dmitrizagidulin,
mccown and
peacekeeper
as code owners
|
@peacekeeper I have initially opted to just add the normative statement requiring GET and allowing POST. I thought the HTTP binding section would be appropriate location for the change but if you think we should make the change in the DID Resolution and Dereferencing Sections directly let me know. Also not sure yet if I need to go into the detailed steps of how the binding can be done with either GET or POST in steps 2 and 4 and how that might affect things like encoding of query params etc. I think let's align on the normative statement first, and perhaps discuss if we need to add the detailed steps as well once we figure that out. |
|
This was discussed during the #did meeting on 18 September 2025. View the transcriptw3c/did-resolution#192Wip: another one from Otto, also about binding. markus_sabadello: it is about adding a POST binding, which we don't have right now. |
Co-authored-by: Markus Sabadello <[email protected]>
TallTed
left a comment
TallTed
left a comment
There was a problem hiding this comment.
Editorial. Improves language and flow.
Co-authored-by: Ted Thibodeau Jr <[email protected]>
|
We will want to align with #182 before merging this |
| <p>This binding is generally considered a <a>remote binding</a>, but could | ||
| also be a <a>local binding</a> if the HTTP(S) endpoint is run in a local environment, such as on <code>localhost</code>.</p> | ||
|
|
||
| <p>All conformant <a>DID resolvers</a> MUST implement an HTTP(S) binding using GET as described in the algorithm below. |
There was a problem hiding this comment.
Does this duplicate text in PR #182: https://github.com/w3c/did-resolution/pull/182/files#diff-0eb547304658805aad788d320f10bf1f292797b5e6d745a3bf617584da017051R2298-R2299
... if so, we shouldn't repeat normative statements because edits to one of them are often missed in the other statement. It is a best practice to follow DRY principles with normative statements.
There was a problem hiding this comment.
Ok good observation @msporny. After some review, I think then we keep the normative text in this PR and then remove some of the redudant text in #182
In #182 I will keep the text about "All HTTPS bindings MUST use TLS".
@peacekeeper do you agree?
There was a problem hiding this comment.
There's the "secure" language that is used in other W3C specs based on "secure contexts" (see: https://www.w3.org/TR/secure-contexts/) that might be able to be leveraged so we don't have to continue to make extra distinctions. This also provides "localhost" treatment.
Co-authored-by: Manu Sporny <[email protected]>
|
This was discussed during the #did meeting on 16 October 2025. View the transcriptw3c/did-resolution#192ottomorac: This PR is related to changes regarding HTTP Get binding. Noting that Manu has highlighted some duplicates with another PR <ottomorac> w3c/did-resolution#182 ottomorac: PR 182, has the duplicate text manu: Sounds good to me Dmitri: reminder that if we are going to require TLS, we need to make an exception for testing purposes in local setups manu: Suggested language, we could say all production deployments must use TLS markus_sabadello: Not sure I am up to date, but is the language now that all conformant DID Resolvers must implement HTTP binding? ottomorac: The language is all conformant DID resolvers must use HTTPS binding with the GET as well as optionally supporting the POST markus_sabadello: To me this doesnt make much sense, a DID resolver that resolves a DID key locally as part of a simple library is also a DID resolver without needing HTTP manu: I agree with Markus. Wondering if we could use the language, all conforming web based DID resolvers. This is about the second conformance class we discussed last week ottomorac: This shifts us to the other issue around conformance class <manu> Wip: Don't like merging something that'll be wrong, especially if it has normative language in. <manu> Wip: This PR will put in a MUST statement that says what Markus has concerns about. <manu> ottomorac: Maybe you MUST if you are working over network and other specifics? manu: Usually bad practice to merge in things that we know are wrong ottomorac: Okay, makes sense |
7 participants
This PR attempts to address #161 by adding a statement requiring that DID resolvers implement HTTP GET bindings and allowing an alternative HTTP POST binding to be used when desired.
Preview | Diff