Short-lived WebID's can be almost like hosted VC's

[michielbdejong]

Break-out discussion from #79:

We're thinking we need VC and that leads us to HttpSig and all of that is a big change, upsetting big parts of the system. So maybe we can find a solution closer to home.

The way we currently use WebID-OIDC-DPoP for identity can be even generalised. For instance, normally I log in with a "credential" with issuer solidcommunity.net, which proves that I control https://michielbdejong.solidcommunity.net. Or at face value it's even slightly more narrow, it proves that I control the document fragment /profile/card#me on there. And that is referred to in ACL docs, and then for the rest we can take it from there.

The particular use case I'm working on is (temporary or eternal) access to a particular resource (for instance a newspaper article or a piece of art, song, etc) based on proof of payment. So for that, I could just log in as https://paymentprovider.com/receipts/34252q3wr34#payer and then the resource server knows that I'm the person who paid https://paymentprovider.com/receipts/34252q3wr34.

Downside is we have to swap identities in the client, depending on the request. So for a given URL, after it gave a 402 Payment Required, stop sending your usual WebID and instead start sending your payer ID. If each visitor is given a different challenge ('34252q3wr34' in this example), which could even just be a hash of your WebID, then proof of possession of the payer ID implies both that you paid and that before you started paying, you already had possession of a specific WebID.

So that's a way of solving my use case without using VC. The downside is that it links the resource server to a specific shortlist of payment providers. But other than that it's quite elegant, I think.

It can be generalised to solve the stories of both 2.9.1 and 2.9.2:

Of course the PKI potential of VC is more generic than listing specific hostnames who can verify a challenge.

But as a rough sketch of how this flow would work in general, in the ACL you can grant https://age-prover.com/proofs/#ok access and then send some response header to the client saying "go proof that you have possession of https://age-prover.com/proofs/#ok", after which the client would present https://age-prover.com/proofs/ to the user, etcetera.