Client Capabilities: Verifiable Credential Proofs vs. Special discoverable prefix in storage

[elf-pavlik]

From #59

@zenomt: a document with a URI in an approved (according to the user's profile) location is just as good as a credential signed by an approved (according to the user's profile) issuer, but with no extra cryptography required (and it's a lot simpler).

If DPoP mechanism and verifiable credentials proof use the same crypto, relying on VC proofs doesn't seem like additional implementation complexity. I actually consider it simpler than having some magic location in the storage which can't be listed etc. Anyways I think we can consider separately how capabilities presented by the client can be verified

EDIT: reference to @zenomt's proposal: #48

The URI for the App Authorization document MUST be in (at a sub-path of) an acl:appAuthorizations in the user's profile (otherwise the resource server MUST ignore it):

[zenomt]

note: i am still -1 on DPoP for Solid.

the point about "no extra cryptography" isn't necessarily about implementation complexity, but about semantic complexity and the actual cryptographic operations that must be carried out.

my main argument for the "App Authorization documents" construction is that, given an identity (and corresponding contents of its profile) and an appid, app-specific authorizations can be implemented with just plain old linked data, independently of how the identity or appid are established (such as by webid-oidc including appid, or by webid-tls with Origin header, or a future mechanism).

[elf-pavlik]

https://solid.github.io/data-interoperability-panel/specification/ represents most advanced work on authorizing solid apps (clients)