V0.2 #15
V0.2 #15
Conversation
|
Progress report:
Updated the schema and general layout of the doc. I think if we agree on the schema, we lock that in and I can wrap up cleaning up the prose etc to reflect the chanegs through Friday. cc @Gozala & @zeeshanlakhani |
|
Yeah, I'm not so keen on that per se, as it can get problematic over time, but maybe @expede has thoughts on another approach for internals. |
README.md
Outdated
| meta {String : Any} | ||
| type Authorization struct { | ||
| scope [&Any] # The set of authorized links | ||
| auth Authorization # Scope signed by the invoker |
There was a problem hiding this comment.
I think you didn't mean to change it.
| auth Authorization # Scope signed by the invoker | |
| s VarSig # Scope signed by the invoker |
README.md
Outdated
| type InvocationCapsule struct { | ||
| inv Invocation (rename "ucan/invoke@0.2.0") | ||
| } |
There was a problem hiding this comment.
| type InvocationCapsule struct { | |
| inv Invocation (rename "ucan/invoke@0.2.0") | |
| } | |
| type InvocationCapsule union { | |
| | Invocation "ucan/invoke@0.2.0" | |
| } representation keyed |
README.md
Outdated
| type Receipt struct { | ||
| ocm Outcome | ||
| sig Varsig | ||
| } |
There was a problem hiding this comment.
This comment...
ChainAgnostic/varsig#6 (comment)
...mentions this...
...which is also my assumption about how varsig will work. If that gets merged, we could consider not having a Receipt wrapper here at all, since it would be redundant.
There was a problem hiding this comment.
I was assuming that we sign Outcome and not the Receipt without sig.
Co-authored-by: Irakli Gozalishvili <contact@gozala.io> Signed-off-by: Brooklyn Zelenka <be.zelenka@gmail.com>
README.md
Outdated
| type Invocation struct { | ||
| v SemVer | ||
| ```Task | ||
| type Context struct { |
There was a problem hiding this comment.
@expede should be type Task no? Task is in the markdown, but that's odd. Later we have https://github.com/ucan-wg/invocation/pull/15/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R207 which is the same?
README.md
Outdated
|
|
||
| ## 5.2 (Signed) Invocation | ||
|
|
||
| An `Invocation` is a signed `Context`. |
There was a problem hiding this comment.
minor: we don't have Context as a thing in the updated doc :).
|
|
||
| # All the other metadata | ||
| meta {String : Any} | ||
| meta {String : Any} # All the other metadata | ||
|
|
||
| # Principal that issued this receipt. If omitted issuer is |
There was a problem hiding this comment.
going off the Ucan spec, is this not Principle?
There was a problem hiding this comment.
Oh, that would be a typo iun the UCAN spec then 😅 For example, from the JWT spec:
The "iss" (issuer) claim identifies the principal that issued the JWT.
There was a problem hiding this comment.
The UCAN spec actually uses both senses of principle/principal, which can be confusing:
Following the principle of least authority
...and...
6.2 Principal Alignment
There was a problem hiding this comment.
ah yes. rs-ucan uses Principle (in the code) haha.
There was a problem hiding this comment.
Oh LOL we should probably fix that
|
A bunch of this is moving to https://github.com/ucan-wg/invocation-ipld/pull/1 FYI: I'm forking this branch to do the high level invocation spec |
|
Where are we with this, can this be merged ? We'd like to ship invocation spec but there's quite bit a difference between what's in the main branch and here. If we moving to this it would really help to have thing merged or at least field renames so they aren't completely different. |
|
Closing in favour of #21 |
Preview 📄
Changelog
ontouri