Expose Caps in Human Readable Format

[dholms]

As a coworker said: "the great thing about UCANs is you can do anything with them. the bad thing about UCANs is you can do anything with them"

Each organization that implements UCANs specifies a way to identify resources (for example an ADX object may be described adx://did:example:userDid|did:example:microblog|did:example:like|3iwc-gvs-ehpk-2s). As more and more folks are doing so, it would be nice for each org to be able to understand/translate UCANs from across the ecosystem.

I know we discussed this at one point, but have we given any thought to a "Resource Dictionary"? By that, I mean a utility for translating UCAN resource names into human friendly descriptions of the resources.

This would have to be publicly contributable & could possible take the form of something like the DefinitelyTyped repo

[expede]

As a coworker said: "the great thing about UCANs is you can do anything with them. the bad thing about UCANs is you can do anything with them"

Exactly! It's intentional! In the same way that JSON or HTML can express anything, a design goal is extensibility, including letting others define specs on top of UCAN that define specific capabilities.

@dholms the current plan is to ship a standard library of things that will be pretty widely applicable, including social primitives etc. Of course we'll never limit capabilities to what's in a repo, or force every implementation to support all capabilities. Even listing a bunch of schema in a repo still leaves it up to each application to implement things beyond the standard lib. We want ts-ucan & wasm-ucan to have good support for defining and importing capabilities.

The spec is designed to be open for further extension. You can start such a spec of capabilities without waiting for this repo, or build a library or capabilities on top of e.g. ts-ucan directly :)

Does that answer your question, @dholms?

[dholms]

Exactly! It's intentional!

Totally! just thought it was a funny phrasing of it. & points to the complexity of social consensus on things out side of the spec.

stdlib for general caps & resources would be great!

Although, this is less about standardized capabilities, and more about just human-readable translations of capabilities from outside your org. Think Fission Auth saying "This app would like to post likes on ADX on your behalf" instead of "This app is asking for permission adx://did:example:userDid|did:example:microblog|did:example:like

In some cases, you'd like to maintain multiple root identities, but in other cases, I'd imagine some folks would want to post to multiple protocols from one identity.

This isn't a short term need for us. Was just thinking about it & wanted to bring up to see if other folks were :)

[expede]

@dholms and I are having an interesting side conversation from the POV of wallet implementers.

---

dholms — Today at 15:13
this is less validation helpers and more "can fission auth give you a nice message that says 'this application wants to make likes on ADX on your behalf'?"
which validation is a step towards
as opposed to "this application wants to write adx://did:longComplicatedResourceId

expede — Today at 15:15
Oh totally human readable, I see
Yeah, I mean for trusted applications, that would be nice for sure 💯
There's a challenge where a malicious app could be like "hey sign this thing" but it's actually completely different
Which is how SIWE ended up with their design

dholms — Today at 15:16
yea totally

expede — Today at 15:16
Granted, I'm saying this as the author of EIP-1444
😛
EIP-1444: Localized Messaging with Signal-to-Text
"Translate status codes into human readable text, including i18n"
This is the other thing in such a project: i18n
All of this gets hard with the nb fields 🤔

dholms — Today at 15:19
my main motivation here is that if a bunch of apps/orgs have decentralized capabilities deriving from a root key pair, hopefully a user doesn't need Fission Auth AND Bluesky Auth AND Block Auth AND.....

expede — Today at 15:19
But yeah, this is still fully in the "nothing is stopping you" bucket 😜
Tell me more about this!

dholms — Today at 15:20
basically, ideally you could link your fission, adx, block, etc data all to one root account
whether that's bluesky id wallet
or fission auth
or whatever block is coming up with

expede — Today at 15:21
(With UCAN, you can merge them after the fact, too)

dholms — Today at 15:21
that is the core of their identity & lots of protocols branch off of

expede — Today at 15:22
I'm less certain that this will happen. If you look at what Apple is doing, for example, they're giving each app a different email address
But maybe if a wallet is sufficiently convenient 🤔

dholms — Today at 15:23
oh interesting

expede — Today at 15:23
In any case, UCAN doesn't really care about which ID, and can aggregate or disperse capabilities as needed
The ID stuff is at a different layer
I completely agree that ID management is wild today
Literally what happened to me with Vimeo when we were talking earlier

dholms — Today at 15:24
oh totally, to clarify: I don't think this should be in the spec
just like DefinitelyTyped isn't in the typescript spec
thinking of it has a social consensus tool
for folks that are implmenting UCANs to be able to interoperate with one another

expede — Today at 15:29
Yeah totally. I doubt that they'll pull in everything, in the same way that very few folks use all of DefinitelyTyped. You're always going to have to contend with URIs/actions/NBs that you haven't seen before, but you're right that there will be a power law on some will get a ton of use and not so much others
I definitely see how this is a challenge for wallet implementers
Have you had a chance to look at SIWE, btw?

dholms — Today at 15:30
yup 👍
much needed
& im very glad it's getting integrated into ucans

[expede]

hopefully a user doesn't need Fission Auth AND Bluesky Auth AND Block Auth AND.....

@dholms tell me more about this. Do you mean so that each wallet can surface the caps in human readable form to the user? Or literally the aggregation use case?

[expede]

just thought it was a funny phrasing of it. & points to the complexity of social consensus on things out side of the spec.

💯

[bmann]

This is of course a very much topic of discussion in Ethereum smart contract land. And Brooke wrote specs around human readable error messages / capabilities, including how to i18n them.

I think this is a great goal to aim for. Much like Brooke's previous work, and some other things I'm aware of, we could run a voluntary registry, and have both service supplied and user supplied translations.

This is similar to various token allow / deny lists, and the work I've done previously in community registration of chain IDs. We could start with... a github repo and PRs! @dholms happy to riff more on this.

[expede]

UPDATE: @dholms means translations to human readable text in the UI! I love this kind of thing, and fully support the idea. It's an actual hard problem, since you quickly get into i18n etc, and there's lots of room here for malicious apps... but worth attempting to tackle!

Nothing in the core spec blocks such an effort, but would at least I support such an effort to make all of this stuff more accessible to end users 👍

[expede]

<Updated the Discussion title to reflect this>

[alanhkarp]

In our paper Making Policy Decisions Disappear into the User's Workflow, (I believe ACM is now open access, but you may need to create an account.) we came up with 4 principles for UIs for usable security. One of them was that every policy decision, e.g., delegation made by the user, must appear as a unique affordance in the UI. It would seem that the kind of translation being proposed would help achieve this goal.