search

ucan-wg / ucan-ipld

IPLD Schema for UCAN
Other
6 stars 0 forks source link

`iat` field (and others) #10

Open expede opened 2 years ago

expede commented 2 years ago

UCAN core has a philosophical issue with the iat field. We could add support for it, but it will always be ignored because a Byzantine node can lie about that value. However, SIWE/CACAO have included it in their format, and we're working on a compatibility spec at https://github.com/ucan-wg/ucan-cacao/pull/1.

We could add this as an optional field, but this raises a broader question about what to do with arbitrary fields. The core UCAN spec is fine because it's very open about extra fields. The IPLD representation is quite a bit more rigid, and if we want to support arbitrary tokens, then we have three options as I see it:

  1. Treat these UCANs as raw (not directly in IPLD)
  2. Add some kind of ext field in ucan-ipld
  3. Force them to be encoded as facts

Any thoughts @Gozala @oed @hugomrdias?

oed commented 2 years ago

I'm not sure why adding iat would help here. Why does the UCAN format need to support the exact same fields as SIWE? Fwiw, we completely ignore the iat field in our CACAO implementation.

Gozala commented 1 year ago

I think both 2 and 3 seem reasonable to me, in fact https://github.com/ucan-wg/invocation/ seems to already introduce ext field so pushing it down to UCAN makes sense to me.

In terms of 2 and 3 I don't really know, it's not exactly clear what should be considered a fact and what should not. So far I have been thinking about facts along the lines of datomic's datoms, so basically a claim made and signed by the issuer.

Unless we have an unambiguous prescription what goes into fct and what goes into ext having two would only confuse people and cause discussions & disagreements. I think I'm more in favor of 3 since I don't have an unambiguous prescription