Editorial WG - 29 June 2023

[bumblefudge]

CASA Editorial 29 June

PRs to refine/move to close

• multidid#0 - multidid
• Namespaces#70 - Chia/Caip-2 - approved by @bumblefudge but second review appreciated
• Namespaces#40 - tezos SIWX
  • haardik's implementation and sergey's both work today, just need to crosstest and refine spec -
  • [ ] @ukstv will push a commit or open a second PR forking it

Ongoing projects/topics

• sergey: update on the timestamp issue
  • UNIX timestamp (POSIX specs - ignores leapseconds)
    • handwavey section in POSIX spec here
  • defer to OS libraries for this
  • since signing can't happen on a leap second, won't break signatures
  • [ ] @ukstv will PR language into the draft spec here
• comments open/awaiting decisions on
  • Namespaces#68 - @friedger
  • Namespaces#64 - @narsiss
  • CAIP-25#201 -
  • CAIPs#182 - waiting on @ligi to come back from sabbatical

Backlog

• fixes to specs:
  • solana/caip-122 bug
    • [ ] @ukstv will take a look at his implementation
• no progress/chatter on
  • CAIP-220
  • CAIP-221
  • CAIP-218 ChainProof
  • CAIP-195 - shim for OIDC/OIDC4VC interop - waiting on final spec and implementer interest
    • reach out to Polygon ID team?

[haardikk21]

FWIW my Tezos SIWX implementation is inspired from the one at Ceramic, though is less restrictive. Ceramic's implementation only allows for Tezos Ed25519 keys - whereas ours allows for all types of Tezos keys as long as they can be validated using Taquito since a lot of popular Tezos wallets don't create Ed25519 keys by default.

This part will definitely fail during cross-testing.

[bumblefudge]

@haardikk21 @zachferland

Ceramic's implementation only allows for Tezos Ed25519 keys - whereas ours allows for all types of Tezos keys as long as they can be validated using Taquito since a lot of popular Tezos wallets don't create Ed25519 keys by default.

I went to look up what the tezos 122 profile says about non-Ed25519 keys... and saw that the relevant PR was never merged because no one ever confirmed Qibinglee's work on the other key/address types 🤦 . Maybe if you've already implemented you can approve that PR and we can go from there?

My assumption (perhaps overhasty) was that since tz1, tz2 and tz3 keys are separate entries/regexs/etc in did:pkh, they'd be separate classes or subclasses of account eligible for a CAIP-122 flow/interaction. As such, they should be tested (and cross-tested) separately anyways-- i.e., an implementation might still be considered valid using a subset of the available tezos keytypes, particularly since not all wallets expose all 3 and they could be deprecated on different timelines over the years...

But my assumption and Qibing's profile don't quite match so if someone cares they should probably argue their case, suggest changes, etc :D