Explore compatibility with CACAO

[oed]

Thanks for your comment here @Gozala

We are currently exploring if it might make sense to have a common dag-cbor representation for both SIWE and UCAN. Currently it's possible to encode a SIWE message and signature as CACAO. From my surface level understanding of your ADL approach it seems like that is pretty similar to what CACAO is doing for SIWE.

Would love your thoughts on this!

[Gozala]

We are currently exploring if it might make sense to have a common dag-cbor representation for both SIWE and UCAN. Currently it's possible to encode a SIWE message and signature as CACAO. From my surface level understanding of your ADL approach it seems like that is pretty similar to what CACAO is doing for SIWE.

There is a lot of context here that I lack to provide meaningful feedback, but I'd be happy to have a call to try and get on the same page if you'd be interested in doing it.

Nuances aside settling on common representation does sound like good idea, but again I wonder what the tradeoffs are.

@oed Is there comparison of UCANs and CACAO written up somewhere ? I have read through the link and ceramic blog post but honestly I'm not sure I understand what the limitations it spoke to.

[oed]

CACAO is a way to represent a SIWE messge + signature in IPLD as dag-cbor. It seems like what you are doing with your ADL is to represent a UCAN in IPLD using dag-cbor.
Would definitely be interested in chatting about this over a call!

@ukstv will provide more details as he has already thought about how UCANs could potentially be stored as a CACAO.

but again I wonder what the tradeoffs are.

Yep, that's what I would like to figure out as well!

[ukstv]

I tend to believe, UCANs and CACAOs are the same semantically, even the schemas are similar.

The major differences are:

1. "proof suite" aka signature algorithm
   UCAN being JWT mandates using JOSE signatures, which are mostly incompatible with blockchain signatures or DIDs. This is important for "Sign in with blockchain" scenario, like SIWE. As far as I understand, it is a major limitation of UCAN, as it strives to be compatible with existing tooling. If a new proof suite is added to UCAN, it becomes incompatible with JWT.
2. canonicalization
   With CACAO we want a capability to be compatible with IPLD data model. It means, that for non-canonicalized JWT case, we have to store the raw bytes of headers and the payload.

Here is the first attempt to store UCANs as CACAO: https://hackmd.io/@ukstv/Hy9bQB-Hc/edit It includes some comparison of UCANs with CACAO. Here we disregarded canonicalization. I personally thought that we might converge towards canonicalization everywhere, which seems not to be the case. I understand now it is important for backwards compatibility reason. So, maybe the way to go is to add a type like [email protected], and raw bytes representation in addition to IPLD fields mentioned in the spec.

The contents would be semantically identical to your approach, with few differences:

• same IPLD representation, and IPLD availability of all the fields, i.e. using vanilla ipfs.dag.get and ipfs.dag.put,
• compatibility with blockchain signatures and DIDs; your schema seems to be unsuitable for keys and DID methods other than limited (=intersection of JOSE and did:key algorithms) form of mandatory did:key,
• slightly larger size in case of non-canonicalized UCAN due to additional raw bytes stored.

Would be nice to discuss a possible convergence in a call.

[oed]

In the ADL you are suggesting @Gozala, it seems like only did:key is supported.

According to the UCAN spec:

and MAY be augmented with additional DID methods.

Is this intentional? Seems like the ADL should support any DID that possible UCAN implementations may use?

[Gozala]

In the ADL you are suggesting @Gozala, it seems like only did:key is supported.

According to the UCAN spec:

and MAY be augmented with additional DID methods.

Is this intentional? Seems like the ADL should support any DID that possible UCAN implementations may use?

That is probably an oversight on my end. We need issuer to be did:key: as issue needs to sign a message with specific key, that said I suppose we have no reason to constraint audience.

[oed]

We need issuer to be did:key: as issue needs to sign a message with specific key

Well, there are other DID methods that supports signing JWTs! As long as the DID has one Verification Method that contains the public key that signs the JWT it is totally valid.

[Gozala]

Oh actually now that I think about it's bit ingrained into data model, current we represents issuer and audience as multicodec code tagged public keys. That said I'd be amendable to revisit this.

More broadly, our current thinking is than instead of putting different DID's into UCANs we will just associate those with some did:key via access/identify protocol describe here https://hackmd.io/pV1GSyMZQ9yQ_m63fGDMEA

That way actors can map one with another, but all the invocations would stick to public keys.

[Gozala]

Well, there are other DID methods that supports signing JWTs! As long as the DID has one Verification Method that contains the public key that signs the JWT it is totally valid.

I lack context here and in no way opposed to supporting other methods. That said I think current interfaces at least are flexible enough to support other methods. Issuer is defined in terms of

js-dag-ucan/src/ucan.ts

Lines 17 to 22 in d7ec23a

	export interface Agent {
	did(): DID
	}
	export type Audience = Agent
	export interface Issuer<A extends number = number> extends Signer<A>, Agent {}

js-dag-ucan/src/crypto.ts

Lines 35 to 38 in d7ec23a

	export interface Signer<A extends number = number> {
	readonly algorithm: A
	sign<T>(payload: ByteView<T>): Await<Signature<T, this>>
	}

Which is basically { did():string, sign(bytes:Uint8Array):Promise<Uint8Array> } that is to say I have no problem imposing did:key requirement, as issuer can tell what it's did is and sign arbitrary bytes it should be fine.

Verification is out of scope here as that requires more that just signature validations so I think we expand support to arbitrary DIDs if that is desired.

[oed]

I'm less worried about this particular API and more about the byte representation in IPLD. We'll discuss this in our call next week however :)

[Gozala]

1. "proof suite" aka signature algorithm
   UCAN being JWT mandates using JOSE signatures, which are mostly incompatible with blockchain signatures or DIDs.

I'm nut sure I fully understand this point. We have to format data model into JWT form and than sign that with private key, which I agree is unfortunate but feel like not too terrible of price to pay for the compatibility.

I might lack context in regards to compatibly with blockchains signatures or DIDs however.

This is important for "Sign in with blockchain" scenario, like SIWE. As far as I understand, it is a major limitation of UCAN, as it strives to be compatible with existing tooling. If a new proof suite is added to UCAN, it becomes incompatible with JWT.

I don't understand this point, it could be that UCANs are more limited than CACAO is, however we seem to find them to be a good fit for our use cases. In regards to "sign in with blockchain" we think of it as capability to associate a blockchain account with a specific did:key (as per linked access/identify doc).

[Gozala]

2. canonicalization
With CACAO we want a capability to be compatible with IPLD data model. It means, that for non-canonicalized JWT case, we have to store the raw bytes of headers and the payload.

That is more or less what we do here. On top we have a view layer that abstracts underlying encoding through an interface that more or less matches the IPLD schema.

[Gozala]

Would be nice to discuss a possible convergence in a call.

Sure lets discuss and find ways to improve.

[Gozala]

Closing this since discussion has moved to https://github.com/ucan-wg/ucan-cacao