Joel: capcould point to a UCAN or a ZCap or a CACAO containing a ReCap...
Brooke: instead of an ENUM, the header could tell you how the cap object is serialized; if you change the alg, the payload could be a UCAN, a passkey, a recap, etc...
Brooke: is SIWX a signature type? that's the only time you need it to be byte-for-byte a particular way...
Joel: I'm not convinced, canonicalicalization algos X signature algos ( X hashing) = NXNXN profiles :/
Brooke: maybe not everything, but some usecases still justify a varsig-style header
Juan: But isn't multiformats or some subset of it going to IETF now?
Juan: If this starts in CASA let's do it in a new repo with community specification IPR and inbound/outbound IPR consent per github account just to be safe
can we get some more detail (preferably in the PR or its commentary) on how it works with different pub/sub architectures? that might help my question from last time about whether ongoing upgrade debates around bitswap might be relevant...
Use case? Joel: Web3.s: delegates cap to a service, versus we de; Joel: This is an invocation, not a delegation, i.e. this signature is when i USED the linked cap
Brooke: Sidenote, DAG-Haus uses "invoked:true" inside a cap, whereas i'd rather the invocation were an envelope with a cap IN it
Joel: hash of cap in header; payload is any CID/stuff
what URL should we move the CACAO demo build to, and how?
SIWX --> UCAN easy (no verb --> wildcard verb); human-readable --> machine-readable is the traditional downhill roll
UCAN --> better URIs to slot into SIWX msgs and CACAOs
Brook: Consuming a CACAO in a UCAN (or even consuming a UCAN in a CACAO) would be quick and easy;
Brook: UCAN need to understand variable sig typers (eip191 + Passkey --> signature types in multiformat); UCAN transformed into a CACAO and signed --> easy peasy?
Brooke: A spec that transformed a UCAN --> humanreadable message for an EIP191 (easy UI) would be fun to write... signing that produces a CACAO that can consumed by UCAN systems?
do that here? i could spit out a strawman this week mebbe
Pedro: Attributes and proof-of-delegation are missing from CACAOs and SIWX, but if a SIWX message could somehow parse attributes and delegation from a CACAO [chain]...
Brook: Trouble grasping the usecase for roundtripping between EIP191-only systems and UCAN-based systems that already have rich consent UI
CACAO <> UCAN misalignment
Pedro: Polyfill all mismatched fields? Brook: Sure, unidirectionally... roundtrip gets ugly with polyfills, tho
timestamp mismatch - timezoned versus UTC time (smurf the timezone into a comment field? feels deeply wrong)
brooke: let's align on usecase first, tho
new use case: who's signing what exactly
brooke: update SIWE or add new SIWX profile to include req'd fields?
pedro: maybe the game is nudging wallets to treat SIWE as a special case rather than an EIP191 -- MM is leading there; making "resources" array more visible (translateable to human-readable?)
joel: missing history: CACAO is an IPLD-friendly SIWX receipt; maybe the most important thing is aligning on how every signature type and event finds its way to a solid IPLD canonical form?
joel: recap is meant to be roundtrippable to human-readable
brooke: SIWE was backfilling new UI into limited existing UI options; needed verbs
one option: -resource[1]?verb=write
pedro: but baseline assumption = unreadable resources (joel: until recaps, anyways)
Next Steps
Brooke does all the homework for the whole group, reports out in two weeks at next meeting
CASA Agenda 15 Nov - CACAO/AuthZ ~Monthly~ Biweekly (for now!)
PRs to refine/move to close
Review, notDraft, but wenFinal?Ongoing projects/topics
capcould point to a UCAN or a ZCap or a CACAO containing a ReCap...capobject is serialized; if you change thealg, the payload could be a UCAN, a passkey, a recap, etc...varsig-style header-resource[1]?verb=writeNext Steps