UCANs are JWTs that contain special keys.
At a high level, UCANs (“User Controlled Authorization Network”) are an authorization scheme ("what you can do") where users are fully in control. UCANs use DIDs ("Decentralized Identifiers") to identify users and services ("who you are").
No all-powerful authorization server or server of any kind is required for UCANs. Instead, everything a user can do is captured directly in a key or token, which can be sent to anyone who knows how to interpret the UCAN format. Because UCANs are self-contained, they are easy to consume permissionlessly, and they work well offline and in distributed systems.
UCANs work
- Server → Server
- Client → Server
- Peer-to-peer
OAuth is designed for a centralized world, UCAN is the distributed user-controlled version.
Read more in the whitepaper: https://whitepaper.fission.codes/access-control/ucan
alg, Algorithm, the type of signature.
typ, Type, the type of this data structure, JWT.
uav, UCAN version.
att, Attenuation, a list of resources and capabilities that the ucan grants.
aud, Audience, the DID of who it's intended for.
exp, Expiry, unix timestamp of when the jwt is no longer valid.
fct, Facts, an array of extra facts or information to attach to the jwt.
iss, Issuer, the DID of who sent this.
nbf, Not Before, unix timestamp of when the jwt becomes valid.
prf, Proof, an optional nested token with equal or greater privileges.
A signature (using alg) of the base64 encoded header and payload concatenated together and delimited by .
ucan.build can be used to help in formatting and signing a UCAN. It takes the following parameters:
type BuildParams = {
// from/to
issuer: Keypair
audience: string
// capabilities
capabilities?: Array<Capability>
// time bounds
lifetimeInSeconds?: number // expiration overrides lifetimeInSeconds
expiration?: number
notBefore?: number
// proofs / other info
facts?: Array<Fact>
proofs?: Array<string>
addNonce?: boolean
}capabilities is an array of resource pointers and abilities:
{
// `with` is a resource pointer in the form of a URI, which has a `scheme` and `hierPart`.
// → "mailto:[email protected]"
with: { scheme: "mailto", hierPart: "[email protected]" },
// `can` is an ability, which always has a namespace and optional segments.
// → "msg/SEND"
can: { namespace: "msg", segments: [ "SEND" ] }
}npm install --save @mkabanau/ucans
yarn add @mkabanau/ucans
import * as ucans from "@mkabanau/ucans"
// in-memory keypair
const keypair = await ucans.EdKeypair.create()
const ucan = await ucans.build({
audience: "did:key:zabcde...", // recipient DID
issuer: keypair, // signing key
capabilities: [ // permissions for ucan
{
with: { scheme: "wnfs", hierPart: "//boris.fission.name/public/photos/" },
can: { namespace: "wnfs", segments: [ "OVERWRITE" ] }
},
{
with: { scheme: "wnfs", hierPart: "//boris.fission.name/private/6m-mLXYuXi5m6vxgRTfJ7k_xzbmpk7LeD3qYt0TM1M0" },
can: { namespace: "wnfs", segments: [ "APPEND" ] }
},
{
with: { scheme: "mailto", hierPart: "[email protected]" },
can: { namespace: "msg", segments: [ "SEND" ] }
}
]
})
const token = ucans.encode(ucan) // base64 jwt-formatted auth token
// You can also use your own signing function if you're bringing your own key management solution
const payload = await ucans.buildPayload(...)
const ucan = await ucans.sign(payload, keyType, signingFn)Using a UCAN to authorize an action is called "invocation".
To verify invocations, you need to use the verify function.
import * as ucans from "@mkabanau/ucans"
const serviceDID = "did:key:zabcde..."
// Generate a UCAN on one machine
const ucan = ucans.build({ ... })
// encode the UCAN to send it over to another machine
const encoded = ucans.encode(ucan)
// verify an invocation of a UCAN on another machine (in this example a service)
const result = await ucans.verify(encoded, {
// to make sure we're the intended recipient of this UCAN
audience: serviceDID,
// A callback for figuring out whether a UCAN is known to be revoked
isRevoked: async ucan => false // as a stub. Should look up the UCAN CID in a DB.
// capabilities required for this invocation & which owner we expect for each capability
requiredCapabilities: [
{
capability: {
with: { scheme: "mailto", hierPart: "[email protected]" },
can: { namespace: "msg", segments: [ "SEND" ] }
},
rootIssuer: borisDID, // check against a known owner of the [email protected] email address
}
],
)
if (result.ok) {
// The UCAN authorized the user
} else {
// Unauthorized
}UCAN capabilities can have arbitrary semantics for delegation. These semantics can be configured via a record of two functions:
canDelegateResource(parent: ResourcePointer, child: ResourcePointer): booleanandcanDelegateAbility(parent: Ability, child: Ability): boolean. Which specify exactly which delegations are valid.
(This doesn't support rights amplification yet, where multiple capabilities in combination may result in a delegation being possible. Please talk to us with your use-case and ideas for how a good API for that may work.)
import * as ucans from "@mkabanau/ucans"
// Delegation semantics for path-like capabilities (e.g. "path:/home/abc/")
const PATH_SEMANTICS = {
canDelegateResource: (parentRes, childRes) => {
if (parentRes.with.scheme !== "path" || childRes.with.scheme !== "path") {
// If this is not about the "path" capability, then
// just use the normal equality delegation
return ucans.equalCanDelegate.canDelegateResource(parentRes, childRes)
}
// we've got access to everything
if (parentRes.hierPart === ucans.capability.superUser.SUPERUSER) {
return true
}
// path must be the same or a path below
if (`${childRes.hierPart}/`.startsWith(`${parentRes.hierPart}/`)) {
return true
}
// 🚨 cannot delegate
return false
},
// we're reusing equalCanDelegate's semantics for ability delegation
canDelegateAbility: equalCanDelegate.canDelegateAbility
}Sponsors that contribute developer time or resources to this implementation of UCANs: