Update capabilites in line with Ucan 0.9.0/0.10.0

[jsantell]

Initial work on updating to support latest capabilities in Ucan spec 0.9.0/0.10.0, with a goal of moving closer to the final serializable shape.

• Represents capabilities as map-of-maps rather than array of tuples.
• Renames 'att' to 'cap' (Ucan spec 0.10.0).
• Addresses/fixes #22 (or what it turned into in 0.10.0)

Looking for feedback on:

• Leaves caveat parsing up to consumer -- we can filter out capabilities that must be invalid (e.g. empty caveats []) in reduce_capabilities(), or we can introduce a semantical layer (as part of CapabilitySemantics<S, A, C>), but unclear what that looks like and how it would work.
• Unclear what kind of ordering, if any, should be enforced (#100)
• Renames 'Capability' to 'CapabilityView' -- other renaming within semantics that could use some improvements

[codecov-commenter]

Codecov Report

Merging #105 (b4a9ebc) into main (3d30ec8) will increase coverage by 1.31%. The diff coverage is 64.06%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

Additional details and impacted files

[](https://app.codecov.io/gh/ucan-wg/rs-ucan/pull/105?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=ucan-wg) ```diff @@ Coverage Diff @@ ## main #105 +/- ## ========================================== + Coverage 57.10% 58.42% +1.31% ========================================== Files 24 23 -1 Lines 802 849 +47 Branches 196 207 +11 ========================================== + Hits 458 496 +38 + Misses 206 204 -2 - Partials 138 149 +11 ``` | [Impacted Files](https://app.codecov.io/gh/ucan-wg/rs-ucan/pull/105?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=ucan-wg) | Coverage Δ | | |---|---|---| | [ucan/src/chain.rs](https://app.codecov.io/gh/ucan-wg/rs-ucan/pull/105?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=ucan-wg#diff-dWNhbi9zcmMvY2hhaW4ucnM=) | `62.61% <50.00%> (+0.71%)` | :arrow_up: | | [ucan/src/ucan.rs](https://app.codecov.io/gh/ucan-wg/rs-ucan/pull/105?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=ucan-wg#diff-dWNhbi9zcmMvdWNhbi5ycw==) | `67.36% <50.00%> (-1.45%)` | :arrow_down: | | [ucan/src/capability/semantics.rs](https://app.codecov.io/gh/ucan-wg/rs-ucan/pull/105?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=ucan-wg#diff-dWNhbi9zcmMvY2FwYWJpbGl0eS9zZW1hbnRpY3MucnM=) | `44.79% <62.96%> (+9.14%)` | :arrow_up: | | [ucan/src/capability/data.rs](https://app.codecov.io/gh/ucan-wg/rs-ucan/pull/105?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=ucan-wg#diff-dWNhbi9zcmMvY2FwYWJpbGl0eS9kYXRhLnJz) | `66.10% <66.10%> (ø)` | | | [ucan/src/builder.rs](https://app.codecov.io/gh/ucan-wg/rs-ucan/pull/105?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=ucan-wg#diff-dWNhbi9zcmMvYnVpbGRlci5ycw==) | `78.00% <66.66%> (-1.00%)` | :arrow_down: | | [ucan/src/ipld/ucan.rs](https://app.codecov.io/gh/ucan-wg/rs-ucan/pull/105?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=ucan-wg#diff-dWNhbi9zcmMvaXBsZC91Y2FuLnJz) | `71.11% <100.00%> (ø)` | | ... and [1 file with indirect coverage changes](https://app.codecov.io/gh/ucan-wg/rs-ucan/pull/105/indirect-changes?src=pr&el=tree-more&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=ucan-wg)

[cdata]

Oh, should also call out that as of this change we will likely be removing support for UCAN IPLD (to be re-introduced at some future date as the spec is updated to be coherent with v0.10.0+).

[jsantell]

Now with working caveats, testing the cases in the spec.

• There are a few number of Capability representations, but unavoidable IMO. Names could be improved (e.g. CapabilityView).
  • Capabilities representing the "serialized" map-of-map nature of the changes in UCAN 0.9/0.10.
  • Capability are deconstructed, "deserialized" individual capabilities generated from Capabilities, reduced to a single resource/ability/caveat per. This form is in-line with the current implementation, and the easiest way (IMO) of working with capabilities.
  • CapabilityView, a Capability imbued with semantics, used in proof reduction and validation.
• Renames With=>Resource, Action=>Ability, Resource=>ResourceURI -- not happy with ResourceURI naming. This may also change when swapping out my/as with ucan, etc. Open to ideas for naming in src/capability/ as well e.g. data.rs.
• I wanted to add non-semantical capabilities when writing tests, introducing (the poorly named) UcanBuilder::claiming_capability_from_data and UcanBuilder::claiming_capabilities_from_data functions. As semantics are only used in proof chain reduction, claim_capability/claim_capabilities could ingest the data forms, and we introduce a new method to build via semantics/views. Additionally, other tests could use these "raw capabilities", as only proof chain parsing needs to imbue semantics as well.

[jsantell]

Updated:

• UcanBuilder::claiming_capability now generic over C: Into<Capability> and UcanBuilder::claiming_capabilities for the &[C] variant.
• Removed the now extraneous clone() and into() for previous claiming_capability implementations
• Linked spec where appropriate in doc comments