Consider using same data model across raw and cbor codecs

[Gozala]

@aschmahmann suggested following

Yes, my thinking was that IIUC the JWT has the data in it as bytes and when you call "parse" you're turning it into something manageable that you're able to treat the same as the dag-cbor version which means you're able to move the JWT UCAN data into the IPLD data model (since dag-cbor covers a subset of the data model).

Which would be neat, although there are some tradeoffs to consider. I imagine it could be modeled as follows

type struct UCAN {
 version String

  issuer SigningKey
  audience SigningKey
  signature Signature

  payload Payload

  capabilities [Capability]
  proofs [&UCAN]
  expiration Int

  facts [Fact]
  nonce optional String
  notBefore optional Int
} representation map {
  field facts default []
  field proofs default []
}

type union Payload {
  | Derived Null
  | Attached Bytes
}

type Capability struct {
  with Resource
  can Ability
  -- can have arbitrary other fields
}

type Fact { String: Any }


-- The resource pointer in URI format
type Resource = String

-- Must be all lower-case `/` delimeted with at least one path segment
type Ability = String

-- Signature is computed by seralizing header & body
-- into corresponding JSON with DAG-JSON (to achieve
-- for hash consitency) then encoded into base64 and
-- then signed by issuers private key
type Signature = Bytes

-- multicodec tagged public key
-- 0xed       Ed25519
-- 0x1205     RSA
type SigningKey = Bytes

General idea is that dag-ucan will issue UCANs with "Derived" signing payload and effectively omit it. While UCANs in the wild who's signatures can't be derived (because of whitespaces, key order etc...) will include those. So jwt-ucan or whatever would be able to decode from raw JWT bytes into such model and leave signature out if it can be derived or capture otherwise.

[Gozala]

My main hesitance here is that malicious actor could exploit this and create a fake block in which capabilities encoded in payload may not match capabilities in the model. Encountering such a faked CBOR block

1. CBOR codec will decode block that has fake payload
2. Schema will validate
3. Signature validation against payload will check
4. Attacker will be able to escalate capabilities

Note that this can not happen with the current setup because payload is simply derived from the model.

[Gozala]

Above is also why I think jwt-ucan that decodes from RAW JWT into anything other than bytes is going to be problematic, because non of the fields of the model could be trusted and need to be compared to what's in the JWT at which point there is no point of decoding.

[Gozala]

I'm closing this as due to outlined problems it seems like a bad idea.