Skip to content
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

Passing authorization as args #31

Open
Gozala opened this issue Feb 28, 2024 · 2 comments
Open

Passing authorization as args #31

Gozala opened this issue Feb 28, 2024 · 2 comments

Comments

@Gozala
Copy link
Contributor

Gozala commented Feb 28, 2024

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
Copy link
Contributor Author

Gozala commented Feb 28, 2024

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
Copy link
Contributor Author

Gozala commented Feb 28, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant