feat!: wildcard support in capabilies

[Gozala]

Fixes #87

We need this to make authorization protocol able to support more granular delegations without specifying exact space DID. And we do not want to specify exact space DID to avoid having to recreate UCAN delegations chains and instead add desired proofs. Specifically consider following scenario

1. did:key:zSpace delegates to did:mailto:web.mail:alice
2. did:mailto:web:mail:alice authorizes did:key:zAgent
3. did:key:zAnotherSpace delegates to did:mailto:web.mail:alice

Unless in step 2 with field is open ended like did:*, agent did:key:zAgent will not have access to new did:key:zAnotherSpace even though it would be able to get it through access/claim.

Changes here implement native support for wildcards in can and with fields and consequently address above described limitation. Furthermore it eliminates need for boilerplate capabilities we had to use

Please note that implementation correctly handles unintended escalation like:

{ can: "store/*", with: "did:*", size: 100 }
                ^
                |
{ can: "store/*", with: "did:*" }
                ^
                |
{ can:"store/add", with:"did:key:zAlice", size:200 }

To make this work when validator parses (middle) capability it inherits information from the outer (bottom) capability and comes out just like bottom one in this instance. By doing this validator correctly identifies escalation (200 > 100) in the next step.

[gobengo]

see https://github.com/web3-storage/ucanto/pull/218/files#r1100550414

IMHO it's not obvious to me from ucan-wg/spec that middle dev/* should authorize this, because spec doesn't say anything about special semantics for dev/* syntax

[Gozala]

So delegation chain we have here is as follows (where top on is ambient authority by ownership, which is also something UCAN spec has no opinion on)

{ with: did:key:zAli, can: * }
         ^
         :   - by Ownership to Alice
{ with: did:*, can: * }            =>  { with: did:key:zAli, can: * }
         ^
         |   - by Alice to Bob
{ with: did:*, can: dev/* }        => { with: did:key:zAli, can: dev/* }
         ^
         |   - by Bob to Mallory
{ with: did:*, can: * }            => [{ with: did:key:zAli, can: dev/* }, { with: did:key:zBob, can: * }]
         ^
         |   - by Mallory to W3
{ with: did:key:zAli, can: 'dev/ping', nb: { message: 'hello'}  }

If you follow the chain you can see all the constraints that had been imposed at every layer (spec calls it diminishing) yet despite all the the constraints bottom is still true.

Now one could argue that Bob is escalating when delegating to Mallory, yet I think it goes against intuition and there is a discussion to spec this pattern because otherwise we have keep recreating chains every time some agent gains more capabilities, for details see:
ucan-wg/spec#130
ucan-wg/spec#131

[gobengo]

Is this capability2.js file imported anywhere?

[gobengo]

what is intended difference between capability.js and capability2.js (if any)

[Gozala]

oops, I did not intend to include that file

[Gozala]

I have chatted with @expede about ways to express "everything, everywhere delegated or owned" resources we've decided we can express this as ucan:*. We'll likely spec ucan: protocol in more detail, but right now I just updated implementation replacing generic URI pattern with only ucan:* form. We can add support for other forms once they get speced.

[alanshaw]

Yeah this is awesome 🎉

[alanshaw]

Should be resolveResource in these examples not resolveAbility?