Support numbers in metadata structures

[peacekeeper]

An issue has come up related to metadata structures:
https://www.w3.org/TR/did-resolution/#metadata-structure

It says:

Each property value MUST be a string, map, list, set, boolean, or null.

This statement references INFRA data types.

It's unclear why

1. The "number" data type is not allowed.
2. Both "list" and "set" data types are allowed.

Should this language be updated? What should be the role of INFRA vs. just using JSON?

@swcurran

[w3cbot]

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

View the transcript

w3c/did-resolution#166

Wip: This is about adding numbers in metadata resolution results.

markus_sabadello: I don't know why we wrote it like this originally.

Manu: I think we did it this way just for completeness, JSON-LD does make a differentation, that is why we have the lists and sets....

Manu: We don't support numbers because if you use floating point numbers there is a chance that it will have failures with digital signatures...

Manu: this could create issues on calculations... so we require floating point numbers to be encoded in a string...

Manu: we can add number back in there, but restrict it to integer... but this would probably open the door to questions about supporting decimals...

<ivan> Infra view on numbers

Manu: So we have resorted to restricting things to strings and the supporting local casting of the string to a number locally...

Wip: is that documented anywhere?

<ivan> +1 to will

markus_sabadello: now I remember, wanted to add that the metadat structure is also used for the input options....

markus_sabadello: so this means that we cannot pass numbers as options in the inputs....

markus_sabadello: I think that makes sense, I remember why we did this now. We can't pass numbers as options in the input, which might be fine -- versionId and other options and metadata fields use strings instead of numbers. Maybe we don't have to change anything.

Wip: We could add some text that explains why numbers aren't supported. That should address this issue.

---

[swcurran]

Reading the transcript, it looks like this is not going to be changed, which I find unfortunate. To be safe in the 0.1% of use cases, we are removing a capability that any reasonable person would expect, rather than adding a line to dissuade anyone from using the "unsafe" use case. Almost no one will use the unsafe values in this context, and in the case they do, the added line would tell them what they are doing wrong. Instead, we have almost everyone being told at DID Test Suite time that their (reasonable) data type requirements are invalid.

That aside, does that mean that the Universal Resolver is going to be updated to make the DID Resolution Metadata "driverDuration" and "duration" items to strings?

[peacekeeper]

I think we should discuss this once more.

@msporny Could you elaborate a bit again why numbers are a problem?

In the DID document data model, we also allow numbers:
https://www.w3.org/TR/did-1.1/#production

In VCs and JSON-LD and Data Integrity, numbers are also allowed.

@swcurran is correct that the Universal Resolver also returns metadata with numbers, and other implementations probably as well.

@wip-abramson Note that e.g. the proposed did:btc1 metadata also uses numbers:
dcdpr/did-btc1#80 (comment)

Also note that resolution options are also defined to be a metadata structure.

[msporny]

@swcurran wrote:

To be safe in the 0.1% of use cases, we are removing a capability that any reasonable person would expect, rather than adding a line to dissuade anyone from using the "unsafe" use case.

Please clearly define the "unsafe" use case. :)

For example, do you expect the entire range of 64-bit numbers to be stored without any loss of precision? What about floating point numbers?

... because those sorts of things will fail on 64-bit -> 32-bit system communication (IoT devices)... or systems that use Javascript (can only support up to 53-bit "integers")... and some of these systems fail silently when you use integers outside of their allowable range.

@msporny Could you elaborate a bit again why numbers are a problem?

https://www.rfc-editor.org/rfc/rfc8785#section-appendix.d

https://www.cs.drexel.edu/~popyack/Courses/CSP/Fa17/extras/Rounding/index.html

The core of the problem here is that, if you want to digitally sign these metadata structures (which people have said they want to do), you will have to lock down how floating point values are operated upon. The variety of hardware that exists out there these days makes this an impossible task. To solve the problem, you would have to know unknowable things about the hardware architecture that your program will be running on (who is serializing the data), but your target float-consuming system is running on as well (who you send the data to). That is, are you running on 32-bit, 64-bit, or 128-bit hardware? At what precision does the programming environment you're using perform floating point operations and serialization? Are the floats on your platform IEEE 754 compliant, or are they posits, or maybe they're being operated on in CUDA cores which are not always IEEE 754 compliant?

