DRAFT: DagJWS CACAO #162
DRAFT: DagJWS CACAO #162
Conversation
|
Fixed formatting, added dagjws payload note, and added full example |
| Example IPLD dag-jose encoded block, strings abbreviated. | ||
|
|
||
| ```tsx | ||
| { | ||
| cid: "bagcqcera2mews3mbbzs...quxj4bes7fujkms4kxhvqem2a", | ||
| value: { | ||
| jws: { | ||
| link: CID("bafyreidkjgg6bi4juwx...lb2usana7jvnmtyjb4xbgwl6e"), | ||
| payload: "AXESIGpJjeCjiaWv...LKw6pIDQfTVrJ4SHlwmsvx", | ||
| signatures: [ | ||
| { | ||
| protected: "eyJhbGciOiJFZERTQSIsImNh...GU2djZEpLTmhYSDl4Rm9rdEFKaXlIQiJ9" | ||
| signature: "6usTYvu5KN0LFTQsWE9U-tqx...h60EgfvjL_rlAW7_tnQUl84sQyogpkLAQ" | ||
| } | ||
| ] | ||
| } | ||
| } | ||
| } | ||
| ``` |
There was a problem hiding this comment.
Can we use the full example with non-abbreviated strings?
So that you can test an implementation against it.
There was a problem hiding this comment.
would it make sense to
1.) publish a sample/reference IPLD block and pin it for posterity, then
2.) link to it from the spec as an https://{cidv1}.ipfs.dweb.link/ link?
and/or
3.) put the entire IPLD block into an /assets/ folder in this repo and link to that from the spec as well to help people make sure they're fetching/deserializing/etc properly ?
i might be taking this whole test vector thing too far but i'm sure the folks at PL outercore would appreciate my asking for this to be extremely n00b-friendly to help with ipfs outreach :D
There was a problem hiding this comment.
test vectors are always nice, but not sure if makes sense for this spec here
This spec mostly describes how to use a cacao with a JWS, ie adding cacao in header and how to verify, it then also happens to be encoded in dag-jose, i think most of serialization/pathing/etc is entirely covered by dag-jose and would be covered by any tests vectors there and some verification is already covered by cacao spec, thanks for commenting!
|
|
||
| **“cap” Header Parameter** | ||
|
|
||
| The `cap` parameter maps to a URI string. ln the scope here this is expected to be an IPLD CID resolvable to a CACAO object. |
There was a problem hiding this comment.
maybe it's worth adding to this section a little more syntax
- i.e. does the URI have to be dereferenceable? ipfs:// only or is https://{cidv1}.{gateway} or "/{cid}" acceptable?
and some semantics
- i.e. when dereferenced do you always get an IPLD object describing capabilities? is it cacao-formatted by default? where would someone look to make sense of what they get back if it isn't? etc.
|
Is it possible to adopt more of a "should" and "recommended" approach for the CACAO object? By that I mean that use of a CACAO could be recommended but any authorisation-delegating token is possible. I'm thinking of UCANs, but in principle I think any "appropriate" alternative may be allowed. Language in this spec which references particular features of CACAO (e.g. comparing the Overall I think this fills a good niche in both UCAN and CACAO for a common ipld-native invocation token format, which is unspecified so far. |
This is exactly what's intended here :) The |
|
Going to close soon instead of move forward, in favor of a future specification that builds on #196 and supports both cacao/ucan and other changes there |
|
Closing while #196 works out-- Zach will reopen/start over after |
Create and verify IPLD based JWS payloads using chain-agnostic Object Capabilities and blockchain accounts.