changed 3 years ago  
Published Linked with GitHub

Connecting IPFS users and permissions to DIDs with UCAN

IPFS þing - July 13, 2022

Note:
How many of you know UCAN and DIDs?

How can we bridge dids and ipfs data (CIDs) with UCANs

Hugo Dias

@hugomrdias

  • Software Engineer at Protocol Labs
  • Team DAG House
  • Working on nft.storage and web3.storage
  • Previously js-ipfs, js-libp2p, js-multiformats

dag house

DID

Identity

  1. Authentication/proof of control
  2. Decentralized/self issued
  3. Guaranteed unique identifier
  4. No call home
  5. Associated cryptographic material

Note:
Who you are

DID 1.0 just got the 👍🏼 to advance to W3C Recommendation after years of effort from many contributing organizations.

The Director concludes that the balance lies in favor of the DID developer community, encouraging it to continue its work and search for consensus on standard DID methods.
The objections are overruled.
– Tim Berners-Lee

https://www.w3.org/2022/06/DIDRecommendationDecision.html

Note:
Sir Tim Berners-Lee AKA The Director (Ralph Swick)

The did:key Method

A DID Method for Static Cryptographic Keys

did:key:MULTIBASE(base58-btc, MULTICODEC(public-key-type, raw-public-key-bytes))

https://w3c-ccg.github.io/did-method-key/

Note:
most of security and privacy considerations can be addressed but UCANs

UCAN

User Controlled Authorization Networks

Transfer authority without transferring keys

https://github.com/ucan-wg
https://ucan.xyz/

Note:
What you can do

UCAN
Trustless Verifiable
Secure Delegable
Local-First Expressive
Attenuation Extensible
Revocation Capabilities

Note:
Achieve Inversion of Control back to the user.

UCANs are all that we need to sign into multiple machines, delegate access for service providers to do things while we’re offline, securely collaborate on documents with a team, and more. We get the flexibility of fine- or coarse-grained control, all controlled by the one who cares about the data the most: the user.

UCANs achieve public verifiability with chained certificates and decentralized identifiers (DIDs). Verifiable chain compression is enabled via content addressing.

Permission delegation is something traditional centralized services can’t easily offer.
But UCAN !

DID + UCAN
💞

Note:
who you are
what you can do

sequenceDiagram

  Note over Service,Marketplace: Service needs to know Marketplace
  Marketplace->>Service: Request UCAN for did:market
  Service->>Service: Signs UCAN for did:market
  Service->>Marketplace: UCAN upload/*
  loop Every time UCAN expires
    Alice->>Marketplace: Request UCAN for did:alice
    Marketplace->>Marketplace: Signs UCAN for did:alice
    Marketplace->>Alice: Short lived UCAN upload/IMPORT
  end
  Alice->>Alice: Signs UCAN for did:service
  Alice->>Service: UCAN+Car

Note:
ucan.storage prototype, kinda centralized all capabilities are issued by the service.

signature chain
direct upload from Alice to Service

dag-ucan

An implementation of UCANs in IPLD via Advanced Data Layout (ADL), designed for use with multiformats.
– Irakli Gozalishvili @gozala

https://github.com/ipld/js-dag-ucan

IPLD schema encoded as DAG-CBOR

type UCAN struct {
  version String

  issuer SigningKey
  audience SigningKey
  signature Signature

  capabilities [Capability]
  proofs [&UCAN]
  expiration Int

  facts [Fact]
  nonce optional String
  notBefore optional Int
} representation map {
  field facts default []
  field proofs default []
}

Note:
With schema we can encode to JWT and others.
Also supports raw JWT to DAG-UCAN with some whitespaces and key order magic.
Export full UCAN chain into a CAR file.

ucanto - framework for UCAN based RPC
(you can too)

oh yeah we can 💪🏼

  1. A declarative system for defining capabilities.
  2. Capability invocations routing and execution.
  3. UCAN validation system.
  4. A pluggable transport layer.
  5. Client supporting batched invocations and full type inference.

Note:
2. Capability routing and execution - A system for binding capability handles (a.k.a providers) to form services with built-in routing.
4. it can work over pubsub, libp2p etc with pluggable codecs for request/response.

DIDs + DAG-UCAN + UCANTO
=
Identity + Permissions + Operations
Packaged as CAR files

Note:
Services/Actors then are just interpreters of these operations.

Because all of the information is captured in the IPLD structure in the CAR, HTTP is just dumb pipe and any other transport could be used in it’s place.

We are already using this to build up protocols to upload data to Elastic IPFS.

w3name with UCAN

Delegated "IPNS" mutation

Note:

  • because we can package multiple operations in one CAR file, one of the cool things we can do is upload data and mutate an "IPNS" record at the same time.
  • Transfer of large DAGs in shards (of desired size) across multiple network request and/or sessions.
  • Uncoordinated multiplayer DAG creation/transfer
  • Revocation

How can we make it really IPNS !?!?

What if IPFS could talk UCAN 🫶🏼


  • Delegated IPNS mutation
  • Delegate IPFS operations to remote nodes
  • Writable Gateways
  • Gateway routed operations
  • bitswap ?

What else ?

Note:
we find UCANs really useful but they would be even more cool if ipfs could understand them.

Future Work

  • Key Management
  • More tooling
  • UCAN transport specs

Thank you! 🙏🏼

Note:
UCAN Join
Building Apps on IPFS track, 01:00pm Subconscious & Noosphere: WWW over IPFS

Select a repo