Credential based access control (WAC + VC)

[joepio]

Not entirely sure is this is the right place for this issue

Web access control allows for a decentralized authorization mechanism, where some data owner can specify which individuals or groups have (read / write) access to specific resources.

However, there exist many use cases where the data owner does not know the identity of the data user beforehand, but does know a set of credentials that should give access. For example, Facebook's "friends of friends" privacy setting gives access to people who have friends that are friends with you. Or how about an adult video supplier who requires an 18+ credential for viewers. Or a local platform for people who live in some neighborhood might require a location credential.

The W3C Verifiable Credentials spec describes how to store, serialize and validate these credentials. Considering the use cases described above, it might make sense to have a link between WAC and VC. For example, an acl:Authorization might have a acl:requiredCredential, which links to some acl:CredentialRequirement, which consists of:

• A required field (a predicate URI)
• A required value (Literal / URI)
• An issuer (URI of some authority)

Some questions:

• Should this be part of the VC spec, WAC or something else?
• What needs to be standardized further to offer the best possible UX? For example, the current VC spec seems to require manual selection of credentials, but this could be automated if we standardize the query process, i.e. give the verifier some standard to define where the credential should be found, so the one asking for access knows how to get / find the right credential.

[michielbdejong]

acl:CredentialRequirement, which consists of:

A required field (a predicate URI)
A required value (Literal / URI)
An issuer (URI of some authority)

And maybe also include the subject's WebID in the VC? Otherwise it just says "someone is over 18", rather than "the current user is over 18".

[elf-pavlik]

@jaxoncreed also has use case around Alcoholics Anonymous, where access would require membership Bearer Credential credential but no specific user identity. I think we should move this issue to https://github.com/solid/authorization-and-access-control-panel

I'll take another look at UMA 2.0 Interactive Claims-Gathering. Granting access based around more general claims / credentials may also come in support of @zenomt's proposal to allow RS delegating that logic to associated AS. In UMA 2.0 also AS gathers claims not RS.

And maybe also include the subject's WebID in the VC? Otherwise it just says "someone is over 18", rather than "the current user is over 18".

For that we could rely on 'sender constrained tokens' which don't require user's identity but only guarantee that client presenting the credential has right to do it. DPoP provides one mechanism for sender constraining credentials. VC spec mentions Token Binding

However, there are zero calendar systems that I'm aware of that allow passing custom HTTP headers, let alone a whole procedure for logging in first. So they need an authenticated URL (no matter no strongly we like or dislike that) such as https://example.org/calendars/work?auth=xxx-yyy-zzz. So 1) a credential that proves their access rights and 2) the ability to communicate that credential through a URL.

In specifications repo I see issue about capability urls solid/specification#143

[csarven]

@joepio Just wanted to ack this issue. Do you think the use cases along the lines of https://solid.github.io/authorization-panel/authorization-ucr/#uc-minimalcredentials and https://solid.github.io/authorization-panel/authorization-ucr/#capabilities-vc are in the spirit of what you'd like to make sure we address? If not, would you like to carve out the use case in the https://github.com/solid/authorization-panel repo? We can also update existing ones if it doesn't quite capture or unclear.

[joepio]

Best continue discussion in ACL / Authorization-Panel tracker (since that's replacing WAC): solid/authorization-panel#79

[csarven]

Not at all "replacing WAC". The activity in authorization-panel is orthogonal. So is VC and how that may be coupled with the other mechanisms in an authorization system/framework. See if the UC that I've linked to captures what you're interested in, if not let's have another UC. We can talk about spec-level solutions after the functional requirements. Okay to close.

[michielbdejong]

Yes! This issue describes both the use case and a partial proposed implementation.

Use case definition

I think the UC is identical to https://solid.github.io/authorization-panel/authorization-ucr/#capabilities-vc so for that we're covered.

Proposed solution

Will keep searching to see where we can discuss the partial solution proposal.

To arbitrarily complete the proposed solution and give us a strawman, we could pick predicate strings as follows:

• the first predicate, connecting the acl:Authorization to the RequiredCredential, would be acl:requiredCredential, as Joep already proposed.
• for the RequiredCredential we could use requiredField, requiredValue, and credentialIssuer.
• we can imply that the credential needs to be about the currently authenticated agent.

Open issues:

• to complete https://solid.github.io/authorization-panel/authorization-ucr/#req-vc we still need a way for the agent to proof possession of the VC to the resource server.
• we also still need https://solid.github.io/authorization-panel/authorization-ucr/#req-vc-determine

[elf-pavlik]

for the RequiredCredential we could use requiredField, requiredValue, and credentialIssuer

can we just handle it with data shapes?

[michielbdejong]

sounds good! what would that look like?

[elf-pavlik]

If we want a specific issuer https://vc.acme.example/ and with field org:memberOf having value https://acme.example/ we could have ShEx shape like

prefix cred: <https://www.w3.org/2018/credentials#>
prefix org: <http://www.w3.org/ns/org#>

<#RequiredCredentialShape> {
  cred:issuer [<https://vc.acme.example/>] ;
  cred:credentialSubject {
    org:memberOf [<https://acme.example/>]
  }
}

@ericprud should probably double check me

[michielbdejong]

Ah, yes! Let's try to do it that way.

[michielbdejong]

Continuing conversation in authorization panel ^