What if you can't derefence a CID?

[bumblefudge]

One thing that I couldn't quite figure out on slow readthrough was what happens if CIDs aren't resolved/fetchable? what happens if the CID value in prf resolves to something other than the proof? I assume the whole invocation is invalid if any proof it relies on can't be fetched or if anything in the graph is malformed, but maybe making more explicit if an invocation that has an invalid link in its chain is different from an invocation with a malformed link in its chain and from an invocation with an expired link in its chain CAN be or MUST be treated differently, and if conforming implementations need to give different error messages in those three cases, etc?

[matheus23]

I assume the whole invocation is invalid if any proof it relies on can't be fetched or if anything in the graph is malformed

That's a really good question. I think implementations don't handle this consistently.
In general, if there's some "path" through the DAG of UCAN delegations with valid attenuations, signatures, valid issuers and audiences, etc. then the invocation should be valid.

This is so that UCAN invocation checking can short-circuit once it found one way to "realize" the final capability needed.

If the whole UCAN DAG had to be valid, then you would have to fetch the whole DAG to check its correctness to be sure you didn't miss any incorrect formatting that would make the whole invocation fail.

I also agree that this should perhaps be added to the spec.

[bumblefudge]

feel free to tag me for review when someone PRs in an "error handling" section and/or does an editorial pass to make these codepaths/logic points more explicit throughout the spec! i don't watch this repo as closely as I should

[expede]

Good point @bumblefudge!

Now clarified in 0.10 PR. TL;DR if you can't dereference the CID, you can't prove your chain, and validation fails. You need to make sure that the validator has the requestite subgraph. There are many mechanisms for this, and it's left to the specific transport spec (e.g. UCAN-over-HTTP, IPFS UCAN, etc)

[expede]

Closed by #132