UCAN

[Alan Karp]

User Controlled Authorization Network is a standard in progress for managing access rights.  It uses capabilities based on SPKI but with JWTs.  I am currently reading the spec, https://github.com/ucan-wg/spec/, and I am puzzled by the section below.

Is it necessary to merge capabilities in the way they describe?  I would think you would just use the one with the smallest scope (to use their term) necessary for what you want to do. 

--------------
Alan Karp

2.4 Capability Scope

The set of capabilities delegated by a UCAN is called its "capability scope," often shortened to "scope." This functions as a declarative description of delegated abilities.

Merging capability scopes MUST follow set semantics, where the result includes all capabilities from the input scopes. Since broader capabilities automatically include narrower ones, this process is always additive. Capability scopes can be combined in any order, with the result always being at least as broad as each of the original scopes.

                 ┌───────────────────┐  ─┐
                 │                   │   │
                 │                   │   │
┌────────────────┼───┐               │   │
│                │   │ Resource B    │   │     
│                │   │               │   │       BxZ
│                │   │     X         │   ├─── Capability
│     Resource A │   │               │   │
│                │   │ Ability Z     │   │
│         X      │   │               │   │
│                │   │               │   │
│     Ability Y  │   │               │   │
│                └───┼───────────────┘  ─┘
│                    │
│                    │
└────────────────────┘

└──────────────────┬─────────────────┘
                   │

               AxY U BxZ
                 scope

The capability scope is the total rights of the authorization space down to the relevant volume of authorizations. Individual capabilities MAY overlap; the scope is the union. Except for rights amplification, every unique delegation MUST have equal or narrower capabilities from their delegator. Inside this content space, you can draw a boundary around some resource(s) (their type, identifiers, and paths or children) and their capabilities.

For example, given the following scopes against a WebNative filesystem, they can be merged as follows:

// "wnfs" abilities:
// FETCH < APPEND < OVERWRITE < SUPERUSER

ScopeA = [
  { "with": "wnfs://alice.example.com/pictures/", "can": "wnfs/APPEND" }
];

ScopeB = [
  { "with": "wnfs://alice.example.com/pictures/vacation/", "can": "wnfs/APPEND" };
  { "with": "wnfs://alice.example.com/pictures/vacation/hawaii/", "can": "wnfs/OVERWRITE"}
];

merge(ScopeA, ScopeB) == [
   {"with": "wnfs://alice.example.com/pictures/", "can": "wnfs/APPEND"},
   {"with": "wnfs://alice.example.com/pictures/vacation/hawaii", "can": "wnfs/OVERWRITE"}
   // Note that ("/pictures/vacation/" x APPEND) has become redundant, being contained in ("/pictures/" x APPEND)
];

[William ML Leslie]

On Fri, 26 Aug 2022 at 08:32, Alan Karp <alan...@gmail.com> wrote:

User Controlled Authorization Network is a standard in progress for managing access rights.  It uses capabilities based on SPKI but with JWTs.  I am currently reading the spec, https://github.com/ucan-wg/spec/, and I am puzzled by the section below.

Is it necessary to merge capabilities in the way they describe?  I would think you would just use the one with the smallest scope (to use their term) necessary for what you want to do.

I am concerned that by treating the resource and the permissions separately in this case, they have opened this system up to confused deputy problems.  It's not clear what problem they were trying to solve, though.  My first guess is that they want to give each service one credential that can be used on multiple resources, which does not sound like a good path to head down.

Maybe you could reach out to Brooklyn or the team to find out more?

--

William ML Leslie

[Ben Laurie]

On Thu, 25 Aug 2022 at 23:32, Alan Karp <alan...@gmail.com> wrote:

User Controlled Authorization Network is a standard in progress for managing access rights.  It uses capabilities based on SPKI but with JWTs.  I am currently reading the spec, https://github.com/ucan-wg/spec/, and I am puzzled by the section below.

Is it necessary to merge capabilities in the way they describe?  I would think you would just use the one with the smallest scope (to use their term) necessary for what you want to do. 

Quite. Also...

 

--------------
Alan Karp

2.4 Capability Scope

The set of capabilities delegated by a UCAN is called its "capability scope," often shortened to "scope." This functions as a declarative description of delegated abilities.

Merging capability scopes MUST follow set semantics, where the result includes all capabilities from the input scopes. Since broader capabilities automatically include narrower ones, this process is always additive. Capability scopes can be combined in any order, with the result always being at least as broad as each of the original scopes.

...I hate this. This implies that a correct merge of two caps could be the universal cap. Which is obviously dumb.

 

                 ┌───────────────────┐  ─┐
                 │                   │   │
                 │                   │   │
┌────────────────┼───┐               │   │
│                │   │ Resource B    │   │     
│                │   │               │   │       BxZ
│                │   │     X         │   ├─── Capability
│     Resource A │   │               │   │
│                │   │ Ability Z     │   │
│         X      │   │               │   │
│                │   │               │   │
│     Ability Y  │   │               │   │
│                └───┼───────────────┘  ─┘
│                    │
│                    │
└────────────────────┘

└──────────────────┬─────────────────┘
                   │

               AxY U BxZ
                 scope

The capability scope is the total rights of the authorization space down to the relevant volume of authorizations. Individual capabilities MAY overlap; the scope is the union. Except for rights amplification, every unique delegation MUST have equal or narrower capabilities from their delegator. Inside this content space, you can draw a boundary around some resource(s) (their type, identifiers, and paths or children) and their capabilities.

For example, given the following scopes against a WebNative filesystem, they can be merged as follows:

// "wnfs" abilities:
// FETCH < APPEND < OVERWRITE < SUPERUSER

ScopeA = [
  { "with": "wnfs://alice.example.com/pictures/", "can": "wnfs/APPEND" }
];

ScopeB = [
  { "with": "wnfs://alice.example.com/pictures/vacation/", "can": "wnfs/APPEND" };
  { "with": "wnfs://alice.example.com/pictures/vacation/hawaii/", "can": "wnfs/OVERWRITE"}
];

merge(ScopeA, ScopeB) == [
   {"with": "wnfs://alice.example.com/pictures/", "can": "wnfs/APPEND"},
   {"with": "wnfs://alice.example.com/pictures/vacation/hawaii", "can": "wnfs/OVERWRITE"}
   // Note that ("/pictures/vacation/" x APPEND) has become redundant, being contained in ("/pictures/" x APPEND)
];

Is there a way to narrow caps? 

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z3tz5EXCdbO5JsJU4QSxus5%2BPOt16k775Czme%2B0_brYow%40mail.gmail.com.