-
Notifications
You must be signed in to change notification settings - Fork 19
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
Support for CWT #30
Comments
Hey @pdxjohnny; thanks for the idea! There's some related discussion here: #18 |
The TL;DR on current thinking (and we can be convinced otherwise!) is that this spec is the one for interoperability between systems. If we introduce many other encodings, then we either run into token incompatibilities, or larger implementations that support multiple codecs. If folks want to adapt the spec to an internal use case that uses a different encoding, that's a great idea and we're happy to help, but that we can't expect it to interop with other systems and so shouldn't be in the spec directly. THAT SAID, please do comment in that discussion, and especially with any concrete tradeoffs that you'd like to solve for 😄 |
Thanks @expede! Just commented: #18 (reply in thread) Also, credit where credit is due, this idea came from @nedmsmith :) |
Awesome; thanks both of you! Also, always super interested to hear about new use cases. If not something that can be public in text, I'm always happy to hop on a call sometime 😃 |
Hey @pdxjohnny 👋 In principle, if you're willing to deterministically encode the CWT, then you should be able to use the canonicalization spec and/or ucan-ipld to convert to/from CWT. Does that meet your CWT needs? |
It would be great if ucan could support CWT as well as JWT for embedded us cases.
This would also pave the way for interoperatbility with attesttation frameworks such as DICE
References:
The text was updated successfully, but these errors were encountered: