content-discovery: content claim protocol handlers

[Gozala]

Goal

Goal is to spin up a content-claims UCAN based protocol so our internal systems can publish signed claims about UnixFS files about which cars underlying blocks are in and where those CARs are located. Details of the actual UCAN capabilities are drafted in content-claims spec

Task

Create another UCAN handlers for assert/location, assert/inclusion and assert/partition capabilities that return {} to invocations with a provisioned (one that has web3.storage provider) space DID.

### Tasks
- [ ] https://github.com/web3-storage/w3up/issues/749
- [ ] https://github.com/web3-storage/w3up/issues/750
- [ ] use them in access-api or w3infra
- [ ] document how to invoke them in the context of a space
- [ ] document using observablehq how to invoke them

Nuances

My initial draft used space DID in the with / rsc field which @mikeal has changed to CID. We can not use CIDs as they need to be URIs but we probably could derive them. However ucanto will not allow you to publish with a resource that you do not own, however we could provide a hook to allow invocations for the specific URL schema that we could use for CIDs.

That said I still maintain opinion that using space DID there and utilizing separate field for the subject CID is a better design, because it allows us to decide who owns that claim. Please note that iss is not the same, because I could delegate you capability to make claims on my behalf, yet I'm the responsible actor not the one issuing the claims.

I think rational for @mikeal's change was to make generic indexing possible of arbitrary invocations, which I think is a good idea but I thing that we should just allocate another field (as in IPLD schema, but probably same one across all claims maybe subject or about) and build our indexers around it. We could later figure out how to utilize rsc / with field instead, but after we have time to do a careful deliberation.

[Gozala]

We also considered doing something more abstract described in invocation router document. If we go this route we would essentially accept invocations to arbitrary audience (that were pre-registered) and index received invocations for them.

Tradeoff with this approach is that:

1. We will not be able to verify ucans as we won't know the capability semantics.
2. It is less clear what would we index and how, with concrete capabilities it is a lot easier to do.

Although perhaps it would be a good idea to allow provider/deploy to specify set of capabilities it supports along with keys it wants to index by. That way we get a flexible & configurable system where we can try various things without encoding them in the code.

[mikeal]

That said I still maintain opinion that using space DID there and utilizing separate field for the subject CID is a better design, because it allows us to decide who owns that claim. Please note that iss is not the same, because I could delegate you capability to make claims on my behalf, yet I'm the responsible actor not the one issuing the claims.
I think rational for @mikeal's change was to make generic indexing possible of arbitrary invocations, which I think is a good idea but I thing that we should just allocate another field (as in IPLD schema, but probably same one across all claims maybe subject or about) and build our indexers around it. We could later figure out how to utilize rsc / with field instead, but after we have time to do a careful deliberation.

I get what you're saying here and I think I'm ready to agree with you on this.

I think a "claim" field that is always a CID works best. Let's make it a top level field in input so that we don't have to leave the invocation spec in the implementation.

We could still build this as a generic system though, we'll just need to define one extra index whenever we get as assert/ invocation, but this would allow us to use the att and iss fields to effectively namespace the service by specific providers, and through that find a path to implementing this a bit more generically.

[mikeal]

Oh, and we need to define what the "rsc" should be. These aren't signed independently so I don't see why we'd duplicate the iss in the rsc field when it can't actually be trusted independently. Perhaps there's a single rsc that we define for Content Discover Claims in this Spec, that would make the indexing of it very useful.

[Gozala]

Oh, and we need to define what the "rsc" should be. These aren't signed independently so I don't see why we'd duplicate the iss in the rsc field when it can't actually be trusted independently. Perhaps there's a single rsc that we define for Content Discover Claims in this Spec, that would make the indexing of it very useful.

The iss field is more like what device / app (agent) send invocation and rsc / with field is the authority on who's behalf it happened. In other words drawing any conclusions based on iss is a bad idea, it is more of route information than the principal identifier.

It is only the same for the root of delegation chain, rest of the delegation chain will retain the rsc but not the iss and provide evidence that iss authorized it.