How to build apps using ucans and w3c-ccg Verifiable Credentials

[gobengo]

From the ucan spec:

Verifiable credentials are a solution for data about people or organizations. However, they are aimed at a slightly different problem: asserting attributes about the holder of a DID, including things like work history, age, and membership.

I find myself wanting more evidence to understand the claim that they are aimed at slightly different problems.
First, I don't see where the UCAN spec explains which problems it is trying to solve. This presents a challenge in evaluating whether any alternatives solve different problems, especially slightly different problems.

asserting attributes about the holder of a DID, including things like work history, age, and membership.

This seems like an argument like "We have problem A, but that thing is solving A and B, so it's solving a different problem", which doesn't add up to me.

I'm sure there are some good arguments for not using VCs. Personally I think the spec will be better if it includes a further elaboration of the above argument or, alternatively, zero arguments for a bit.

(this is not meant as a paragon/proposal, just an example). Here is a sketch from @OR13 of expressing zbac using VCs: https://transmute-industries.github.io/authorization-credentials/#abstract

Notably, and like UCANs later, VCs have a JWT encoding.

My goal is to be able to coherently explain how a developer should build something that makes use of UCAN-using service providers in combination with VC-using service providers.

For example, @TBD54566975/ssi-sdk (and #web5) will support VCs and higher-order protocols like DIF presentation-exchange.
https://github.com/TBD54566975/ssi-sdk/blob/main/example/presentation/presentation.go

Another example of a VC-based protocol that may be useful to the same web app that uses a UCAN-based protocol is the vp-request-spec authorization capability request, which e.g. could perhaps respond with a VC that has an embedded UCAN (or vice versa).

Elaborating on the feature matrix / design space of VCs vs UCANs may lead to win/win ways of interoperating across these ecosystems (i.e. ucan, ccg-vc, ssi-sdk, DWN), which I believe will be good for the developers using this protocol and, more importantly, the end-users of these protocols.

[bmann]

Thanks @gobengo for starting this thread!

[bumblefudge]

From the current Prior Art section of the spec:

ZCAP-LD is closely related to UCAN. The primary differences are in formatting, addressing by URL instead of CID, the mechanism of separating invocation from authorization, and single versus multiple proofs.

(Would it also make sense to mentioned RDFC here? That's also a difference some would call primary)

CACAO is a translation of many of these ideas to a cross-blockchain invocation model. It contains the same basic concepts but is aimed at small messages and identities that are rooted in mutable documents rooted on a blockchain and lacks the ability to subdelegate capabilities.

Not sure this is quite accurate, either-- CACAO works with implicit addresses (i.e. valid addresses with no onchain history) and contract addresses, i'm unclear on the im/mutability claim, and the underspecified Resources array can be used to record/notarize subdelegations, in theory (maybe that still counts as lacking a specified ability, but it may be happening in the wild?).

...Verifiable credentials are a solution for data about people or organizations. However, they are aimed at a slightly different problem: asserting attributes about the holder of a DID, including things like work history, age, and membership.

I think VCs assert attributes about the subject of a VC, which may or may not be the subject (not holder!) of a DID or addressed otherwise. It might be more accurate to say VC tooling is optimised for claims, and using it for authZ has diff tradeoffs, while ucans are optimized for, e.g., more efficient chaining, etc

[gobengo]

(Would it also make sense to mentioned RDFC here? That's also a difference some would call primary)

RDFC is not mentioned in there and I believe you could use any sig scheme alongside that zcap-spec vocab. (afaict, there are a lot of 'todo' in the spec text, so it might be in the 👁️ of the beholder)

It might be more like "In UCAN, we wanted there to be a well-defined way of verifying them (i.e. signing over the JWT serialization)" but ZCAP-LD left this open ended and is an unfinished draft.

i'm unclear on the im/mutability claim,

Early on, and maybe still in practice or even in spec text, UCANs operate more on the 'verification method' level than on the 'generic mutable identifier' level. e.g. a specific public key. That way they don't rely on some temporal view of the referent of the identifier to be able to be verifiable. (I'm talking about in UCAN 0 iss and aud esp)

[gobengo]

I think VCs assert attributes about the subject of a VC

💯 big distinction. The subject of a VC can be a holder subject of a did, and you do that with { credentialSubject: { id: "did:...", memberOf: ["dag.house"] } }

while ucans are optimized for, e.g., more efficient chaining, etc

UCANs have changed a lot over the last two years, and between v0 and v1. They have probably been optimized for differing things along the way.

[bumblefudge]

Early on, and maybe still in practice or even in spec text, UCANs operate more on the 'verification method' level than on the 'generic mutable identifier' level. e.g. a specific public key.

absolutely-- capabilityDelegation is a first class verification method exactly because early DID WG thinking assumed authZ should be distinct from authN and claims/VCs, but the ZCap spec was never really finished because not enough people could agree on a shared approach for that extension mechanism at the time. UCANs could slot neatly into that niche, and work better for delegating capabilities than VCs do, for reasons im sure could be documented by summarizing some old mailinglist flame wars and github threads where the ZCap people argued against the "just use VCs for authZ" idea. Might be a fun mini research project?

UCANs have changed a lot over the last two years, and between v0 and v1. They have probably been optimized for differing things along the way.

i'll take that as a +1 to revisiting the prior art section and writing it in terms of comparative efficiencies and optimizations after v1 implementer feedback has been factored in?