How do you coordinate among many business units in one company, or with many independent businesses across the web? Fission's UCAN approach makes for lightweight, verifiable credentials that can help businesses coordinate without tight integration or coordination ahead of time.
"At a Doughnut Shop Near You!"
Let's say that you've recently realized your lifelong dream to open an independent doughnut shop. To welcome you to the neighbourhood, the coffee shop next door wants to run a promotion to drive awareness of both businesses (what's better than coffee and a doughnut, right?) If someone buys a cruller from you, the coffee shop will give the them a brew coffee at half price.
To keep things simple, customers only need to show a receipt from your shop issued in the last 24 hours at the coffee shop. To prevent them from being claimed multiple times, the cafe will track the receipt ID in their system. Non-coffee drinking customers can hand off their doughnut receipts to their friends, who gratefully take the 50% off, and drives even more business to the area. Foot traffic is up, and profits soar.
Time goes on, and this arrangement is working so well that the other shops in the area want to also offer collaborative deals. They want to do all kinds of things: some keep the single-use deal offer, but others want to offer permanent discounts to members of their co-op, over different time periods, or recurring offers (e.g. "every Friday").
You could absolutely create a coordinated system with a central database for the entire neighbourhood, but that shows everyone how many sales are being done at the other stores, and requires ongoing maintenance. You want to offer specials and deals without coordinating with the entire business association! You keep the system that's been working: record the receipt IDs, and leave it up to each retailer how they want to run their offers.
The Online Equivalent
The above story not only sounds reasonable, but is done in real life with physical receipts. It's ground-up, requires little coordination, has no service outages, and anyone can participate. No one has to ask the doughnut shop if they are allowed to use their receipts, and no one is maintaining a complex system of rules for these offers.
Historically, doing this online has been less straightforward. Because permissions are done per company, offering a discount code requires coordination between at least two teams: the doughnut shop in the above story suddenly needs to either:
- Know all of the discount codes for all of the participating shops, or
- Register the user ID as being eligible for deals, and wire up the two company's back-ends
These both work, but they depend on a high level of coordination, and rules to be maintained across systems. They're permissioned, and top-down. There must be a simpler way, closer to the bottom-up version from our doughnut shop story, right?
Enter the UCAN
At Fission, we've developed a version of distributed auth called UCAN:
User Controlled Authorization Networks (UCANs) are a way of doing authorization where users are fully in control. OAuth is designed for a centralized world, UCAN is the distributed user controlled version.
– Fission blog: UCAN: Authorizing Users without a Backend
As well as being like a distributed variant of OAuth, UCANs are also stateless by default ("REST for auth"), so it continues to work client-side, P2P, and even offline.
UCANs are used anywhere that we need to authorize a user to perform side-effects: time-based expiry, rights delegation, authorized access, writing to a database, and so on. Fission is a platform that helps people create apps, so we made it extensible: it can support arbitrary use cases as long as they're well understood by the issuer and verifier.
It turns out that UCANs are able to fully support verifiable credential use cases, in a different format, with the added flexibility of delegation. This makes them work much like the receipts in the doughnut shop story, thanks to the following properties:
- Permissionless — anyone can accept UCANs issued without bothering you
- Bearer Credential — you only need the UCAN itself (like a receipt)
- Delegable — can be passed around to friends, and prove that they're allowed
- Non-fungible — uniquely identifiable, even when delegated
Use Case: Decentralized Coordination
We have been exploring use cases with a few teams, including a Fortune 500 publishing company. They have many properties under their umbrella, and collaborate with many third parties to offer perks to their subscribers. Like many companies offering running at scale today, they solved for team agility with microservices — each team can move their publications forward independently. Users have a single account across publications, and so all logins and billing get funnelled through the auth service.
Internal Decentralized Coordination
If you have ever read a physical magazine, you'll be familiar with their leaflets enticing you to sign up for their other publications and partners. You typically mail the leaflet that's already prefilled with your account number back to the publisher. How would we replicate these offers digitally?
The centralized auth server works well, but that auth server is a both a technical and team bottleneck: if Publication A wants to give a trial offer for Publication B, they need to encode this logic directly in the auth server. The auth and billing teams are suddenly responsible for maintaining the complex rules across all teams' marketing deals. Teams A and B now have a hard dependency on the roadmap of the auth team, which is also responsible for servicing all of the other teams.
By placing all the information needed to describe and validate an offer right in the token, teams can ship independently.
Easy Third-Party Integration
The same applies to teams outside the company: anyone with a valid credential can be used as authorized proof that you have an account, despite having totally separate auth systems. It can be as simple as signing up with the same email that's in the credential, or having a challenge code signed into the UCAN chain.
What this can't tell you statelessly is that the holder is currently a subscriber, only that they were when the credential was made. For this reason, these credentials generally have an expiration date. They can absolutely be made stateful by requiring a lookup — it's always easier to go that direction than from stateful to stateless — but in our experience it's not required for the 95% use case.
What this enables is that business and marketing teams can make discounts, offers, and other specialized deals anywhere, with any company, with low effort and without developer coordination overhead, while still having verifiable credentials, and without sharing more than a single fact about users.
Contemporaries
It turns out that it's not just us! This pattern is being picked up elsewhere, too.
Google Macaroons
Until fairly recently, Google had a similar centralized auth setup as the publishing company. Being at Google scale means that their auth servers were dealing with an enormous volume for logins and auth across Gmail, YouTube, Google Play, Google Docs, Stadia, and so on. To make this scale better, they developed the Macaroons system to delegate auth responsibilities to the individual services, which still remaining interoperable with a single account.
In many ways, UCANs are like Macaroons taken to their logical conclusion: they fully decentralize auth, are stateless by default, and work well permissionlessly across teams.
Passport
Ben Thompson of the excellent Stratechery has recently released Passport, which is also aimed at a subset of the problem space. From the linked article:
The second reason to build Passport is to provide a better experience for my subscribers. One of the downsides of relying on a menagerie of different services is that there were both more rough edges exposed to users, and also an inability to provide more personalized offerings. Passport is an improvement on both fronts.
We had a number of people send us this article, saying that it reminded them of how Fission worked. Definitely, these are the types of use cases that we think can be created and enabled across the web as an open, interoperable standard. And some of it crosses into the work we're doing as part of the Decentralized Identity Foundation, too.
It feels like this idea's time has come!
Your Turn
Interested in implementing UCANs to coordinate offers? Have a use case we haven't thought of? Want to poke holes in the whole concept? We'd love to hear from you!
Book a time in our calendar, or drop by our Discord chat with any further questions.
You can find all the collected UCAN resources in our developer forum »