Are there any JSON encoding rules?

[sbellem]

Quoting from https://www.obj-sys.com/docs/JSONEncodingRules.pdf (2012) by Objective Systems, Inc.:

There is currently no recommendation from ITU-T, or any other standards body of which we are aware, that standardizes JSON encoding rules.

There's a related blog at https://www.obj-sys.com/blog/?p=508

Another company, OSS Nokalva, has a white paper: http://www.oss.com/asn1/resources/books-whitepapers-pubs/JSON%20Encoding%20Rules.pdf (2015).

I do not know how different, how alike, the two above approaches are.

What is crypto-conditions stance on this matter?

---

The current JSON representation of fulfillments in test vectors appears to be somewhat arbitrary, as the current specification does not mention any required JSON representation.

What are implementations to expect?

As an example, if one considers the json field in the following (minimal ed25519) test vector:

{
  "json": {
    "type": "ed25519-sha-256",
    "publicKey": "11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo",
    "signature": "5VZDAMNgrHKQhuLMgG6CioSHfx645dl02HPgZSJJAVVfuIIVkKM7rMYeOXAc-bRr0lv18FlbviRlUUFDjnoQCw"
  },
  "cost": 131072,
  "subtypes": [],
  "fingerprintContents": "30228020D75A980182B10AB7D54BFED3C964073A0EE172F3DAA62325AF021A68F707511A",
  "fulfillment": "A4648020D75A980182B10AB7D54BFED3C964073A0EE172F3DAA62325AF021A68F707511A8140E5564300C360AC729086E2CC806E828A84877F1EB8E5D974D873E065224901555FB8821590A33BACC61E39701CF9B46BD25BF5F0595BBE24655141438E7A100B",
  "conditionBinary": "A4278020799239ABA8FC4FF7EABFBC4C44E69E8BDFED993324E12ED64792ABE289CF1D5F8103020000",
  "conditionUri": "ni:///sha-256;eZI5q6j8T_fqv7xMROaei9_tmTMk4S7WR5Kr4onPHV8?fpt=ed25519-sha-256&cost=131072",
  "message": ""
}

implementations are expected to be capable to:

Create fulfillment from json, serialize fulfillment, should match fulfillment

(source: https://github.com/rfcs/crypto-conditions#test-vectors)

In other words an implementation should be able to consume

{
    "type": "ed25519-sha-256",
    "publicKey": "11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo",
    "signature": "5VZDAMNgrHKQhuLMgG6CioSHfx645dl02HPgZSJJAVVfuIIVkKM7rMYeOXAc-bRr0lv18FlbviRlUUFDjnoQCw"
}

and produce the fulfillment string (hexadecimal):

"A4648020D75A980182B10AB7D54BFED3C964073A0EE172F3DAA62325AF021A68F707511A8140E5564300C360AC729086E2CC806E828A84877F1EB8E5D974D873E065224901555FB8821590A33BACC61E39701CF9B46BD25BF5F0595BBE24655141438E7A100B"

But different implementations could decide to diverge from the JSON representations found in the test vectors.

For example, leaving the content aside, as far as the representation (hex, base64, etc) is concerned, and paying attention to the structure, here are three very reasonable representations:

test vector

{
    "type": "ed25519-sha-256",
    "publicKey": "...",
    "signature": "..."
}

javascript asn1.js

{ 
    "type": "ed25519Sha256Fulfillment",
    "value": {
        "publicKey": "...",
        "signature": "..."
    }
}

python pyasn1

{
    "ed25519Sha256": {
        "publicKey": "...",
        "signature": "..."
    }
}

From an implementation's point of view it may be more convenient to actually stay closer to the representation used by the asn1 library that the implementation depends on, and this could easily lead to all kinds of variants of JSON schemas to represent both conditions, and fulfillments.

It seems to me that it may be worthwhile to attempt to have some kind of JER (JSON Encoding Rules), but I do not know enough about the complications that this may bring.

Lastly, as pointed out by @stevenroose in #10 the representation/encoding would need to be specified.

[stevenroose]

It would be useful to have a standard way to encode crypto-conditions to JSON, but I'm not sure if it's a good idea to enforce it in any way. It might be included in the RFC as a suggestion, though.

[sbellem]

It would be useful to have a standard way to encode crypto-conditions to JSON, but I'm not sure if it's a good idea to enforce it in any way. It might be included in the RFC as a suggestion, though.

Yes, I do not have a preference really. A recommendation would be good enough I think. The main problem and potential confusion for a newcomer is that the current test vectors, are requiring implementations to be able to parse a specific JSON schema, which isn't documented elsewhere.

[stevenroose]

I totally agree that we need to document the JSON in the vectors (you mentioned #10 as well). So yeah it might be an opportunity to define a standard JSON format.

[sbellem]

I totally agree that we need to document the JSON in the vectors (you mentioned #10 as well).

I have a simple README in the works, which I'll try to make a PR for this week.

[ssadler]

A minor painpoint for me is deciding between base16, base64 and base58 encoding. The spec uses a somewhat nonstandard base64 which is not easy to develop against, the vectors include base16. My preference would be either standard base58 or base64. Base58 might be the cleaner choice since it already doens't have any ugly padding chars or anything.

[stevenroose]

I think the de facto standard for binary data in JSON is to use base64 or base64web. I also think most programming languages can easily encode and decode this and it has the lowest data footprint.

On 10 Feb 2018 05:15, "libscott" notifications@github.com wrote:

A minor painpoint for me is deciding between base16, base64 and base58 encoding. The spec uses a somewhat nonstandard base64 which is not easy to develop against, the vectors include base16. My preference would be either standard base58 or base64. Base58 might be the cleaner choice since it already doens't have any ugly padding chars or anything.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rfcs/crypto-conditions/issues/16#issuecomment-364624638, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0F3Fg7WLul8hT6swvltgLSG3y6qPGYks5tTRf7gaJpZM4N3LFw .

[jaromil]

FYI in Zenroom the standard input for binary data is base64, which I advise for. My choice has been also motivated by the universal availability of the base64 encoding utility in standard UNIX CLI environments, which always allows for quick debugging and shell scripted integration tests.

In Zenroom the default can be easily changed prefixing any zencode with a rule:

rule input encoding url64

or

rule input encoding hex

FTR I came across this rather old issue from a code comment in zenroom.py, perhaps it is time to settle the issue and remove the uncertainties.