Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editorial WG - 29 June 2023 #86

Open
3 tasks
bumblefudge opened this issue Jun 30, 2023 · 2 comments
Open
3 tasks

Editorial WG - 29 June 2023 #86

bumblefudge opened this issue Jun 30, 2023 · 2 comments

Comments

@bumblefudge
Copy link
Collaborator

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

Backlog

@haardikk21
Copy link

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
Copy link
Collaborator Author

bumblefudge commented Jul 3, 2023

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants