Capyloon Feedback

[expede]

First off, a huge thank you to the Capyloon team, who have done an experimental UCAN integration 🎉🎉🎉 The feedback from this project is invaluable.

They posted some of their experience with UCAN here: https://github.com/capyloon/nutria/blob/main/did_and_ucans.md

And there's a few messages in this Twitter thread (I'm attempting to direct the conversation here, per @hugomrdias's suggestion)

[expede]

Ported from the aforementioned Twitter thread:

@expede

I do wonder if the stolen use case they cite is inherent to the design or a bug in the implementation, since they would also need the private key to use the UCAN again 🤔 Let’s make it to the GH Discussion for sure, though!

---

@hugomrdias

Exactly UCAN should be bound to the secure context of the keypair (audience). For the web that should be an origin, for mobile a secure element etc. As for reuse one would the need the token leaked and access to the audience private key.

---

@expede

Exactly yeah 💯

That said, I’m SUPER EXCITED that there’s experimentation happening with these directly in browsers. Very useful source of feedback 🚀

Even if it turns out to be “only” a matter of clarifying in the spec / clearer in the libraries, that’s really good to know!

---

@fabricedesre

I don't understand why you need the audience private key to validate the ucan? The issuer does the validation with the just the token as in https://docs.rs/ucan/0.6.0-alpha.1/ucan/ucan/struct.Ucan.html#method.validate

---

@expede

You don't need the audience's private key, but to need the issuer's private key to invoke it. UCANs are "single use" for invocation, so you have to prove that you have that key on each invocation. A theft of credential via delegation would require the secret key, as well.

[expede]

The idea here is that a UCAN shouldn't be reused on invocation. We make this clearer in the 0.8 and 0.9-WIP specs, but I believe that the Rust 0.6 Alpha that they're working from doesn't implement a single-use invocation check as of yet. (@cdata please do correct me if I'm wrong — also not in any way meant to disparage the Rust implementation!)

[fabricedesre]

By "not reuse on invocation" do you mean that issuers need to track the tokens they created and make sure they are only used once afterwards?

[expede]

Not the issuers: the recipients who are performing some action (invocation). If you're a web server, and you receive a UCAN to fulfill a request, the server's DID MUST be the audience, the token SHOULD be short lived, and unique (e.g. use the nnc nonce field or a different expiry time). This means that as the party executing the capability, you only need to track the hashes of unexpired UCANs. For example, at Fission we use a 30-second expiry, but you could elect to go higher to avoid clock drift.

Since the server in the above scenario is the aud, no one else can execute the request. For replay, and the hash ensures that it's a unique request and cannot be replayed. You never need to track the hashes of expired or invalid tokens — expired hashes can be garbage collected. This should get built directly into all libraries, so that you don't have to do all of this tracking yourself.

There's an additional case where the aud server redelegates to another collaborating service to fulfill the request (e.g. they need an email sent by another provider). This is delegation, not invocation, and the email provider would track the invocation hashes.

There is an edge case where a PITM gains access to a UCAN and can use it to perform that one request prior to expiration and before the issuer notices. Typically this means having some way around TLS. The issuer stays in control of issuing credentials, and the PITM can only make those exact requests (which is less to do with UCAN and more to do with secure channels). They cannot be redelegated by a PITM without the issuer's secret key. (We actually have a PITM-resistent secure channel bootstrap based on UCAN called "AWAKE", which is kind of like a fancy mTLS, but that's another discussion 😛)

[cdata]

This is a small aside, but responding to your comment:

When reading the spec, I (mis)interpreted the receiving agent to refer to the user of the UCAN implementation, not the implementation itself. So, I did not think to include facilities for automatically checking for re-used tokens.

This is certainly something we can implement as part of the library.

[fabricedesre]

Ok... So I probably made some mistakes with the different roles in my implementation. In Capyloon there are no remote servers, but the same role is fulfilled by local APIs (current a VFS one).

What we have is:

1. a DID created to represent the user on device.
2. when a 3rd party web page wants to access the VFS api, it requests capabilities for its own DID. The token is issued on behalf of the DID from 1. using the page DID as the audience.
3. when the 3rd party web page want to run an api call, the API validates the token signature and time range, and checks that the token issuer is the same as in 1.

[cdata]

Again, sorry for the aside, but FYI ucan-wg/rs-ucan#14