Consider state proofs when trust boundaries are crossed

[msporny]

@dhh1128 wrote:

What we are doing here is trusting the service to tell us whether a credential has been verified. As long as the API we're building is meant to be "internal" (that is, the service and the client of the service are both running inside a trust context governed by the same identity), trusting what the service asserts here is probably good enough. But if we ever run the service in a mode where a trust boundary is crossed (e.g., a SaaS service operated by a different entity from the client), then there is a trust issue. A way to resolve it would be to return a state proof. But of course that then creates a crypto and processing burden on the client, which is likely not to be viable in many cases. Which calls into question the wisdom of asking an external service to verify something for you in the first place.

[dlongley]

If the client doesn't trust the verifier, the client should just run the verification checks itself. Having the verifier create yet another proof that the client has to check does not seem to be particularly helpful and instead appears to just create unnecessary additional work. I recommend we close this issue and indicate that the APIs presume (require) trust boundaries are not crossed and that the purpose of them is a separation of concerns and consolidation of verification code behind an API.

[dhh1128]

I think I agree with Dave. I brought up state proofs not because I want them, but because they're a logical place for minds to go -- and then I pointed out why they're not necessarily practical. As long as we understand that the API can't cross trust boundaries, and we document that intentional caveat, I'm cheerful with just trusting the service.

[msporny]

We need to write some specification text that states that if a client is calling an HTTP endpoint, then they are explicitly trusting it to perform the action that is detailed in the specification.

[OR13]

blocked by no defined api security, closing as won't fix.