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...
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
24 Jan - CACAO/AuthZ Biweekly
PRs to refine/move to close
Ongoing issues/topics
fctfield?0xd51ecodec roundtrips between IPLD and SIWE message str, including timezone nuancesv= UCANucvif a UCAN, SIWE version if a SIWX...:create any problems? would a better divider be worth recommending?signatureMetastringNext Steps