AuthZ Group - special meeting about UCANs, ReCaps, CACAOs and IPLD syntax/interop

[bumblefudge]

23 Nov - Special Session - UCAN/ReCap

Context

• Discord chat
• Recap
  • Eth Magicians discussion
  • https://github.com/ethereum/EIPs/pull/5573/files
• UCAN
  • https://ucan.xyz/
  • https://github.com/ucan-wg/spec/discussions

PRs to refine/move to close

• N/a ?

Ongoing projects/topics

• Moving Recaps towards being able to express UCANs?
  • brook: history of syntax changes (<-- current verbose form came from... can't quite remember whom?); looked more like recaps before
  • brook: JSON<>IPLD issue (unique keys not detected by some JSON tooling?)
  • current state: array of objects that each point to a UCAN triple; new proposal: nested rather than flat structure (caps nested under each resource, recap-style)
    • issue is duplicate keys in json --> sketchy canonicalization

example of proposal UCAN syntax:

{
  //...,
  att: [
    {
      'example.com': {
        "crud/read": {},
        "crud/create": {
          "mime": "jpg"
        }
      }
    }
  ]
}

proposal Rebase syntax

{
   "def":[
      "read"
   ],
   "tar":{
      "my.resource.1":[
         "append",
         "delete"
      ],
      "my.resource.2":[
         "append"
      ],
      "my.resource.3":[
         "append"
      ]
   },
   "ext":{
       "parentCapability": "bafybeigk7ly3pog6uupxku3b6bubirr434ib6tfaymvox6gotaaaaaaaaa"
   }
},
{
   "def":[
      "read"
   ],
   "tar":{
      "my.resource.4":[
         "append",
         "delete"
      ],
      "my.resource.5":[
         "append"
      ],
      "my.resource.6":[
         "append"
      ]
   },
   "ext":{
       "parentCapability": "baakrwer7ly3pog6uupxku3b6bubirr434ib6tfaymvox6gotaaaaaaaaa"
   }
}

Rebase status quo for multiple namespaces:

example.com wants you to sign in with your Ethereum account:
0x0000000000000000000000000000000000000000

I further authorize https://example.com to perform the following actions on my
behalf: (1) example1: read for any. (2) example1: append, delete for
my.resource.1. (3) example1: append for my.resource.2, my.resource.3. (4)
example2.biz: read for any. (5) example2.biz: append, delete for my.resource.4.
(6) example2.biz: append for my.resource.5, my.resource.6.

URI: https://example.com
Version: 1
Chain ID: 1
Nonce: n-0S6_WzA2Mj
Issued At: 2022-06-21T12:00:00.000Z
Resources:
- urn:recap:example.com:eyJkZWYiOlsicmVhZCJdLCJ0YXIiOnsibXkucmVzb3VyY2UuMSI6WyJhcHBlbmQiLCJkZWxldGUiXSwibXkucmVzb3VyY2UuMiI6WyJhcHBlbmQiXSwibXkucmVzb3VyY2UuMyI6WyJhcHBlbmQiXX19
- urn:recap:example2.biz:eyJkZWYiOlsicmVhZCJdLCJ0YXIiOnsibXkucmVzb3VyY2UuMSI6WyJhcHBlbmQiLCJkZWxldGUiXSwibXkucmVzb3VyY2UuMiI6WyJhcHBlbmQiXSwibXkucmVzb3VyY2UuMyI6WyJhcHBlbmQiXX19

• Joel will propose a Rebase syntax PR that avoids having to namespace arbitrarily by example / URN prefix segment
• Brook: Use case for targets being so open as opposed to constraining to URIs to match UCANs more easily?
  • Chunny: have to confirm our use-case internally is unaffected by URI requirement, but i think it would work fine; human-readability may have been the main or only factor driving this design, i'll ask around
  • Brook: I'd love to hear about any use-case that breaks or is stymied by the URI constraint, if you find one post it or DM it to me plz
• Update from Brook re: ZCaps: non-DID principles in ZCaps (example.com)
  • example.com wouldn't allow redelegation...
  • Chunny: If example.com could resolve a key, couldn't you delegation offline/OOB? Brook: What method? Chunny: Maybe something undocumented, only requires the application to have a map, undocumented behavior... Brook: but don't DID methods exist to document that behavior? When I said "wouldn't allow" I meant wouldn't be predictable or deterministic, just private
  • Joel: SIWE and ReCaps don't really force that decision since they're already constrained to something very did-like (i.e. did:pkh:eip155)
  • { Juan was distracted and took no notes about how a binary representation is needed for all of this to be translated to IPLD unambiguously }
    • Joel: binary representation of a DID ?
      • where put spec for this representation, tho? A CAIP? UCAN repo? A new CAIP repo with new IP boundary?
      • Brook: Sep repo works for me, why not DIF? Juan: I can help but sometimes joining DIF is a hurdle for certain kinds of contributors; Brook: DIF can accept donation later if clean enough IP, right?
      • Brook: Sep repo with CLEAN IP in case it needs to move to some place like DIF later?
      • Maybe CASA is fastest short-term - Brook can make the repos
        • /varsig+canonicalization_sniffing_prefix and /binary-dids repos?
        • /multi-canonicalization thread might be a repo some day
        • [x] @oed will copy-pasta varsig setup to `/binary-dids
  • Joel: But maybe leaving both identifiers and cap interpretation up to application is fine (partic for an EIP)...
  • Chunny: ZCap spec may have gotten a PR about this recently, can't remember
  • duplicate keys anywhere would create duplicate keys in flattened IPLD canonical version, tho
    • might be easier to discuss after joel's got a strawman PR open for this - reminder to consider duplicate keys/blank-node problem
• Sam: Where discuss recap generally?
  • keep it in CASA for UCAN interop? keep it in eth magicians for maximum visibility?
  • Joel: ucan github for ucan stuff, eth mag thread is already poppin, leave casa for pinging?
    • Sam: SGTM
    • brook: the EIP itself looks early, does recap have a repo to watch or something?
      • Sam: the EIP PR works, but we can try to remember to post in CASA when
      • Joel: we're scheduled to work on a java recap library next year, so we'd be posting about it
      • Chunny: we're doing it in rust but so far it still transpiles just fine to WASM (in a bundle with other stuff)