We aim to use it for resource access and inbox action authorization. Our current use cases:
Send people who don’t have accounts yet invite links that can be used to view the inviter’s profile (capability-based resource access) and auto-connect the new user without manual approval by the inviter (a capability to invoke an inbox action on the inviters inbox). As of January 2024, this is implemented with a custom capabilities solution which we aim to migrate to zcaps.
Allow friends to share/recommend contacts (with their friends). Here, Alice issues capabilities to view her profile and send her Notes to a trusted friend, Bob. Bob creates a delegated capabilities to Craig. Craig can now view Alice’s profile and send her a message. This is the next thing, we are implementing.
We would be very happy to hear from you about
feedback
ideas and other use cases in the realm of consent and capabilities
experience with capabilities (and implementations) (I just found out about @bengo’s AP+zcap server but haven’t got quite through yet)
This is incredible news! I have been impressed with Christine’s work and with OCapN. This is excellent news as we are building our new platform on ActivityPods framework
Hi @laurin . Glad to hear you’re interested in this. I am too!
I just found out about @bengo’s AP+zcap server but haven’t got quite through yet)
That was definitely a bit of a handwavey sketch by me and not something I expected others to use.
But aside from that, I’ve definitely been exploring zcaps more and always with an eye for they could be applied in the ActivityPub world. Ideally we’d have some zcap scheme that isn’t too activitypub-specific, and e.g. could be combined with other similar http based protocols as well.
ZCAP-LD is pretty great for combining with ActivityPub. There are a lot of TODOs and I’m not sure how active the editors are committed to being (they’re busy with other important things).
UCANs express authorizations that are verifiable because they are issued by a did: URI that has a cryptographic verification method i.e. a did:key.
I don’t think it’s realistic that everyone will use only one of these authorization certificate schemes. They’re all useful in different contexts and adoption will shift over time. But it would be really ideal if everyone can at least reuse did-core and common did methods like did:key and did:web
I’ve also shared some related links in this discussion
This is also a good overview from ActivityPub Conf 2019
Excellent, yesss! I’m glad you’re working on it! I’ve always wanted to apply zCaps to AP! (And Solid, also, fwiw).
I think we (and other interested ppl on this thread) should get together and synthesize the best of zCap-LD and UCANs.
I don’t fully agree with some of the zCap-LD resource restrictions (and I say that as an implementer and contributor to the zCap-LD spec).
Similarly, I don’t like where the latest version of UCAN is going (breaking changes from the previous one).
So naturally, the world clearly needs /yet another spec/, amirite
I like how ZCAP-LD makes use of data integrity proofs. The spec definitely needs an update though, and I would like to see it becoming more JSON friendly.
I’m not familiar with UCAN yet but maybe it might help to create a wiki page or a collaborative pad for people to gather ideas and set up a call then? Happy for alternative proposals!
Adding a https://w3id.org/security#capability field to the activity?
You don’t attach it but send it to a custom inbox URI dedicated to one particular capability, as proposed in the OcapPub writeup by @cwebber
Something else?
What does the capability’s caveat / allowed action which restricts / permits certain kinds of activities on an inbox look like? E.g. something like json schema.
