1/ register a cron job / callback lambda using a UCAN, that can make other calls using UCANs to eg a webhook
2/ create a web hook in API Gateway that accepts a UCAN as part of the payload that can then do other actions with derived UCANs
Bonus points if these things can trigger a request to get a new UCAN before the old UCAN expires. These building blocks could be combined to do a lot of things and the UCAN layer can be our relationship with customers / app users as an abstraction on top of IAM and AWS complexity.
Bonus round:
3/ create DNS mappings for everything happening in AWS using our own DNS infra
4/ send emails and other notifications
5/ a websocket connection that speaks AWAKE and other protocols, backed by lambdas, that accepts UCANs
I am building a cloud service that would be best served by UCAN. What you are talking about sounds like the basic UCAN starter kit as I’ve been imagining it. I might specialize it to fit the 80% use case, and then document how to modify that for the other 20%. The 80% use case is gonna be aligned with web2 developer expectations. Eg a new visitor browses the site / tries the app, then authenticates, and now can access protected resource and create content.
As an app dev, the experience I get from taking the path of least resistance looks something like this: https://next-auth.js.org eg for the cognitive overhead of setting up a github app id, and pasting some tokens to my .env file, I have login working, with options for server side or JWT sessions.
I think inherently UCAN is more powerful, but it doesn’t matter if it’s harder to do the 80% use case. Bridging this gap probably looks like a combination of:
an AWS CloudFormation (preferrably SST) stack that implements a hello world resource protection. Eg any user can generate a UCAN principle locally, verifying with an email link click or SSO (github etc login.) Once the UCAN is linked to the identity in a way the service trusts, it should grant access to the protected resource. Ideally in a way devs can learn from and adapt to useful purposes, with sane defaults: eg a verified UCAN holder can write to an s3 bucket with a path like <bucket/verfiedUcanDID/write here> or something. As long as the logging is ready for it, “billing” can be punted for later.
the second part is a cloud service that makes it so I don’t have to do all that.
Agreed this is the accept the universe as-is approach - while I want that nascar experience of choosing an Oauth provider to be replaced with a passkey experience passkeys are going to take a few years to eat into the space, and people will need to integrate their stuff now.