search

dckc / awesome-ocap

Awesome Object Capabilities and Capability Security
The Unlicense
335 stars 24 forks source link

Adding UCANs - User Controlled Authorization Networks #40

Open tgrecojs opened 10 months ago

tgrecojs commented 10 months ago

The UCAN project makes use of capabilities for the purpose of handling authorization in a manner in which POLA can be enforced. In short, UCANs eliminate reliance on an authorization server to dole out user privileges. More can be found out about the project at the following links:

tgrecojs commented 10 months ago

@dckc if you're interested in adding this project and would like assistance, then let me know. It seems like it would fit within "Applications and Services".

dckc commented 10 months ago

Hm. Seems more like a format than app or service. An app is something I can run. How do I run UCAN? A service is something I can make requests of. How do I make a request to UCAN?

Apps and services are ready-to-run. This looks some-assembly-required, like a library or programming language.

tgrecojs commented 10 months ago

Hm. Seems more like a format than app or service. An app is something I can run. How do I run UCAN? A service is something I can make requests of. How do I make a request to UCAN?

Ahh, that was my mistake.

A UCAN can't be run, nor can requests be made of it. A service can support requests containing UCANs. And applications can support authentication by use of UCANs.

And your observation of UCAN seeming more like a format than an app or service is correct - it is a specification that extends JSON Web Tokens. Apologies for the mix-up.

dckc commented 10 months ago

In browsing around, I found a July 11 message from Matt Rice:

It seems like the UCAN text author considers it a capability system, or at least to be isomorphic to one...

That suggests that I should be able to take any UCAN service and split it between the signature processing stuff and a normal ocap API. Likewise a client.

The ag-solo protocol does this, for example. In the Agoric REPL, when you make an eventual send to an on-chain object, a message gets serialized and signed and sent to the chain. This is sort of the vattp layer. Then, on chain, it gets de-serialized and forwarded on to the relevant object in the relevant vat.

Looking at the ucanto filesystem service example, I can't see how to organize it to work this way. I don't see an isomorphism between UCAN and ocaps.

If you can see how it works, would you show me how a hello-world example using makeCounter() would work?