Inconsitencies between the in-toto specification and reference implementations: to `_name` or to `name`, that is the question

[adityasaky]

• The in-toto specification defines _name for step names in both layouts and links. However, our implementations use just name, and this is what we see in all existing metadata. Incidentally, some of the examples in the specification use name too. As I understand, the underscore was to ensure the type and name show up first, but there has also been other discussion about the right ordering of fields in in-toto metadata.

  • _name in steps: https://github.com/in-toto/docs/blob/master/in-toto-spec.md#431-steps

  • _name in links: https://github.com/in-toto/docs/blob/master/in-toto-spec.md#44-file-formats-namekeyid-prefixlink

  • name in example in spec: https://github.com/in-toto/docs/blob/master/in-toto-spec.md#write-codealice-keyid-prefixlink

• The specification has the inspections field with the key inspections but our implementations and existing metadata use inspect.

[lukpueh]

I'm in favor of fixing the spec, i.e. _name should become name in the spec. IMO field display order should be handled elsewhere, e.g. in an in-toto pretty-print --format-<XYZ> tool (see https://github.com/in-toto/in-toto/issues/18 and #5). Especially since neither JSON nor Python dict keys are strictly alphabetically ordered.

[adityasaky]

I noticed another inconsistency:

The specification has the inspections field with the key inspections but our implementations and existing metadata uses inspect.

[shibumi]

This should be fixed with the latest PR. Can we close it? @adityasaky @SantiagoTorres

[adityasaky]

Yessir. Thanks for working on it, @shibumi!