AuthZ Biweekly Meeting - 24Jan 2023

[bumblefudge]

24 Jan - CACAO/AuthZ Biweekly

PRs to refine/move to close

• n/a

Ongoing issues/topics

• CACAO Overhaul PR
  • Joel: Context: v1 & v2 were driven by SIWX and IPLD determinism, profiling signatures; v3 driven by SIWX + UCANs, mimicking UCAN structure and enabled by varsig
    • Brooklyn: varsig relies on hopefully forthcoming tooling
    • Chunny: prev discussion of CACAO being more precise than SIWX (i.e. timezone info)? time zone stored in fct field?
      • OED: 0xd51e codec roundtrips between IPLD and SIWE message str, including timezone nuances
    • Jacob: timezones as a toplevel optional versus fact semantics? depends what future usecases you're envisioning
    • Jacob: why unix if some usecases require the rfc?
      • OED: unix is standard in most JWT tooling, not rfc, tho
      • Brooklyn: Being able to serialize to a JWT (and losslessly roundtrip back) requires separate field for that extra info
      • Jacob: Do SIWE CACAOs serialize to JWTs? I thought not (losslessly at least); or is it just a transport
      • Brooklyn: at verification time, comparison as unix simpler, so everything will be converted to unix to UCAN
    • TODO - timezone kinks have to be worked out before going live
  • Intro "version" prop - doesn't work well if v1 and v2 didn't have one
    • sniffing based on properties (Juan: Describe that decision tree in ### Legacy )
    • size and efficiency (major problem for IPLD crowd)
      • Brooklyn: UCAN spec is versioned at semver, tons of breaking changes (v0.10); the UCAN-IPLD version in lockstop
  • The "v3 Question" - force current CACAO spec and template into dustbin of history as deprecated intermediate stage, as OED rightly points out has already happened once!, or create separate CAIP to make new CACAO a major version/independent?
    • Pedro: V1 vs v2 - only breaking changes were adding signatureMeta and typo in SIWE message version prop
    • Pedro: Separate-CAIP versioning cleaner than commit-linking, allow distinct documents
  • Pedro: CACAO-RPC endpoint currently consuming v2 CACAOs ; without knowing issuer, requesting partial CACAO (minus issuer); would that work with v3?
    • Pedro: I'll create a separate CAIP for the request/endpoint (that we will need to share with non-WC infra)
  • Chunny: version of SIWE/X msg goes where?
    • OED: v = UCAN ucv if a UCAN, SIWE version if a SIWX...
    • Size is of the utmost here
• multidid
  • call for broader feedback? while we wait for irakli; merging soon to have straw man
• varsig
  • call for broader feedback? while we wait for irakli; same
• namespaces/SIWX profiles issue
  • So far, namespace profiles include the following signatureMeta values:
    • eip155/caip122 --> caip122-eip191 and caip122-eip1271
    • solana/caip122 --> solana:ed25519
    • arweave/caip122 --> arweave:rsa-pss
  • and in open PRs:
    • stacks/caip122 --> stacks:secp256k1
    • tezos/caip122 --> tezos:ed25519, tezos:secp256k1 and tezos:p256
  • does : create any problems? would a better divider be worth recommending?
  • should SIWX CAIP give guidance here on how to pick that name? people are clearly cutting and pasting, then guessing for lack of instructions in the template :D
    • might be moot if CAIP-191 uses varsig prefix on signature rather than signatureMeta string

Next Steps

• Joel will retool PR to add CAIP-191 and ONCE STABLE AND PROD-READY, supercede 74 to it
• work out IPR request/issues async?
• 4 weeks from now, discuss CAIP-122 relative to V2/V3 CACAOs