HTTP POST method binding

[sloops77]

The current binding for DID resolution uses HTTP GET method. This has a drawback:

1. There is a maximum character limit for URLs which, while it varies, it is possible there will be issues with URLs that are longer that 4000 characters long due to issues with servers and firewalls trying to protect them from CVEs. DIDs are sometimes quite long and it would be nice that HTTPS resolvers are made safer for longer DIDs. For example see https://nvd.nist.gov/vuln/detail/CVE-2017-1000100
   and https://stackoverflow.com/questions/6304397/long-urls-with-more-than-4095-characters-in-php

Please consider adding in an alternative HTTPS binding to use POST

[peacekeeper]

Thanks, yes this topic has come up in the past, let's discuss.

[peacekeeper]

I think there is also something that needs to be discussed with regard to the current HTTPS GET method binding:
https://www.w3.org/TR/did-resolution/#bindings-https

There's a question about how resolution options are passed via the HTTPS binding.

At the moment, the spec says that resolution options are encoded as query parameters in the URL.

But the problem with that is that the values of resolution options can also be complex data structures, see this language in the "Metadata Structure" section:
https://www.w3.org/TR/did-resolution/#metadata-structure

Each property value MUST be a string, map, list, set, boolean, or null. The values within any complex data structures such as maps and lists MUST be one of these data types as well.

An HTTPS POST binding would solve this.

Another approach could be to continue to use GET, but encode the resolution options in a different way than key/value query parameters, e.g. as an encoded JSON object.

Or allow both GET and POST.

[peacekeeper]

1. The content in the path is not encrypted permitting monitoring by third parties of DID resolutions to specific HOSTS undertaken by specific CLIENTS. Using HTTP POST method would prevent such monitoring by including the DID being resolved in the body

I don't really understand this argument. When using HTTPS/TLS, the request URL, headers, and body are all equally encrypted I think.

[w3cbot]

This was discussed during the #did meeting on 17 July 2025.

View the transcript

HTTP Post Binding for DID Resolution

<Wip> w3c/did-resolution#161

markus_sabadello: if a client calls a resolver over https right now this is done using GET, however the issue poster would like to also allow this to be done with POST...

markus_sabadello: There is a potential issue when resolution option parameters are too many this may cause issues with using GET...

markus_sabadello: These issues have to do with HTTPS binding... so the question is do we want replace the GET approach or allow both GET and POST

Wip: What are the good arguments to keep using GET?

markus_sabadello: GET is simpler and it works directly in the browser... Also there are some caching semantics that work better with GET than POST...

<JoeAndrieu> FWIW, The ISO blockahin discussion at GDC was about ISO 23042 (Reference architecture for blockchain-based decentralized identity systems)

<JoeAndrieu> From https://globaldigitalcollaboration.org/agenda?day=2025-07-02

<JoeAndrieu> ---

<JoeAndrieu> Security and Interoperability Standardization for Wallets

<JoeAndrieu> One-hour workshop at GDC 2025 uniting BGIN and ISO experts to present ISO 23042 (Reference architecture for blockchain-based decentralized identity systems) under development and forthcoming wallet-security related standards, showcase BGIN cybersecurity streams, and engage regulators, vendors, and researchers on implementing and managing secure,

<JoeAndrieu> interoperable digital wallets.

<JoeAndrieu> Speakers

Wip: I think then perhaps we should keep both of them

<JoeAndrieu> Julien Bringer (ISO/TC 307/JWG 4, BGIN) Mitchell Traves (BGIN) Carole House (BGIN) Paolo Campegiani (ISO 23042) Shin'ichiro Matsuo (Moderator)

<JoeAndrieu> ---

markus_sabadello: I am interested to hear other opinions but I think we should indeed keep both....

<pchampin> https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-method-w-body.html

markus_sabadello: perhaps GET can be used when you have fewer resolution options and use POST when want to have access to all functionality and not be restricted

<bengo> Oh yes I have been planning to use QUERY for wallet.storage

pchampin: there is also some work on IETF that allows you to add payloads to a query...

pchampin: this could be interesting here

JoeAndrieu: I am not in favor of keeping both because it could harm interoperability. However would like to ask about http and https?

JoeAndrieu: The 4000 character limit is just a platform limitation, I would like to see more examples of GET actually breaking and not being sufficient...

pchampin: I have seen some examples with SPARQL, but this is not a big issue really

markus_sabadello: Yes in SPARQL, both are allowed however Joe might be right that the character limit is not a good argument

markus_sabadello: There could still be ways that we can do resolution without using POST

markus_sabadello: The DID resolution could also be encoded as JSON in the QUERY string

<Zakim> bengo, you wanted to talk about interoperability *of intermediate caching proxies* which is imho where GET/POST is not enough but is critical to scalability which is not something SPARQL endpoints are known for.

bengo: Yes Cloudflare is one of the Authors in that QUERY ietf draft

bengo: You could also use the content-type header....

---

[sloops77]

I don't really understand this argument. When using HTTPS/TLS, the request URL, headers, and body are all equally encrypted I think.

You are correct that everything is encrypted, i've updated the description appropriately

[mccown]

It might be more flexible to allow both GET and POST.

[wip-abramson]

Do we have a direction for the issue, or is this something we should add to the agenda to discuss further?

[peacekeeper]

I am also leaning toward supporting both GET and POST.

We could do the following:

• Leave GET the way it is right now, i.e. no changes, but clarify that is has some limitations, e.g. with regard to character limit, and supporting complex values as options
• Additionally define POST, where you would send the options in the HTTP body.

Anyone opposed to this..?

[sloops77]

Im not strictly against it but adding support for both harms interoperability and adds complexity

Some questions about supporting both:

• Must resolvers support both protocols?
• If not, then can clients discover which http method is supported by the resolver, and if so how?
• If a resolver supports both, the spec should provide guidance when a client should use one or the other

[peacekeeper]

Im not strictly against it but adding support for both harms interoperability and adds complexity

Right.. One idea is maybe to make GET mandatory and POST optional?

[TallTed]

adding support for both harms interoperability and adds complexity

Certainly, more complexity. I think it's questionable whether interoperability is harmed. What do you say about HTTP servers supporting both verbs?

[TallTed]

maybe to make GET mandatory and POST optional?

I think this would harm interop, because it means that clients SHOULD implement both, and MUST have some fallback strategy for when POST fails because the upstream resolver only supports GET and the URL is too long.

[sloops77]

What about making POST mandatory, and make GET optional? It would make new implementations & clients easier, but existing implementations would de facto continue to function

[peacekeeper]

What about making POST mandatory, and make GET optional?

This would break A LOT of existing implementations that only support GET.