We'd have to say something like: "Only use numbers that serialize to the same value across all systems", and that is something that falls into the category of "unknowable things".

Now, if we wanted, instead, to not digitally sign DID Resolution results, then we could allow numbers (integers, floats, etc.).

Keep in mind that I'm talking about the serialization layer here... you can do whatever you want to at the library layer (use native numbers)... but when a resolution result gets serialized... if it uses JSON numbers (without serializing them to strings), you're asking for trouble.

[swcurran]

The type of caveat you propose (something like "Only use numbers that serialize to the same value across all systems") -- along with why that is defined -- the bad things that can happen, notably that the signature may not verify. An implementer would be notified in the specification of what the problem is and the consequence of pushing the limit of using decimals, floating points, doubles, etc.

Presumably it would be safe enough to say 32-bit unsigned integers, as that would open up a large percentage of the likely uses. I image that a decimal carve out could be defined. Having one or both are much better solution than to say -- "don't use numbers", or "stringify/unstringify" all numbers. That makes for a mess. If you are dealing with JSON and numbers that are at risk of serialization/deserialization issues, you are going to already be well aware of the problem. Making it a problem for the entire population is overly pedantic, IMHO.

Other points.

• DID resolution metadata is not signed AFAIK. Why the limit here.
• Verifiable Credential data is signed. Does the same restriction apply?

Is the Working Group aware that numbers play an important role in many aspects of life on Earth?

That last bit was a joke.

[peacekeeper]

Verifiable Credential data is signed. Does the same restriction apply?

I think I have the same question now.. Why is this a problem now in DID resolution metadata, when it was not a problem in VCs or in DID documents?

[msporny]

I think I have the same question now.. Why is this a problem now in DID resolution metadata, when it was not a problem in VCs or in DID documents?

It is a problem in both VCs and DID documents.

[swcurran]

I think putting a "no numbers" limitation into the VC spec would kill it.

Are there any special words in that spec about numbers or is the issue just ignored? If ignored, why not do the same in this spec and make it an SEP -- Somebody Else's Problem?

[msporny]

Are there any special words in that spec about numbers or is the issue just ignored?

The issue isn't ignored, it's there, but it's becoming clear that we need to provide guidance here (given the thread above).

The guidance should probably go in the VC Data Integrity spec, which is what invokes the transformation step that would result in the data loss leading to an invalid digital signature.

Is the Working Group aware that numbers play an important role in many aspects of life on Earth?
I think putting a "no numbers" limitation into the VC spec would kill it.

Let's schedule another discussion in the WG -- we're clearly talking past each other and the jokes (not taking the concerns seriously) and hyperbole is not going to help us get to an understanding on this topic.

[peacekeeper]

+1 to discussing this in the WG again. I feel like we should have a consistent approach for DID documents, VCs, and metadata.

[swcurran]

Good conversation on this topic in the Data Integrity meeting today (Aug. 8), this issue was opened against the DI spec.

I scanned the VCDM spec and didn't find anything precluding the use of numbers in the spec and one example that includes a number. I did find a reference in the spec about handling strings that points to an external document covering internationalization. Maybe we need a comparable spec/document that can be referenced in specs to provide the details about the classes of numbers to "use at your own peril".

[TallTed]

If you are dealing with JSON and numbers that are at risk of serialization/deserialization issues, you are going to already be well aware of the problem.

This kind of approach leads people who are not well aware of the problem (but think they are aware of all problems) to do the exact thing that is the problem, leading to eventual zeroday alerts, which are sometimes issued years after the problematic software shipped.

Further, "avoid xyz" warnings are insufficient, because there is always a new freshman who believes they have a clever solution that allows them to use xyz safely, only to learn (hopefully before graduation) that their clever solution does not provide safety, which was learned by an earlier freshman and their unsafe software deployment.

The warnings MUST be more along the lines of "Do NOT do xyz, because link, link, link. Instead, do zyx, because link, link, link."