Use an exact match for backwards-compatible-json.

[MarkLodato]

Previously the doc said it was a prefix match, but that is both error-prone and slightly complex. It is safer and easier to use an exact string match. We use a magic URI so that it may optionally serve documentation for this format.

Also add a warning that backwards compatibility should be disabled by default.

Closes #5.

[trishankatdatadog]

Thanks, Mark! I think we should use a different domain than in-toto.io because the spec is shared by both TUF and in-toto, so perhaps an independent domain that is less confusing on first glance to developers, but that is a relatively minor concern that can be addressed.

[MarkLodato]

Do you have a suggestion for what domain to use? Alternatively, if there is no natural domain to use, we could go back to the non-URI string to avoid the issue.

[trishankatdatadog]

Do you have a suggestion for what domain to use? Alternatively, if there is no natural domain to use, we could go back to the non-URI string to avoid the issue.

http://wiki.laptop.org/go/Canonical_JSON (which is not HTTPS but hey)

[MarkLodato]

Hmm, that doesn't indicate that it's specific to backwards compatibility with in-toto and TUF.

What do you think about avoiding magic "payloadType" altogether and instead having an explicit "mode" field? That would sidestep the question and hopefully be more explicit. Something like:

{
  "payload": "...",
  "mode": "backwards-compatible-json",  // or perhaps "tuf v1" / "in-toto v1"
  "signatures": [...]
}

I'll send out an update so we can see what that looks like.

[SantiagoTorres]

Thanks, Mark! I think we should use a different domain than in-toto.io because the spec is shared by both TUF and in-toto, so perhaps an independent domain that is less confusing on first glance to developers, but that is a relatively minor concern that can be addressed.

That's why I was thinking of using the secure systems lab domain https://ssl.engineering.nyu.edu/cjson or https://github.com/secure-systems-lab/cjson or so would do wouldn't it?

[adityasaky]

That's why I was thinking of using the secure systems lab domain https://ssl.engineering.nyu.edu/cjson or https://github.com/secure-systems-lab/cjson or so would do wouldn't it?

That sounds good to me. :)

[trishankatdatadog]

That's why I was thinking of using the secure systems lab domain https://ssl.engineering.nyu.edu/cjson or https://github.com/secure-systems-lab/cjson or so would do wouldn't it?

Yes, we really should move our canonical JSON code to its own github repo, like Docker did for its own implementation. Leaves things super unambiguous.

[SantiagoTorres]

Yes, we really should move our canonical JSON code to its own github repo, like Docker did for its own implementation. Leaves things super unambiguous.

I like the idea. We could also just write down a small readme file describing how we differentiate (disambiguate stuff from?) OLPC

[MarkLodato]

I put together a draft version that does away with the magic URI, replacing it with an explicit sigType field:
https://github.com/MarkLodato/signing-spec/blob/sig-type/specification.md

If you get a chance, please take a look to let me know what you think. If you all think it's a good idea, I'll update this PR to go that route instead.

[trishankatdatadog]

If you get a chance, please take a look to let me know what you think. If you all think it's a good idea, I'll update this PR to go that route instead.

I don't feel strongly either way, so would you please briefly describe pros vs cons of each?

[MarkLodato]

If you get a chance, please take a look to let me know what you think. If you all think it's a good idea, I'll update this PR to go that route instead.

I don't feel strongly either way, so would you please briefly describe pros vs cons of each?

Benefits of signature.sigType:

• More explicit and obvious. No need to know that some magic payloadType invokes special behavior.
• Provides a natural path for future versions, say if we need to add a new authenticated field.
• Allows mixing of backwards-compatible and "new" signatures in the same file.

Benefits magic payloadType:

• No chance of the verifier using the unauthenticated payloadType because it doesn't exist.

[trishankatdatadog]

Thanks for the enumeration, Mark! Let me sleep on this (it's 3AM here) and get back to you, please...

[SantiagoTorres]

I'm personally leaning towards the first option...

[MarkLodato]

I sent out #13. My preference is to drop this PR (magic payloadType URI) and instead go with #13.

[adityasaky]

Closed in favour of #13.