Proposed Initiative - Extend WAC specification with verifiable credential support

[justinwb]

Creating this as a standalone initiative proposal from #72 so that it can be tracked individually. The UCR work should help to inform the scope, priority, and mission of this initiative.

The intent would be to allow WAC authorization statements to make access determinations based on whether or not a given verifiable credential is presented and verified.

[bblfish]

That is actually part of what I was setting out to do for my PhD. For some examples see the third chapter on security of my 2nd year report.

[michielbdejong]

I think there are three parts to flesh out:

• express the need for a VC in the ACL doc or similar
• express the need for a VC in a 4xx response or similar
• put a VC into a request header or similar

I'm looking for the third one but not finding much yet.
This may be a lead, though: https://www.w3.org/TR/vc-data-model/#authorization

I know we did experiments with storing a w3c-vc on the user's pod, but not with requiring the user agent to present one.

[bblfish]

I agree there is quite a lot to be worked out still @michielbdejong .
You may want to look at how I tie these together in the HttpSig Authentication proposal. It is also PR 125 on the authentication panel repo.

• I have an example there of how an age requirement can be expressed in the Access Control Resource (right at the end).
• Instead of putting a VC in the request header, I propose linking to it. With the P2P protocol for HTTP this could even refer to a VC on the client (a bit far out technically, but it is good to keep that possibility in mind, as it is extremely elegant)
• It shows how the server could express its HttpSig capability to the client, but perhaps it should be able to express that it is also Credential Aware.

[bblfish]

Actually I do show issue 176: Only Trust Certain issuers of Identity of the Authorization panel how one could express an Access Control Rule that allowed only credentials from certain issuers to be acceptable. But there are certainly other ways to do that too. It would be helpful if it were orthogonal a bit because being over 21 could be proven in so many different ways.

[michielbdejong]

Moving discussion of RequiredCredentialShape here from solid/web-access-control-spec#79 (comment).

[michielbdejong]

being over 21 could be proven in so many different ways.

I agree, https://solid.github.io/authorization-panel/authorization-ucr/#capabilities-vc is a more generic goal than https://deploy-preview-152--authorization-panel.netlify.app/authorization-ucr/#uc-trustedissuers

Your remarks made me think and I want to propose an alternative way to solve the stories of both 2.9.1 and 2.9.2: #185

[michielbdejong]

https://identity.foundation/presentation-exchange/ also seems like it could be relevant