rs-ucan: Rust crates to support UCAN-based authz

[cdata]

Open Grant Proposal: rs-ucan

Name of Project: rs-ucan

Proposal Category: core-dev

Proposer: @cdata

(Optional) Technical Sponsor: @autonome

Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT, APACHE2, or GPL licenses?: Yes

Project Description

TL;DR rs-ucan is a Rust library to help the next generation of web and native applications make use of UCANs in their authorization flows. UCANs are perfectly suited to authz flows for decentralized network applications leveraging IPFS/Filecoin, and are already being used by some Protocol Labs-adjacent projects. To learn more about UCANs and how they fit into authz flows, visit https://ucan.xyz/!

Many of the next generation of web applications are local-first, and/or communicate with decentralized infrastructure when connecting to the network. In this emerging software landscape, user accounts are no longer centrally managed. Many apps generate or utilize cryptographic key pairs to identify their users and perform actions on their behalf. Decentralized applications verify that a change is valid by leveraging cryptographic signing and verification techniques.

UCANs are an emerging scheme for managing authorization - specifically authority delegation and capability attenuation - in the decentralized network topology. A provided UCAN enables an application to verify that an actor is authorized to take an action on some user's owned state at the point where the action would be executed, without the need to consult an external source of authority. UCANs are also safe to be stored in plain text in public, and cached for the period of their lifetime.

rs-ucan is a Rust implementation of UCANs. As the author and maintainer, I'm an active participant in regular UCAN community calls. As the implementation approaches 1.0, it will be contributed as the first-party Rust implementation offered by the UCAN Working Group (ucan-wg). This grant will support me as a continue to develop the crate and push it towards a stable release.

Value

UCANs are already being implemented in Protocol Labs-adjacent projects such as web3.storage (https://github.com/web3-storage/ucanto) and Capyloon (point of use). Although there are similar emerging schemes for managing authz (such as Biscuits), UCANs have the advantage of being coherent with extant infrastructure: their default serialization is JSON, and their structure is a superset of JSON Web Tokens (https://jwt.io/). Other serializations, such as one that is deterministic and suitable for direct storage in IPLD, are being pursued by the UCAN Working Group. This Rust implementation of UCANs will be valuable for anyone implementing authz for decentralized network services, including those leveraging the emerging ecosystem of IPFS-related Rust crates.

The project is already implemented to the point of being usable and is compatible with other language implementations. The challenge now is to find the resources to push the work over the edge to a stable release.

Deliverables

A stable release of rs-ucan (https://github.com/cdata/rs-ucan), up to date with the latest revision of the UCAN spec, graduated to the UCAN Working Group's first-party Github organization (https://github.com/ucan-wg).

Development Roadmap

The UCAN spec is a living document (and has not had a 1.0 release yet), so much of the development roadmap will depend on ongoing discussions within the UCAN Working Group.

• Track releases of the spec on an ongoing basis (currently we implement 0.8.1, with 0.9 on the horizon) #11
• Add additional verification of spec compliance in the form of unit tests to ensure that capability attenuation works as expected #10
• Add support for resolving capability proofs from CIDs #9
• Complete the documentation for both ucan and ucan-key-support crates #12 #13
• Graduate the implementation to the UCAN Working Group

Total Budget Requested

$30,000 to enable maintenance, enhancement and community participation over the next year, culminating in a stable release and project graduation.

Maintenance and Upgrade Plans

My intention is to continue as primary maintainer of the project after it has had a stable release and has graduated to the UCAN Working Group. I expect that major feature work will slow a bit and that my attention will shift to shepherding community contributions. The project will continue to track closely to the UCAN spec. If it seems like major revisions are needed in the future then I may seek additional funding at that time.

Team

Team Members

• cdata
• gordonbrander

Team Member LinkedIn Profiles

• Chris Joel: https://www.linkedin.com/in/christopherjoel/
• Gordon Brander: https://www.linkedin.com/in/gordonbrander/

Relevant Experience

We are both former Googlers, with a background in Chrome and Firefox browser engineering.

Team code repositories

The latest code for the alpha release of rs-ucan can be found here: https://github.com/cdata/rs-ucan

Additional Information

Please reach me by e-mail at [email protected]

[ErinOCon]

Hi @cdata, this grant has been approved! We will send an email to you to discuss next steps!

[cdata]

Noting for posterity that we have completed two major milestones as outlined in the grant proposal:

• #9 - The core library has been enhanced to resolve UCAN proofs from CIDs (via work in #28)
• #15 - The UCAN Working Group has accepted our project as the canonical implementation of UCAN in Rust

[cdata]

Current status of this work:

• We have completed the following milestones:
  • Milestone 1: Update to 0.9 of the UCAN spec
    • We've gone a step further and made a great deal of progress towards compatibility with the 0.10 spec, which didn't exist at the time of the grant proposal
  • Milestone 3: As of 0.9 all proofs are resolved via their CID
  • Milestone 5: The UCAN Working Group has accepted our project as the canonical implementation of UCAN in Rust
• Outstanding work:
  • Milestone 2: This milestone is partially superseded by new work related to 0.10 spec compatibility (see Verify that my:* and as:* work as specified ucan-wg/rs-ucan#10). Discussions are ongoing within the working group as to how to best address Abstract over DIDs with an async verify interface ucan-wg/rs-ucan#16
  • Milestone 4: The packages continue to be in a state of incomplete documentation; we've made incremental improvement in a lot of areas but a more deliberate pass on documentation is still called for.

Overall we've continued landing meaningful improvements to rs-ucan in the time since the grant was issued. Not all of the work was covered under the grant. We intend to continue pursuing work related to the grant as we are able to prioritize it.

[ErinOCon]

Hi @cdata, we have some questions regarding your grant progress. Can you contact our team at [email protected]?