Open Gozala opened 6 months ago
One detail that came up in the side channel is that what we pass as arguments SHOULD NOT be invocations, because we may not know all the args ahead of time. For example we may give access to crud/read
but audience should have flexibility to parametrize range which they are going to read.
In the side channel we got tentative agreement to do something along the lines of
{
iss: "did:key:alice",
aud: "did:key:bob",
prf: ["bafy...dan-to-alice", "bafy...bob-to-dan"],
cmd: "/pipe",
args: {
pipe_from: {"ucan/a@1.0": ["bafy...ucan-alice-to-bob", "bafy...carol-to-alice"]},
pipe_to: {"ucan/a@1.0": ["bafy...alice-to-bob-again"]}
}
}
Where ucan/a@1.0
is capsule type for the delegation chain to which we want to give more formal name. Note that we don't use capsule in the prf
field because type is implied from the context.
We have use cases for passing authorization to invoke some ability as part of invocation args e.g. I want you to compile HTML from this markdown source and write output to specific destination. Source is not publicly readable so I need to give you read permission e.g.
crud/read
for it and I also need to give youcrud/write
permission to write output.At the moment it is not obvious where proof chains for
crud/read
andcrud/write
should go to make it all work. I think it would make sense to address this in spec in some way.