# CASA CACAO/AuthZ WG - Biweekly Meetings

[📹 Join the meeting](https://meet.ethereum.org/CASA)
[💬 Join the Discord](https://discord.gg/nVyUMe9b)
[📅 Meetings calendar](https://bit.ly/thepubliccasacalendar)

# template - XX Month [Year]
## PRs to refine/move to close
## Ongoing issues/topics
## Next Steps

# 23 January

Announcements

## PRs to refine/move to close
## Ongoing issues/topics

- varsig
- breaking changes prototyped
- use-cases -
- CACAOv3 looking less comp with UCANs;
- CACAOv2 w/varsig
- `s` field for raw sigbytes --> varsig instead
- chunny: is that for streaming/chunking or for agility? joel: more for self-describing; sergey: simplifies cacao by moving type info from 2 fields into sig field
- joel: move our whole thing to dag-cbor instead of having a downstream dag-json pointing back to it
- prototype working (passing most tests), will open spec PR eventually

## Next Steps

- close loop on UCAN v1
- open PR for varsig

# 28 November

## PRs to refine/move to close
## Ongoing issues/topics
- ceramic's varsig library - EIP191, JWTs, and more sig types coming soon
- JS-did repo branch (packaged soon, works as branch for the compilers from [code](https://github.com/ceramicnetwork/js-did/tree/feat/varsig))
- implementer feedback for the spec:
- spec is basically just examples -- needs to be prosily spec-ified
- multicodecs wishlist -
- EIP191 - personal_sign (EVM) (`0xe191` for now)
- EIP712 - structured data signing (EVM) (`0xe712` for now)
- JOSE (`0x7053` for now) - give https://datatracker.ietf.org/doc/rfc7520/ as normref
- alternate path if rodd, volker, or anyone else thinks it's a 2-entry scenario:
- JWT
- unprotected header and body both b64d JSON
- JWS more generally (ideally consecutive)
- header but body can be arbitrary octet bytes
- sergey- also allows multisignature
## Next Steps
- [ ] @chunningham will start the editorial process of making varsig spec more spectastical and tag juan to clean up after
- [ ] @bumblefudge will spearhead multicodec registrations (@expede any opinions?)
- [ ] @ukstv will finish breaking varsig out as a package from the js-did lib and ship it to the masses clamoring for freedom as an NPM library

# 31 Oct

## PRs to refine/move to close
## Ongoing issues/topics
- varsig
- brook: exploitable surface - too much goes outside of signed payload exposes "fudged metadata" (partic diff mechanism) family of attacks
- brook: alg field signed over in classic JWTs... maybe we should be signing of that as well
- redundant adds a processing/security check
- which way varsig
- most standard formats put the `alg` into the data format or envelope anyways, so varsig is mostly a fallback/redundancy
- our formats included
- same redundancy issue - putting it in two places risks people checking the wrong one, OR having to check both
- opening an issue and
- how would moving alg into payload work for other data formats?
- eip191 - only one alg (thus implicit, no agility)
-
- CACAOv3 (CAIP-196) still has varsig dep instead of putting alg in payload
- UCAN v1rc1
- moving from heirarchical nested caps to arbitrary/flat batched signatures
- easier for implementers to check
- chunny: I'm pretty sure Spruce is ok with batched sig approach, we can make that work UX wise
- rebase is a bit of a halfmeasure anyways; medium-term hope is that wallet come up with better signing flows anyways
- brook: security and UX both improved by giving each resource or quote/scope a DID/keypair (rather than just a UUID) and leaving a key/signer near resource makes it easier to work out good flows and UXs i think
- chunny: when you say "did" do you mean strings or multidid byte arrays? brook: preference? chunny: i dont think we should give implementers one more thing (multidid) to implement
- aaron: much easier to barf a non-understood DID str in an error message than a crazy ipld thing not understood
- brook: so maybe we stick to strings for now?
- thinking through
- designing a "UCAN Store" - special parser library that translates between the deleg chains that are basically custom-CAR files containing all the event chain and allows the substrate - works as a kind of dedicated IPFS store/sync engine that can run in the background so that when people verify or invoke, they can get all the back-contents ()
- live connection with resource at invocation STARTS with syncing all relevant objects, so that they're already on hand if invocation fails, all the plan B resources are already onhand
- signing and delegating simpler (hash a single object), invocation needs to walk and hash the whole merkletree
- joel: caip-222 combines steps
- what about CACAOv3 tho? brook: each delegation = single resource in the resources[] array of SIWE msg in merkletree-sig approach
- joel: but does anything really need to change in CACAOv3? can't you just add all the leaves in `fct` and the merkle path in the sig somehow?
- brook: well now the thing you're signing is the digest bytes, merkle root, and merkle path
- joel: but you need to add "newhash" prop
- chunny: htink of cacao as a "virtual" envelope;
- just doing everything as ipld now that we have more ipld
- joel: verkle trees more high-compression and maybe easier to align with ipld?
- brook: but why can't underlying data fully be encoded as ipld? i don't follow
- brook: verkles are more expensive to write and less to read, and the discreet math gets heavy (not sure we need that headache) to make it more compressed;
- brook: some day, i'd think ZK > merkle some day? wouldn't need to pass around intermediate proofs that way
- joel: we were researching chain proofs for gnosis safe accts (which are single use), which would require us to construct a ZK
- brook: putting alg back into payload?
- joel: but JWT signing puts alg in _protected_ header, so it's already signed over? you have to take alg out of varsig and put it back into JWT header BEFORE checking signature (JWS surgery, as it were)

## Next Steps

# 3 Oct

## PRs to refine/move to close
- [varsig #11](https://github.com/ChainAgnostic/varsig/pull/11/files) - will be taken out of draft once i'm happy with the prototype, which is any day now
- oed: who else needs to weigh in on this? we won't implement v3 for a while, not sure WC will have opinions here
- chunny: webauthn-ucans won't be "official" JWTs for some time, maybe never; `prf` field will allow key derivation that gets you to the same place, *but* deriving keys from `prf`s won't technically be the same trust model, the key will exist in browser memory
- interested parties should attend [the ucan wg calls to discuss](https://lu.ma/ucan)

## Ongoing issues/topics
- chunny: CACAOv3 impl in rust updates
- timestamp update: manipulating as string was wonky in rust but i got it working and roundtripping SEEMS to work
may be corner cases with 100-yr-old timestamps?
- chunny: webAuthN version field =? 3?
- oed: maybe make it something meaningful? i'd make it wAN or something to make explicit that it's not an element in a series, something "special casey"
- chunny: yeah, could be mistaken for artefacts of another profile...
- aaron: cacao3? chunny: wan3? could be mistaken for cacaov3 receipts of other signing flows
- chunny: varsig prefixes are a game-changer here, i just wanna use them e'erywhere
- oed: well, our open PR for this (using cacaov2) might not align; in sig array, we have this additional property, `aad`, which is where we stick the authenticator data and client data JSON (base64d?)
- chunny: how encoded? oed: CBOR actually, thrown in as unencoded binary
- chunny: in my rust prototype, credential.get --> set of flags that gives length of CBOR object that follows; library that i'm passing that object to barfs on the flags; i put a varsig in front for the FLAGS, then I can pass the JSON blob to a std lib; varint-AAD-varint_for_client_JSON-bytefield-varint_for_sig_length-sig
- chunny: `aad` doesn't reliably include/encode the key type, which is why i wanted to varint prefix it
- oed: what's cred.get actually send? chunny: 3 arrays that we care about in the response: `aad` byte array (self-describing lengthwise, but you have to parse to know where it ends), client JSON thingy (uint8-typed array, not ordered, not compacted and may contain whitespace, etc etc), and signature
- 1Password's rust lib, `passkeytypes`, limited here
- varint prefix for `aad` costs us a byte and in practice is only 1 of 2 values at the moment; is that a problem for folks? ukstv: i think in this context we don't need to sweat that one byte; chunny: varint-prefixing bytestream saves many consumers from even having to know what that aad piece is or means, they can just set it aside and parse the thing they know that comes after;
- multicodec table doesn't have an entry for the passkey keytype; issuer's did:key works for now; aaron: but in the future this could require a did resolution step if you want to support arbitrary issuer dids; chunny: correct; oed: did:pkh key types are pretty easily inferred from prefixes;
- chunny: i can imagine a future situation where webauthn keys are separate entries on DID Docs (e.g. did:web keys); oed: that sounds like a future footgun, maybe should have a stub codepath so devs don't get surprised if it breaks on that case? chunny: good idea i do this
- chunny: maybe if keytype discriminant is in frontmatter, signature length will be known for many keys, e.g. ed25519 (oed: all keys, tho? chunny: not for RSA); oed: couldn't we re-use encoding/alg info from multicodecs? or is that more ipld-specific/assumes unsigned_varints and IPLD parsing... chunny: i think the latter; although rebuilding as close as possible to ipld parsing without all of the assumptions might make sense; aaron: but it's a JWT, innit? oed: nah its more of a CWT/CBOR-digest thingy; chunny: signs over a byteflag+cbor+json turducken then hashes it SHA2
- chunny: the browser APIs are abstracting all the byteflag stuff and cbor stuff so script kitties are just handling JSON and JS blissfully
- oed: newer yubikey seem to have some fancy stuff in the byteflags, sneak first 8 bytes of pub key (to save people ECRecover or other expensive compute); chunny: I've also seen some bytecounters in the wild... but seems kinda unspecified/bespoke in those cases
- prototype realtalk: yall using a backend to track authenticatorIDs and signature counters and whatnot? i've been playing with it in sessions, wondering if others see the necessity for a full-blown backend server to track these; oed: we see 3 paths here, trying to support all 3 and let devs decide in our library: 1. create did/key, dev has to store/track user::key mapping; 2. probe: ask webauthn for arbitrary signature, recover (2) key(s) from that signature, then give user a signin message to sign, then test against the 2 keys you recovered; 3. ceramic version is to get 2 possible keys and then scan streams for history/evidence of one of them being in use
- chunny: 2nd sounds risky, 3rd sounds good
- library size? oed: we went lightweight; chunny: i bundled a full did resolver in there, yolo
- iframe, pass back key to parent page; registration wasn't working in iframe so had to do redirects :/ (should be fixed before public launch, docs says it should work, but chrome is failing on this); aaron: CSP workarounds work? chunny: giving me a [permissions policy error](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/publickey-credentials-create#browser_compatibility) when calling credentials.create in chrome even with all the CSP flag allow-set
- chunny: payload DOESN'T involve issuer, right? oed: nah; should i just send you the [PR](https://github.com/ceramicnetwork/js-did/pull/166)?
- chunny: UCAN invocation spec, specified in IPLD; would it worth writing a CACAOv3 profile for those?
- delegation still using JWTs but [invocations](https://github.com/ucan-wg/invocation/blob/high-level/README.md) are IPLD-only (e.g. to enable promises getting piped around and such); still trying to figure out at the top level what an invocation MESSAGE looks like (so haven't prototyped yet)
- chunny: haven't confirmed yet but i'm fairly certain invocations will produce conformant CACAOv3s
- chunny: links out from ipld are just CIDs to invocation-receipts (whereas i've been prototyping the same kind of CIDs linking out to CACAOv3s with iss and aud that match and /delegate endpoints); if found in the wild, would be cryptic unless we have a profile published somewhere; oed: well, it doesn't need to be service-focused or located; chunny: we want it to be self-certifying (as a state machine update/patch); oed: you mean qua transaction? aaron: only invocation is "PATCH", then; chunny: yeah that's about it
- juan: informational CAIP plz; chunny: yeah totally non-normie, just "if you thinkin about using a CACAO may we recommend this format for the purpose field and endpoint naming convention"

## Next Steps
- [ ] chunny will put did resolution stub in cacaov3 rust prototype for review and post to discord calling for reviews

# 9 Sept

## PRs to refine/move to close
- [varsig#11](https://github.com/ChainAgnostic/varsig/pull/11/files) - mergèd

## Ongoing issues/topics
- CACAOv2/v3 mapping; have been studying these lately and playing with WASM tooling that could normalize between the two
- Chunny: v2 describes AuthZ well;
- WIP tooling PoC: WASM library that handles UCANs (and WebAuthN values) as JWTs and types CACAOs in v3
- OED: A spec would be nice on exactly how you map WebAuthN values to JWTs for this...
- Chunny: hacking so far:
- alg ==> `webAuthN`
- turning the WebAuthN "into a JWK"; OED: but isn't it a pile of CBOR? Chunny: Actually we're just turning the header and body strings into a digest and signing over them JWT-style; didn't implement `multidid` way yet, still figuring out how to align diff community styles
- OED: we've been prototyping WebAuthN with CACAOv2; remove issuer and signature and stick the remaining payload into IPLD, grab the CID of that, and sign over THAT
- Chunny: challenge is already a hash...
- OED: A .CAR file full of IPLD examples would also be nice!
- OED: free-standing [CAR library](https://github.com/n0-computer/iroh-car) broken out of IROH is gonna be a game-changer
- Philip Kruger contrib
- OED: we have aPR open for JS-DID monorepo that adds support for SIWE session keys to rely on WebCrypto (non-extractible) keys instead of ephemeral ones that live in browser memory (less secure)
- chunny: the signer passed in to this tooling expects a closure (a JS shim could make webauthn that signer...)
- oed: we're thinking of making the did:key in `aud` the non-extractible one, so that the browser holds the
- webcrypto create-keys API has a "non-extractible" flag which isolates them not only from DOM but also from extensions (Aaron: TPM, in theory?); those keys persist in indexDB even though they're non-extractible

## Next Steps
- Chunny: TS library coming out soon that lets WebAuthN take JWTs and sign UCANs, SignSIWE --> UCAN that is a CACAOv3
- OED: [PR merging some day soon](https://github.com/ceramicnetwork/js-did/pull/164)
- bumblefudge: Announce both on Discord, mebbe?

# 8 Aug

## PRs to refine/move to close
- [multidid-pkh](https://github.com/ChainAgnostic/multidid/pull/9)
- merged
- follow-up to mandate all chainIDs be integers for EIP-155 only
- [x] Juan to open upstream did:pkh PR

## Ongoing issues/topics
- [varsig#11](https://github.com/ChainAgnostic/varsig/pull/11/files)
- previous discussions about using WebAuthN's PRF function (which creates arbitrary entropy off your webauthn credential) versus generating token externally and just
- downsides to using webauthn's native PRF: 1.) still an extension, not in most browsers yet (just firefox!) 2.) puts keys generated into readable memory (becomes extractible)
- alternate approx: put digest or arbitrary message into challenge field, put a nonce in the nonce, get webauthn-reliant signature back (not the authN signature, a new signature made by that token)
- consensus - some text specifying we're doing the latter here, not the former
- Joel: using CID as challenge (32 bytes), but don't we also need more inputs
- [challenge length](https://w3c.github.io/webauthn/#sctn-cryptographic-challenges) recommended to be >=16bytes , so could be a CID+anything
- Chunny: constrain choice of hashes (blake512, e.g., couldn't work); CIDv1 too open
- challenge length --> choice of hash; identity hash --> doubles length; although I suspect FIDO spec will hash all inputs down to 32 bytes anyways as digest, will check and experiment
- Joel: hard to get recovery bit when using ECRecover/secp keys
- Chunny: public key returned by authN ceremony but needs to be stored somewhere;
- Joel: don't need to store it if credential_get can have the recovery bit somewhere in it; YubiKey implementation, for ex., seems to stash a few bytes of pub key in other fields so that public key is recoverable on each session from, e.g. SIWE
- this would mean full AuthN ceremony only needs to be done at registration and nothing stored between sessions
- Hugo mentioned on the UCAN call that Chrome, Android, and iOS not handling this the same way, tho; recovering public key could get dodgey across platforms if so
- chunny: PR still draft, has TODOs
- joel: will review in a few weeks
- other todo: note about replay attacks necessary? [Rust implementation guidance](https://docs.rs/webauthn-rs/latest/webauthn_rs/index.html#allow-serialising-registration-and-authentication-state) for webauthn mentioned holding onto authentication or attestation bits for length of the session in some kind of cache?
- joel: but if it's a capability i'm not sure it's as big a risk...
- chunny: invoke a cap twice? not so bad
- aaron: no risk to replaying something idempotent

## Next Steps
-

# 11 Jul

## PRs to refine/move to close

## Ongoing issues/topics
- CACAO <> UCAN timestamp translation
- unix timestamps as int in both specs
- JWT spec: "numeric date" (can be floats :grimacing: )
- brook: easy spec PR - NEVER FRACTIONAL PLZ, NO TIME ZONES
- **Action Item:** Brook will make the PR and close the issue ([#136](https://github.com/ucan-wg/spec/issues/136))
- sidebar: float and int ARE diff in IPLD (presence or absence of decimal point), but in DAG-JSON not
- IPLD spec has warning about float ambiguity and precisions from context; DAG-JSON specifies float by reference to a specific IEEE-754 (same one everyone uses)
- Aaron: JSON has the same underlying ambiguity, but in practice almost everyone uses that double standard for practical interop
- brook: specifying just for DAG-JSON gets us going but maybe a PR or issue on IPLD would be a stitch in time for long-term interop
- WebAuthN <> UCAN experiments?
- Chunny: authenticator and RP both need to supply lots of data points to WebAuthN signer, not sure how to encode all of that in varsig params
- WebAuthN has a pseudorandom function extension for turning an input into 32bytes which it returns upon authN (can use that as a deterministic salt??)
- discussions on webauthN repos asking for deterministic symmetrical/reuseable enc/dec keys... other readers/implementors seem to have the same question, guidance may be forthcoming
- non-extractable key being requested in one issue, but other commentators are managing expectations on the security model of that approach
- joel: but delegating TO that non-ext key is safer than having the prf in the DOM
- chunny: note, tho, that `prf` is unstable, can roll over in some authN flows (and thus brick any plans of reusability/session-scope)
- registry entries for webauthn params still seems worth doing
- Brook: FIDO cred as varsig object; webAuthN doesn't predictably produce the same output cert for the same inputs, sometimes changes a few bits (because of server-side assumptions), so not really deterministic enough to buidl on (at least not without further research on those server-side variables... might be undocumented still)
- passKey a little more direct to end-user UX; webcrypto API a little more software-driven (and thus prone to malicious injections/sneaky stuff in less trustful e2e envs)
- passkey delegating to a local key (via prf) feels a better path than going back to root cert every time, although we're waiting on a standards process and a bump to the libraries... theoretically Q4/Q1 but who knows in reality
- joel: we have someone hacking on webauthn --> ipld receipts, hoping they could come today but not sure they're coming; sticking point is reconstituting or recovering the public key from a call to the request/get cred func
- chunny: you CAN get the key from the attestation that comes back; better to keep the key you got at registration tho, use it as challenge when calling that func
- joel: credentialsCreate() + ECRecover --> pubKey, sure, but we're stuck on whether or not that key can be recovered later from credentialsGet()
- brook: check with hugo dias (ex-daghouse), have your people call him-people
- chunny: RP sets ID of the cred at time of create
- joel: but you can't put the pubKey into that ID or else it's visible to everyone else, defies the point
- pow-wow with hugo sounds good, let's set something up
- cacaov3 impl updates?
- ceramic still working on deps (libp2p subprotocol specifically) before getting to TS impl
- spruce working on rust impl similarly working on basics still (types <> encoding/multibase chaos)
- implementing timestamp conversion catcher
- sergey's PR is still open, needs a bit more time
- chunny: happy with the direction tho if it works in all relevant languages
- RFC3339 corner case (60 microseconds is a valid value !?!?) but maybe all the stdin libraries already exclude that/prevent it from happening
- aaron: timezones also screw microseconds cuz of those non-int offsets like india
- quick check: UCANs allow additional JWT header fields? `additionalProperties`?
- brook: we haven't found a use-case for needing them yet, might get locked down at the conversion to IPLD stage...
- chunny: might be able to lock down the header if varsig is expressive/open enough...
- brook: recent ucan major version (v0.10) pulled last optional/variable field into payload, allowing header to be locked down and schematized at IPLD level
- chunny: oops need to update our implementation to conform to that
- brook: this was actually the motivation of moving that field - spec COULD now be PRd
- joel: DAG-JOSE code squatted in multicodecs table hehe
- sidebar: Multiformats governance
- joel: can codes in multiformats be re-signified in context-stable varsigs table?
- brook: punning should be fine?
- juan: uhoh
- joel: is varsig single-signer only? (Chunny: but UCAN is single-signer only)
- brook: multiple `prf`s is the workaround for BLS some people have been exploring
- brook: for true multisig, that might just be a new entry in varsigs table... joel: but in JOSE sense, protected AND unprotected headers ALL have to be encoded for multisig, non? the v0.10 move out of unprotected will help
- chunny: DAG-JSON codec for ucan varsigs, is that ok? is base64(header).base64(payload).varsig close enough? joel: well depends, we can overload it but maybe registering a new code is cleaner?
- chunny: if header CAN'T have additionalProps, we don't need any risky overloading of varsig... joel: unless you need fancy signatures... chunny: my question is also semantic, since it isn't JSON being encoded, just pseudo-JSON transformable into JSON?
- chunny: UCAN signed as plain unord json, turning that into a CACAO makes it unverifiable because of field ordering :grimacing: has anyone found a way around this or have we just accepted this as a limitation? ; brook: this is a good reason to defer to UCAN-IPLD representation throughout, make that the canonical form; raw, "as-encoded" version of the `prf` is the secondary, less-guarantee-having form, check sig against the canonicalized IPLD form if you want a simple life
- canonicalizing isn't strictly required because no JWT libraries do it the same way; DAG House impl of UCAN canonicalizes submitted JSON before signing/checking/converting to IPLD; but not everyone likes that, IPLD has to be aware of the looser form
- Aaron: Is UCAN always DAG-JSON, not CBOR, etc? Brook: no, [reconstituted](https://github.com/ucan-wg/ucan-ipld/) (and then [canonicalized into DAG-JSON bits](https://github.com/ucan-wg/canonicalization/)) JWT is what's signed over and verified, NOT any other form. layering means invocations and retained verifications can buy back that compute depending on the flow.
- chunny: prf list of a cacao should point to the canonical CID of the [non-CACAO form] of the original UCAN as-signed, right? brook: Y, would recommend that for optimum interop/modularity. linking to a CACAO would limit utility of that signature chain to fully CACAO-aware consumers... whereas UCAN-aware might be a wider field

## Next Steps
- minor PR to UCAN spec
- [ ] @expede to make a few 99%s into 100%s in the spec (integer thing, i.e. closing ucan-spec#136)

# 13 Jun

* Zoom failure :grimacing:
* Varsig and recap and cacao v3 impl updates?
* 3box - no updates, a little blocked by other projects, but coming up soon on the queue
* spruce - samesies - hoping to make progress on a webAuthN based signing flow
* OED - would it make sense for a separate CAIP to define a WebAuthN Profile or sig suite type thing? maybe for hash of payload in challenge for GET req?
* chunny - cacao (or other canonicalized arb data) as payload to hash for challenge
* OED - cacao without the varsig as GET payload, add the varsig from the response?
* OED - bikeshed: "resident" key seems the way to go, but how know if already have one?
* chunny - ATM analogy - same authenticator across multiple domains gets complicated (iFrame?)
* OED - iFrame approach is tricky cuz WebAuthN then binds to FRAME not to app/domain/etc
* OED - what about hosting a page/dapp on ipfs so that the iframe is content-addressed
* chunny - do we need a DID method for inheriting/rotating keys across hashed versions?
* OED there's a top-origin (domain-bind on parent?) option, but I think that is not implemented yet by lots of browsers
* OED - cacao works without changes, right? all fits?
* chunny - yes
* OED - CID multiformat bytes take up space...
* chunny - i've been delaying thinking about that, not prefixing the sig
* OED - could the CACAO encode the "everything exc the signature" part?
* chunny - is there a definitive spec for what an authenticator can do?
* https://www.w3.org/TR/webauthn-2/#sctn-authenticator-model - actually pretty explicit
* me: IPNS????
* UX and modal/meaningful consent
* Secure Design WG kinda thinking along these lines?
* [notes here](https://github.com/ChainAgnostic/secure-design/blob/main/meetings.md#3-may-16-8am-pst---rsvp)
* "meaningful" consent and human-readability of AuthZ modals
* OED - local agent that detects bad ToSs?
* chunny - Kepler local agent ideas <> ReCap and/or CACAO interactions
* WebAuthN doesn't have the implicit stakes of cryptocurrency signing - non-repudiable and/or financially-consequential claims should probably be flagged to user as such in a uniform way...
* Current UX standards bar is on the floor - no capacity to send message or explain, just "give fingerprint y/n"
* OED - tresor actually had a prototype but the spec removed that option last-minute :(
* segregating keys per domain --> relative safe against classic phishing attacks but bad for UI
* chunny - hard to scaffold that flow without a lot of network chatter and extra steps
* spitballin
* local version of webAuthN? OED: not quite but you can do secp256k1 locally with a hardware signer...
* domain-bound to localhost might work but this requires you to open a browser (e.g. PWA chromium on localhost?)
* did:pkh multidid
* chunny: should the hedera version be bound to [explicit mode only](https://docs.hedera.com/hedera/core-concepts/accounts/account-properties#public-key-account-alias) to be deterministic without a lookup?
* OED and Juan: SGTM
* OED - tezos same problem - lookup required for the non-secp (i.e. non-EC Recover) account types (i.e. tz2 only)

# 16 May

* PR for varsig got merged
* Mostly bikeshedding at the end
* Seems like we landed at something everyone can use
* PR for ucan got merged as well!
* Now uses the ReCap compatible layout
* v1 sometime this year? Does it imply it won't change?
* 0.10 is kind of a RC for 1.0 (not a promise ;) )
* PR multidid got merged
* 3Box Labs multidid impl of key and regular
* Spruce got draft CACAOv3 with support of the above + pkh did
* https://github.com/spruceid/cacao-rs/tree/feat/cacao-v2
* Timestamp conversion is still a problem that needs to be figured out
* ChainProof update
* Proofs are pretty large, jthor.eth -> 21K

# 21 Mar

## PRs to refine/move to close
- [varsig v1 yet?](https://github.com/ChainAgnostic/varsig/pull/6)
- still waiting on joel to close code comments/requests in pull #6?
- discussion topic: if varsig is still blocking [cacaov3](https://github.com/ChainAgnostic/CAIPs/pull/196), maybe it would make sense for some [profile of] a [pre-existing format](https://github.com/ChainAgnostic/varsig/issues/8) to encapsulate signatures for CACAOv3 purposes, instead of or in addition to varsigs?

## Ongoing issues/topics

- [multidid](https://github.com/ChainAgnostic/multidid) - no news is good news?
- if it's bad news and implementer feedback is desired, maybe we can [assign](https://github.com/ChainAgnostic/multidid/issues/6) open [issues](https://github.com/ChainAgnostic/multidid/issues/5) to solicit it?
- [CAIPs#196](https://github.com/ChainAgnostic/CAIPs/pull/196)
+ [new ReCap EIP draft](https://gist.github.com/chunningham/5dface3307d9e69ad8b68327d96b56e9) - wen launch tho? has there been [silence on the eth-mag thread](https://apply.workable.com/sismo-1/?lng=en) since december? implementers reaching out?
- [ChainProofs](https://github.com/ChainAgnostic/CAIPs/pull/218/files)
- Spitball the to-dos on the call?
- esp. "Discussion of ChainProof inclusion within ReCaps, UCANs, and W3C Verifiable Credentials, including their relationship with cryptographic signatures in these formats."
- UCAN spec [v0.10 almost done](https://github.com/ucan-wg/spec/pull/132)
- biggest remaining design question:

# TODO BEFORE MERGE

- [ ] Fully define ChainProof EVM Profile mechanisms for identifying minimal states necessary from `eth_getProof` for EVM verification of contract calls and blocks. currently under "Instruction things".
- [ ] Flesh out ChainProof Method definition and examples, especially the EVM NFT Ownership method.
- [ ] Example code and test vectors.
- [ ] Clean up ChainProof Methods section, move EVM-specific stuff to the EVM Profile.
- [ ] Discussion of ChainProof inclusion within ReCaps, UCANs, and W3C Verifiable Credentials, including their relationship with cryptographic signatures in these formats.
- [ ] Complete remaining empty sections.

# 21 Feb

## PRs to refine/move to close
- [multidid v1 yet?](https://github.com/ChainAgnostic/multidid/pull/2)
- [i'm confused by who's on first](https://github.com/ChainAgnostic/multidid/pull/2/files#r1102529167)
- merge as first draft and open tracking issues
- [varsig v1 yet?](https://github.com/ChainAgnostic/varsig/pull/6)
- holding off, joel will ping the channel when it's ready for review

## Ongoing issues/topics
- [multidid](https://github.com/ChainAgnostic/multidid)
- [varsig](https://github.com/ChainAgnostic/varsig)
- [CAIPs#196](https://github.com/ChainAgnostic/CAIPs/pull/196)
+ [new ReCap EIP draft](https://gist.github.com/chunningham/5dface3307d9e69ad8b68327d96b56e9)

## Next Steps

# 7 Feb

## PRs to refine/move to close
- [multidid v1 yet?](https://github.com/ChainAgnostic/multidid/pull/2)
- [varsig v1 yet?](https://github.com/ChainAgnostic/varsig/pull/6)

## Ongoing issues/topics
- [multidid](https://github.com/ChainAgnostic/multidid)
- [varsig](https://github.com/ChainAgnostic/varsig)

## Next Steps

# 24 Jan

## PRs to refine/move to close

## Ongoing issues/topics
- [CACAO Overhaul PR](https://github.com/ChainAgnostic/CAIPs/pull/196)
- The "v3 Question" - force current CACAO spec and template into [dustbin of history as deprecated intermediate stage](https://github.com/ceramicnetwork/CAIPs/blob/fix/update-cacao/CAIPs/caip-74.md#backwards-compatibility), *as OED rightly points out has already happened once!*, or create separate CAIP to make new CACAO a major version/independent?
- [multidid](https://github.com/ChainAgnostic/multidid/pull/2)
- [varsig](https://github.com/ChainAgnostic/varsig/pull/6)
- 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

## Next Steps

# 29 Nov - CACAO/AuthZ Biweekly
- meeting link (temporary until a dedicated Zoom acct or a stabler jitsi instance can be established): https://zoom.us/j/3034248110?pwd=VTkyWTA1YVFvOEozdktEd2J2SW14Zz09

## PRs to refine/move to close
- [IPLD timestamping PR](https://github.com/ChainAgnostic/CAIPs/pull/168) - needs a little more work? need to discuss OED's "string discriminant" proposal
- resolution: string registered in namespaces profile per-namespace
- [StreamSync PR](https://github.com/ChainAgnostic/CAIPs/pull/167) - needs to incorporate Spencer's input? Are any non-Ceramic streams or systems using this, and would it make sense to find one?
- likely to close soon anyways-- will reopen later if multi-company usecase emerges
- [DagJWS](https://github.com/ChainAgnostic/CAIPs/pull/162) - I think this just needs an editorial pass for clarity of the "profile"/semi-normative nature of some statements?
- will keep working for a near-future `Draft` status

## Ongoing projects/topics
- UCAN spec generally
- UCAN<>ReCap progress?

## Next Steps
- [ ] @oed will ask UCAN group if `prf` as JWS header make sense to align
- [ ] @oed and @bumblefudge to do CLA-bot things offline
- [ ] @chunningham to respond to eth magicians post after discussion w/team
- quick read - LGTM w/full URIs, but will discuss
- chunny: where this headed? oed: IPLD shared receipts baybee
- chunny: not just timezone but also precision (nanoseconds vs seconds) - varsig should specify

# 23 Nov - Special Session - UCAN/ReCap

## PRs to refine/move to close
- N/a ?

## Ongoing projects/topics
- Moving Recaps towards being able to express UCANs?
- oed will propose a Rebase syntax PR
- Use case for targets being so open as opposed to constrain to URIs to match UCANs more easily?
- Update from Brook re: ZCaps: non-DID principles in ZCaps (example.com)
- Joel: binary representation of a DID ?
- Where discuss recap generally?
- localization wallet-side how, wen?
- revocation - [ucan GH discussion thread#124](https://github.com/ucan-wg/spec/discussions/124)

## Next Steps
- OED: moving away from strictly base64'd JSON objects to IPLD structures referred to by CIDv1 would be great IMHO
- keep discussing in the places we're already doing so, see ya on the threads

# 15 Nov - CACAO/AuthZ ~Monthly~ Biweekly (for now!)
- meeting link (temporary until a dedicated Zoom acct or a stabler jitsi instance can be established): https://zoom.us/j/3034248110?pwd=VTkyWTA1YVFvOEozdktEd2J2SW14Zz09

## PRs to refine/move to close
- OK so the [SIWX spec](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-122.md) is now in`Review`, not `Draft`, but wen `Final`?

## Ongoing projects/topics
- Zach's PR about [DAG-JWS CACAOs](https://github.com/ChainAgnostic/CAIPs/pull/162/files)
+ [test vectors](https://github.com/ChainAgnostic/CAIPs/pull/162/files#r1013416233) are our friends
- Joel's [StreamSync CAIP PR](https://github.com/ChainAgnostic/CAIPs/pull/167/files)
- what URL should we move the CACAO demo [build](https://chainagnostic.github.io/session-demo/) to, and how?
- Report from the UCAN contingent - wen spec v1? - [CACAOs v UCANs](https://github.com/ucan-wg/ucan-cacao/issues/2)
- CACAO

## Next Steps
-

# CASA Agenda 2 Nov - CACAO/AuthZ Monthly
- meeting link (temporary until a dedicated Zoom acct or a stabler jitsi instance can be established): https://zoom.us/j/3034248110?pwd=VTkyWTA1YVFvOEozdktEd2J2SW14Zz09

## PRs to refine/move to close
- should we host a [build](https://chainagnostic.github.io/session-demo/) of Ceramic's CASA demos on ChainAgnostic.org subdomain for educational purposes

## Ongoing projects/topics
- Joel's [StreamSync CAIP PR](https://github.com/ChainAgnostic/CAIPs/pull/167/files)
+ can we get some Protocol Labs eyes on this?
+ How does this relate to the ongoing effort to upgrade/iterate BitSwap?
+ Zach's PR about [DAG-JWS CACAOs](https://github.com/ChainAgnostic/CAIPs/pull/162/files)

## Next Steps
- leave issue open on hosting to gather outside feedback before ceramic's team designer(s) have a crack
+ add link to CAIP, links to SIWE and SIWS profiles
+ `https://demos.chainagnostic.org/session-demo`