September 2023 UCAN Community Call

[heybeckyv]

Sign up: https://lu.ma/ucan

Agenda

In no particular order:

• @expede: spec updates & questions
  • Apologies for continued delays! It's been a whole thing
    • Silver lining: got some good feedback & clarity in the meantime
  • Library roadmap
    • rs-ucan updates (Quinn to cover momentarily)
    • Delegation Store 🦀🕸️
    • Revocation Store 🦀🕸️
    • Invocation RPC 🦀🕸️
  • Semantics pretty locked, all about representation now
  • The eternal JWT vs IPLD debate rages on
    • ~7% overhead (less when RSA)
    • (Non)canonicalizaton
    • Varsig still immature
  • Moved prf to Invocations
    • Clarifying who's authority vs ambient authority
• @QuinnWilton
  • rs-ucan updates (fork in the Fission org ahead of PR)

Video

YouTube Recording

Chat Log

00:06:18 Brooklyn Zelenka (@expede): https://github.com/orgs/ucan-wg/discussions/168
00:09:55 Aaron Goldman: web crypto api is a constrained environment
00:10:12 quinn: 👋 Good to see you again Aaron!
00:11:25 Philipp Krüger: Is it available without experimental flags in chrome?
00:11:30 Hugo Dias: no
00:11:36 Philipp Krüger: meh
00:13:57 Aaron Goldman: Reacted to "👋 Good to see you a..." with 😀
00:19:36 quinn: And it also means that at invocation time under the current design, the verifier needs to search through the graph of proofs given by the invocation to find a proof chain for that invocation. Since UCANs may contain multiple capabilities beyond those being invoked at some point, this search can end up being fairly complicated
00:20:41 Brooklyn Zelenka (@expede): It’ll be here when fully written up ucan-wg/invocation#21
00:20:56 Aaron Goldman: Dijkstra’s algorithm in the middle of verify 🤔
00:21:08 Brooklyn Zelenka (@expede): Not the verify, in the invocation
00:37:08 Philipp Krüger: When I was thinking about caches on the (old) haskell server, I was thinking it'd be something like keys are UCAN CIDs, and values are "these capabilities, for this length, involving these UCAN CIDs (to check against revocation)"
00:38:18 quinn: It's also not a monotonic progression from maybe-valid to invalid because validation also happens with respect to some time, and the nbf (not before) field can flip an invalid UCAN back to valid
00:38:18 Alan Karp: I would also like to discuss the current invocation spec.
00:39:26 charlescunningham: Reacted to "I would also like to..." with ➕
00:39:33 Aaron Goldman: Dose a revocation have the CID of the UCAN or the Bytes of the UCAN?
00:40:28 charlescunningham: CID, as of now
00:46:06 Philipp Krüger: I do believe that automated case should behave similarly to the non-automated case here
00:46:20 Philipp Krüger: It shouldn't matter whether Brooke is a robot or not (I should stop using this example :D )
00:46:44 Philipp Krüger: If the robot is continues re-delegating to a bad actor, then revoke it, and set it up again correctly, no?
00:47:04 charlescunningham: Or, if you’ve made 1 delegation which is being abused, then a 2nd which is for “onboarding” a new device (delegate “/: [{}]”), followed by losing or destroying the original signing TPM/device, the ability to revoke anything related to the first delegation is lost forever. This may be a logically unavoidable consequence of having a delegation model though
00:47:12 Philipp Krüger: I may be missing something. I guess I'd need a more concrete example in that case
00:47:43 Brooklyn Zelenka (@expede): Reacted to "It shouldn't matter ..." with 🤖
00:52:05 quinn: It's like shoving multi-factor auth secrets into the same password manager that holds the password so you can share accounts with your team 😅
00:54:31 quinn: If the chain becomes the resource, can you model revocation as a separate resource semantics entirely? Like with a chain: resource with a revoke ability you can delegate?
00:56:15 Brooklyn Zelenka (@expede): Some of Quinn’s work also uncovered an edge case in Varsig (which she filed an issue for)
00:57:07 Philipp Krüger: The edge case was varsig should sign over the signature algorithm bits, right?
00:57:30 charlescunningham: Is that issue on the varsig spec repo or elsewhere?
00:57:37 Brooklyn Zelenka (@expede): Yeah, you should include the algorithm in the signature envelope
00:57:44 Brooklyn Zelenka (@expede): But not all formats allow that
00:57:54 Brooklyn Zelenka (@expede): Which is frustrating, because we probably can’t force that in the spec
00:57:58 Philipp Krüger: add 💡
00:58:43 Brooklyn Zelenka (@expede): @CharlesCunningham ChainAgnostic/varsig#12
01:00:24 charlescunningham: Thanks, yeah I would suppose that varsig allowing a choice of encoding might preclude it from supporting signing over the sig type choice in the general case, but would have to think more
01:00:34 Brooklyn Zelenka (@expede): Reacted to "Thanks, yeah I would..." with 👍
01:00:35 charlescunningham: Its a good point though
01:06:52 Alan Karp: Revocation for DWN decentralized-identity/decentralized-web-node#138
01:06:59 Brooklyn Zelenka (@expede): Reacted to "Revocation for DWN h..." with 👍
01:07:34 quinn: ucan-wg/conformance-tests#13

Notes

Follow-Ups

[expede]

@Gozala: revocation

• Include revoked UCAN itself in request?
• Make revocation an invocation?
  • @matheus23: different delegation semantics though
• Deep vs shallow revocation
  • Include full reified chain on deep revocation
• Can I revoke things deleated to me?