ucan-wg / invocation

UCAN Invocation & Pipelining
Other
12 stars 5 forks source link

Passing authorization as args #31

Open Gozala opened 6 months ago

Gozala commented 6 months ago

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 you crud/write permission to write output.

At the moment it is not obvious where proof chains for crud/read and crud/write should go to make it all work. I think it would make sense to address this in spec in some way.

Gozala commented 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.

Gozala commented 6 months ago

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.