UCAN v0.9.0

[expede]

• 👉 Preview Render 📃

• 35

Change Log 🪙🪵

Added 📥

• [x] Explicitly restrict keys to RSA, ECDSA, and EdDSA per @ukstv
• [x] Standardize on "proof" instead of "witness" (see https://github.com/ucan-wg/spec/discussions/23)
  • At minimum it leaves the door open for renaming later; we already call them proofs
• [ ] Revocation spec Staying the same, see comment: https://github.com/ucan-wg/spec/pull/55#discussion_r844809873
• [x] Standardize on "ability" and not "action"
• [x] Break out caveats fields, per @gozala https://github.com/ucan-wg/spec/discussions/61
• [x] Replace my:... URI with "my" parenthood field
• [x] Changes to UCAN DAG representation
  • [x] CARv2 Agnostic collections
  • [x] Proofs enforced as CIDs only

Removed 📤

• [x] Remove IPFS/DHT requirement
• [x] Remove URI selection by scheme (e.g. no more "with": "dns:*")
  • This was actually very bad and broke the URI contract

Move Out of Core Spec 🪁

• [x] Consider extending my: to all parenthood cases, even specific values (CC @matheus23)
• Transport agnostic point-to-point protocol
• HTTP cache header protocol <- HTTP stuff should live in own spec
• Resource selection (e.g. "with": "ucan:uri:dns")

Resolves 🛠️

• Closes #61
• Closes #77

[expede]

cc @dholms FYI this is going to include removal of the DHT dependency, and replace it with a point-to-point (e.g. HTTP) protocol. If you have any thoughts on this direction, this is the time! 😉

[expede]

Added this line to the 0.9 roadmap:

Consider extending my: to all parenthood cases, even specific values (CC @matheus23)

https://github.com/ucan-wg/spec/issues/21#issuecomment-1091400629

[ukstv]

Hey, I might be missing something here, but as far as I understand, UCAN thing is not really a valid JWT, even in this form. You mention mandatory support of did:key. Apparently, it allows using some exotic signature suites like BLS, which can not be really supported in older JWT libraries, as it does not belong to JOSE algorithms (AFAIK!). Do you apply some constraints on the list of available algorithms, like using only ed25519 and RSA did:key, or is the whole backwards compatibility story a bit of a misnomer?

If my basic understanding is correct, then UCAN supports did methods that use JOSE algorithms exclusively. How can it be both compatible with existing JWT tooling and support advanced did methods?

[expede]

@ukstv Technically DID can support any signature scheme, yup! Today we support EdDSA, ECDSA, and RSA only, which are all in JWT. IIRC EdDSA is in a separate JOSE extension IETF spec, but is extremely widely supported in libraries (it's de facto supported).

We should absolutely be explicit about this in the spec. We also don't allow HMAC verification.

A library supporting more methods "off spec" is possible today (we've done proof of concepts with ION, for example), but can't expect that to be compatible with "any" other implementation. The spec if just here to be the line of "what is interoperable".

If there's a good case made, we're open to effectively forking JWT (at which point, we drop the weird multi-section formatting with .s and stuff, trim a few bytes from redundant fields, etc). Using JWT as-is has a few arguments:

1. Easy to build new implementations out of existing components
2. Extensive tooling (though not for the UCAN parts — we've started on some at ucan.xyz)
3. Familiarity for web devs / "sell to management"

[expede]

I flipped this to Ready for Review. I think that we're mainly on the same page about the scope of 0.9 from the conversation above, but please do mention anything that should or should not be in here. I think the most controversial things will be:

1. Requiring my: for introduction by parenthood
2. The label nb for extensible fields

Open to folks flagging typos or nitpicks. VERY open to approvals 😜

[expede]

left some suggestions to fix typos.

@hugomrdias Thank you for the copy editing 👏👏👏

[expede]

@olizilla 🙏 thank you very much for fixing the links. The spec likely needs to move to a specialized spec format instead of Markdown. I had trouble getting the W3C one running on my M1, but clearly it's time to just bite the bullet and get it working in a Docker container or something 😅

[expede]

@dholms if you have a few minutes I'd love a ✅ or any comments!

[expede]

Okay, I'm going to wrap this up like... today. Just integrating the last bit of feedback from @Gozala & @hugomrdias from a call a few weeks back, and agonizing over:

1. Whether or not to rip ucan:as: out of the core spec
2. If SUPER_USER is needed separately from * (and add more rationale to the spec if it is)

[expede]

FYI @matheus23 ☝️

[expede]

@hugomrdias when you get a second, could you give the latest version a skim and check if it hits the points that you had hoped from our call a few weeks ago? I think I covered it all in the call earlier today, and updated this PR's description. Just looking for a quick 👍 / 👎

[Gozala]

Okay, I'm going to wrap this up like... today. Just integrating the last bit of feedback from @Gozala & @hugomrdias from a call a few weeks back, and agonizing over:

Whether or not to rip ucan:as: out of the core spec If SUPER_USER is needed separately from * (and add more rationale to the spec if it is)

@expede thanks for incorporating all the improvements, new spec is shaping up to be really nice IMO.

I did notice few things with current draft:

1. with: my:*, can:* is gone now and no equivalent in my: {} had been specified. If I recall correctly plan was to represent it as my: { with: ucan:*, can: * }
2. I still think can: ucan/delegate is still confusing and spec fails to specify why not can: *. If they need to be different I think spec should at least describe how two compare when used with: ucan:…

For what it’s worth we pretty much settled on using own did:key:… for ambient authority as it’s credibly verifiable & requires no checks.

I honestly think it is much better model as things can be verified without db lookups. Other things can also map e.g did:key:zAlice:email etc… This also removes need for :as: because you can just use with: did:key:zAlice:* can: * to redelegate all that had been delegated to you by Alice

[expede]

@Gozala thanks for the feedback! 🚀

with: my:, can: is gone now and no equivalent in my: {} had been specified. If I recall correctly plan was to represent it as my: { with: ucan:, can: }

Yeah 💯 agreed — I noticed this late Friday 😅 I've been playing with a few ideas for it since we need it in the AWAKE spec as well. I hope to have something concrete today. Current thinking is something like this:

We have two orthogonal factors: selection by scheme (ucan:*:<scheme> or similar), and selection by owner (ucan:as:<did>:<resource> or similar). These need to get combined in some cases, for example to say "all DNS records owned by Alice". In AWAKE we currently added a as: field (similar to the my: field), but I think for ownership it's probably cleaner as a URI. I'll have a proposal shortly.

I still think can: ucan/delegate is still confusing and spec fails to specify why not can: *. If they need to be different I think spec should at least describe how two compare when used with: ucan:…

Fair! I'll expand the reasoning in the spec.

For what it’s worth we pretty much settled on using own did:key:… for ambient authority as it’s credibly verifiable & requires no checks.

This is exactly the solution space from the above ucan:as comment. We definitely need something for this use case. I think that what you're describing is what as: does — we may be talking past each other on what these do.

On did:key:zAlice:* — I don't think that we can use the did: scheme directly, and will likely need a prefix like ucan:as:<did>, because of how the existing did URI scheme works (i.e. you cannot write did:key:zAlice:* with DID v1.0, and may conflict with other DID subschemes). You won't have enough enough flexibility beyond "everything", or clarity of "resources for this DID" versus "control of the DID document itself". Prefixing this with ucan:as: or similar gives us full control over the semantics of the subschemes.

For what it’s worth we pretty much settled on using own did:key:… for ambient authority as it’s credibly verifiable & requires no checks.

Can you expand on this? Based on my reading of this, you would still need to check which resources are ambiently owned by Alice, unless that resource was self-authorizing (e.g. the data lists Alice as its owner directly on it). You'll need to find the resource outside of the UCAN at some stage. Do you perhaps mean prefixing the owner of every resource, and treating it as a null pointer if that doesn't resolve to a resource owned by them in the real world? (Which sounds equivalent, but I could totally be missing something)

[Gozala]

@expede I have evaluated changes required to switch from "my:*" schema to "my" field in our implementation and I'm afraid I'm arriving to conclusion that this idea may have been a bad one. I feel bad for pushing for it without evaluating it first, but maybe it is not too late to reconsider ? Here are some of my the unstructured thoughts about it:

• UCAN validator needs to recognize which capabilities can be issued by an actor to distinguish them from ones that are delegated.
  • ucanto validator provides canIssue(capability, issuer): boolean hook to make that configurable.
  • By default it is uses canIssue(cap, iss) => cap.with === iss, implying that only owner of the did can issue capabilities for that did.
  • ucanto does not recognized my:* as one that actor can issue, instead it has my(iss): cap[] hook which is used to expand my:* forms and then select matches from it.
• In other domains decisions made by ucanto may not fit so there needs to be another signaling mechanism which used to be e.g my:wnfs://....
  • However it seems that validating that would still require out of bound checks that claimed resource is actually owned by user.
• I think signaling whether capability is owned by iss or not should be left out of spec that way ucanto can use it's did matching logic while other implementations may embrace my: schema

[expede]

@Gozala

but maybe it is not too late to reconsider ?

I've been waiting for your review exactly for this reason 👍

I think signaling whether capability is owned by iss or not should be left out of spec that way ucanto can use it's did matching logic while other implementations may embrace my: schema

I'd love to dig into this more, because I'm having a hard time piecing together how the validation and rooted authority would work in this version. A sync call may be the fastest way to iterate on some ideas, but let me know! I'll ping you on Discord.

[expede]

@Gozala several your comments seems to be on old code — not sure what's happening there. For example: