Feb 2023 Communty Call

[expede]

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

NOTE: moved to the first week of March due to a public holiday during the regularly scheduled time. See the Luma link above for exact details :)

Suggested Agenda

• 0.10 started up again
  • Needs from community?
• Invocation 0.1 merged 🎉
• Alan: can/*

Video

Chat Log

Notes

• Version 0.10
  • Brooke has started writing this
  • Some details to be determined
  • Please make requests on the PR if there are things you want in this version
  • Question from bengo
    • "Would it lower the pressure on ‘0.10’ to make that PR like ‘0.10-pre.0’ and that way the tagging decision is decoupled from the PR decision"
    • We might do this or make it a feature branch?
    • It is sort of a feature branch, with live discussion on the PR
  • What is in 0.10
    • v0.10 #132
    • Invocation spec: https://github.com/ucan-wg/invocation/
    • Ways to connect delegation chains
      • Adding a proof to avoid recreating chain
      • Powerbox, reference in an another chain
    • Syntax for an unattentuated delegation
    • Facts field map instead of array
    • Expand on revocation
    • Move reserved resource & ability to their own spec(s)
  • Powerbox and can/* discussion
    • Connect fragments of chains, validator knows where to find each piece
    • Less complexity recreating chains
      • DAGHouse implementing this
    • Potential issues
      • Could be dangerous
        • Delegated everything
        • Add something in the future that should not be delegates
      • Follows OOP principles
        • Any new methods on an object can be invoked
        • But objects are ephemeral, services less so
      • We could disallow can/* at the root, but allow it at other levels
        • That way new things aren't implicitly granted
    • DAGHouse explicitly wants this
      • Gets out of key management and recovery
      • Users can gate what actually is actually delegated
      • But programmers are lazy and will use * instead of being explicit
    • Example from Brooke
      • Work with local agents
      • Offline agents, can check with them
      • Want to pass permissions from phone to laptop
      • Lost laptop, only have phone
      • The * allows for automatic redelegation to the phone, laptop will never be available to redelegate
    • Alan Karp
      • Important use case, but there are risks
      • Note that * is only an issue for new methods, not new resources
    • Can we make it harder to use *? Can we make it clear there are risks?
      • UX question, how we help developers avoid dangerous actions`
    • can/* will only be allowed from the agent with the capabilities in DAGHouse use case
      • DAGHouse provides set of capabilities
      • User self-delegates from one device to another
      • DAGHouse wants to add new features in the future. How to do it?
    • We may not have a specific suggestion for 0.10 in next month
      • Maybe remove chains from proofs?
      • Might not be needed, put more onus of work on validators
      • Can intention be unambiguously decided when combining chains? There might be conflicts?
        • Instead of giving entire certificate graph, give links to parts of the graph
          • Validators works through links to determine capability
          • One option is know everything explicitly, another is powerbox
        • Bag of proofs
          • Could have interoperability issues where one proof says valid and another says not
        • Interop issues can be solved by implementers working with each other
      • Concrete example
        • Delegation A to B
        • Later discover that C delegates to A
        • B want to be able to do what C delegated
        • Want to do this without redelegation
        • You wouldn't know at a single UCAN what is going on, but with the whole chain you can tell
        • Non-linear, instead of a liner chains
  • Nested syntax
    • Instead of an array of objects
    • A bit more compact
    • Has been added to PR
• Test cases
  • Where are the DAGHouse test cases?
    • Noosphere would like to interop
    • https://github.com/ipld/js-dag-ucan/tree/main/test
    • Would love help with getting this tests into better shape
  • dag-ipld
    • Agnostic, could test serialization and deserialization
  • DagHouse has a closed loop for some pieces
    • Maybe not something others would want interop with
    • Blaine and Brooke have some ideas on flipping this flow, more discussion later offline
• Census service
  • Folks could send it UCANs to get a sense for what capabilities are people using
  • DAGHouse will likely write a validator service
  • Could add some known capabilities to the UCAN check web app
    • Some of this information is application specific, don't want to handle all possible things
  • Comparing capabilities by scheme, do they overlap, expand capability, attenuate?
• UCAN store
  • Holds UCANs, which can be requested by audience
  • Sounds like UMA, user managed access
• Invocation/IPVM
  • Lots of use cases for WebAssembly
  • Here is a module, take this and run it, bounded by gas
  • Could be done with passing around validators
• URIs instead of requiring DIDs
  • Groups
    • Should only be key pairs
    • Should be any URI
    • Group in the middle is happy with DID
  • One option
    • You must support did:key
    • Extend beyond that as you like
  • But some use cases cannot resolve a key
    • Thus the desire for URIs
  • Open to adding this to the draft
  • Consideration
    • Someone else can claim a URI, no way to validate
    • DIDs indicate you need to check and how
    • Support for other methods need to state how to delegate
    • Namespacing needs to be clear, what are we working with

Follow Ups

• ucan-ipld test cases
• 0.10 principals as URIs
• DID docs expede/bengo/blaine/gozala