Cybersecurity-LINKS / json-proof-token

JSON Proof Token (JPT) library in Rust. Implementation of the new JOSE WG drafts: JSON Web Proof (JWP), JSON Proof Token (JPT) and JSON Proof Algorithms (JPA).
Apache License 2.0
2 stars 0 forks source link

Ambiguous JSON path when keys include special characters #1

Open abdulmth opened 9 months ago

abdulmth commented 9 months ago

One edge case I came across is on JwpPresentedBuilder.set_undisclosed not supporting special characters in JSON. For example, the following is a valid JSON:

    let custom_claims = serde_json::json!({
        "degree": {
            "type": "BachelorDegree",
            "name": "Bachelor of Science and Arts",
            "ciao.": [
                {"u1": "value1"},
                {"u2": "value2"}
                ]
            },
        "name": "John Doe"
    });

But I don't think there is a way to access or deal with the value ciao.. Same probably with characters like [..] when they're included in keys.

One way we dealt with this issue in https://github.com/iotaledger/sd-jwt-payload is using a string array. This had its limitations, like not being able to access values inside arrays. Another solution could be by using JSON path, but that might not be straight forward to implement.

AlbertoSvg commented 9 months ago

@abdulmth Thank you for your feedback! What you have found is certainly a problem, but I'm not sure if the solution used here https://github.com/iotaledger/sd-jwt-payload is usable in this context as I need to handle flattened JSON. That is, when I need to call the function JwpPresentedBuilder.set_undisclosed, the reference JSON will no longer be:

{
  "degree": {
  "type": "BachelorDegree",
  "name": "Bachelor of Science and Arts",
  "ciao": [
      {"u1": "value1"},
      {"u2": "value2"}
   ]
  },
  "name": "John Doe"
}

but will be:

{
  "degree.type": "BachelorDegree",
  "degree.name": "Bachelor of Science and Arts",
  "degree.ciao[0].u1": "value1",
  "degree.ciao[1].u2": "value2",
  "name": "John Doe"
}

The fundamental problem lies in the handling of flattening, which, as implemented, does not handle the possibility that keys may contain the "." character or "[]" characters used as separators during the flattening and unflattening process.

Maybe exploring this https://datatracker.ietf.org/doc/html/rfc6901#section-4 could be interesting. Applying the evaluation process used here during flattening and unflattening might be a potential solution, less complicated than JSON paths. What do you think?

abdulmth commented 9 months ago

@AlbertoSvg yes, JSON pointer looks great if it can be used. Then the flattening would be using a standard, which is probably necessary. I will look into using it in the sd-jwt-payload crate too.

abdulmth commented 9 months ago

@AlbertoSvg I wanted to let you know that we decided to use JSON pointer in the sd-jwt-payload crate, it worked well there, thanks for pointing it out 👍🏻

AlbertoSvg commented 9 months ago

@abdulmth Thanks for sharing! Glad to hear the JSON pointer worked well for you. I will try to implement it here as soon as possible as well.