CIP-0115? | CBOR tag definition - ED25519-BIP32 Keys

[stevenj]

This CIP is both desired by Project Catalyst to help define CBOR data structures, and serves also as an example implementation for #752.

Note, the example registry in #752 has matching definitions for these tags, typically a PR would include changes for that file once its been merged.

This is the third of three PRs that should be considered together for context.

See also:

• CPS-0014? | Register of CBOR Tags #751
• CIP-0114? | CBOR Tags Registry #752

Closes input-output-hk#4

---

Rendered proposal on author's fork

[Ryun1]

Should this be its own CIP or could this just be added as a document inside of #752? (once merged)

Just thinking if it is easier to manage if contained in one CIP?

[stevenj]

Should this be its own CIP or could this just be added as a document inside of #752?

Just thinking if it is easier to manage if contained in one CIP?

I didn't think it was normal to keep editing CIPs once they are accepted?

There are a bunch of candidates for tags, this is just a really easy one I need right now.

CIP-19 jumps to mind as well.

I was following the example of the metadata registry CIP-10, So #752 just explains how tags are handled, and that new tags are supposed to include a patch to its registry file.

Also, as another example, I am drafting a new cip for registration of various roles in catalyst. It will define a CBOR data structure and I will probably tag it as well, the CIP will define both the metadata structure, and any specific tags it creates related to it. These tags are used by it, but are not defined by it, so it seems wrong for it to define ED25519 tags which come from CIP-0003.

The alternative is to add a section to the end of CIP-0003 which defines these tags and canonical CBOR encoding, but that would then alter that CIP which has been around for a while.

[rphair]

@Ryun1 @stevenj adding CIPs for tag definitions would be consistent with our precedent for CIP-0068 - for which the metadata and motivation / rationale would be hopelessly more complicated than we could ever simply tabulate in the originally conceived CIP-0067 table to store for each asset label.

Since we've told new asset label (token type) creators to submit new CIPs for any new definitions beyond the first four, it would make sense to do so here... and even more sense if @stevenj your planned introduction of these key/tag definitions can be broken into groups as large as possible, as you already appear to have done here.

On the other end of the complexity spectrum: we were able to "get away with" using a simple JSON array in CIP-0010 because the information stored was simpler, and the details of each entry were colloquial and could be challenged in the PR if necessary (cc @KtorZ). But the information associated with each of these CBOR tag/keys needs more authentication which needs to be documented more officially: so requiring new CIPs does make sense.

@stevenj one thing we needed to stipulate for both CIP-0013 and CIP-0068 (cc @Crypto2099)... to make both of them "extensible"... is to say very clearly that a certain number of initial definitions were supported in the original CIP and then others beyond would follow a specific form. You may already have done this but please keep this "plug-in" convenience as a goal when refining your draft for #752.

... and therefore @Ryun1 that would indeed allow a number of initial definitions to included as suggested in #753 (comment).

[rphair]

@stevenj @Ryun1 - separate question from the last: I'm avoiding tagging this Metadata or Tools until we settle the question asked earlier in #752 (comment).

[Ryun1]

Agreed @stevenj @rphair

lets do new CIPs!

[rphair]

@Ryun1 it does seem like it would be cleaner to have 1 CIP for the framework and 1 CIP for each new set of related keys. We were kind of stuck with CIP-0068 because we had to represent the state of the art until that point... but here we can start fresh, so there's no reason the framework CIP would have to include a "base" set of keys (I'd be happy to leave that to @stevenj this time).

This can be confirmed during Triage at the next meeting where it would be up for introduction anyway (I've put it on the agenda): https://hackmd.io/@cip-editors/81

[Ryun1]

@Ryun1 it does seem like it would be cleaner to have 1 CIP for the framework and 1 CIP for each new set of related keys. We were kind of stuck with CIP-0068 because we had to represent the state of the art until that point... but here we can start fresh, so there's no reason the framework CIP would have to include a "base" set of keys (I'd be happy to leave that to @stevenj this time).

I agree!

[Crypto2099]

Minor personal preference but I would love to see a stripped down template of this CIP as a demonstration for future Tag definition CIPs.

[Crypto2099]

Going to echo some of the sentiment from @rphair and @Ryun1. I love how these three PRs have been drafted to work in unison and provide a "clean" template for how these "registry" types of CIPs/CPSs could be defined in the future. This seems much cleaner than what we have learned through past experience w/ CIP-10, 68, etc.

[rphair]

@stevenj the question posted in #753 (comment) has been answered:

This week's CIP meeting concluded by undisputed consensus that the CBOR Registry related CIPs and CPS are of Category: = Tools (rather than Meta or Metadata) in short because these formats will inevitably be consumed off-chain by a currently unknowable variety of applications.

[stevenj]

Minor personal preference but I would love to see a stripped down template of this CIP as a demonstration for future Tag definition CIPs.

I think this is a good idea and will work on something to that effect.

[rphair]

By my reckoning this now includes @Ryun1's last few spotted improvements & the admonitions (in advance of IANA official assignment of tags) @stevenj was talking about adding at today's meeting. So I believe we are now all set to merge between meetings if other editors approve.

[Ryun1]

good to go!