Required Credentials Discovery

[matthieubosquet]

On proposal

ACP, WAC, WAC+...

Details

A resource's access permissions are mandated by its effective Access Control Resource which contains an assortment of potentially complex and private rules.

A client that cannot read (no access) or understand such rules will nonetheless need to understand which credentials to present in order to gain specific access permissions to a resource.

I would propose having a standard required credentials discovery mechanism is necessary.

Maybe having the wac-allow structured header extended to accept IRIs as permission-group could be explored, especially if the wac-allow header becomes defined at the spec level and mapped to operations in the Solid protocol.

Maybe someone familiar with verifiable credentials could suggest whether there is a generic enough mechanism there to fulfill this requirement (cc @acoburn).

Maybe something completely different is required.

Acceptance criteria

What actions are needed to resolve this issue? (checklist)

• Discuss and agree whether a standard required credentials discovery mechanism is necessary or not.
• Propose a mechanism that would be generic enough to accomodate our use cases.

[bblfish]

A client that cannot read (no access) or understand such rules will nonetheless need to understand which credentials to present in order to gain specific access permissions to a resource.

A client that cannot access those rules or descriptions, can assume it does not have access to the resource. An ACR may be public, but parts of the description protected.
See the example in issue 189 comment.

(As for problems of "understanding" I think we should place those out of scope).

Maybe having the wac-allow structured header extended to accept IRIs as permission-group could be explored, especially if the wac-allow header becomes defined at the spec level and mapped to operations in the Solid protocol.

Why place in a header complex information that is already available in the ACR? Headers are not a good place to make complex statements.

[matthieubosquet]

A client that cannot access those rules or descriptions, can assume it does not have access to the resource. An ACR may be public, but parts of the description protected.

Say I have 2 WebIDs, how do I chose which one to use to access a resource?

The same kind of question holds with credentials.

Maybe group membership is a good abstraction layer for chosing between WebIDs and could be advertisable consistently with the way required VCs might be.

Why place in a header complex information that is already available in the ACR? Headers are not a good place to make complex statements.

Well, if access modes associated to a specific group are already advertised in the wac-allow header, one might question how much more complexity it is to generalise the mechanism for a credential to access modes mapping.

[bblfish]

A client that cannot access those rules or descriptions, can assume it does not have access to the resource. An ACR may be public, but parts of the description protected.

Say I have 2 WebIDs, how do I chose which one to use to access a resource?

Well you use the one that is specified in the group. So let us say the acl for is world readable and contains:

<#r1> a :Authorization;
    :accessTo <party>;
    :agentGroup </g/082999bc-eb9f-11eb-9a03-0242ac130003#> ;
    :mode :Read .

Q: Does this create a privacy problem for the members of </g/082999bc-eb9f-11eb-9a03-0242ac130003#> ?

Say that group contains

<#> a foaf:Group;
   foaf:member <https://bblfish.net/people/henry/card#me>;
   foaf:member <https://csarven.ca/#i>; ...

(sorry if I stick to foaf, as I know that ontology well)

That group would have an access control resource </g/082999bc-eb9f-11eb-9a03-0242ac130003.acl> containing the following subgraph:

<#r1> a :Authorization;
    :accessTo </g/082999bc-eb9f-11eb-9a03-0242ac130003>;
    :agentGroup </g/082999bc-eb9f-11eb-9a03-0242ac130003#> ;
    :mode :Read .

So to answer Q above the answer is "no, it does not create a privacy problem for the members of that group, since they are the only ones who know they are members."

It really reveals nothing to anyone to tell them that a resource is visible to members of some group, if they don't know more about that group. Any resource has read and write restrictions to members of some groups (be that group a foaf:Agent!). So one learns nothing when discovering that members of some group have read access to a resource!!

Q2: How would one of the members know which WebID to use to authenticate?

Well it would use one of the methods accepted by the server using identities relates to the WebID listed in the group. At least that is the simple obvious answer.

The same kind of question holds with credentials.

Credentials is a very different situation. If the resource requires proof of being over 18, then there is no problem if the ACLs states that publicly. There would be no privacy problem knowing this, since it does not list any individuals. The same with proof of payment, etc...

Maybe group membership is a good abstraction layer for chosing between WebIDs and could be advertisable consistently with the way required VCs might be.

Why place in a header complex information that is already available in the ACR? Headers are not a good place to make complex statements.

Well, if access modes associated to a specific group are already advertised in the wac-allow header, one might question how much more complexity it is to generalise the mechanism for a credential to access modes mapping.

The WAC-allow header is not for authorization. It is just a hint given to the (non-authorization) client (e.g. Dokieli) so that it knows, given that is already authenticated, if it can or cannot display an edit button for some content. That is a completely different use case.

[matthieubosquet]

I'm not questioning the fact that designing access control resources to selectively display access control statements that are not a privacy issue is possible (even though it is currently impossible in WAC).

I am asking for a generic mechanism to advertise required credentials that would not be restricted to but also include group membership.

I don't think it is really constructive to dismiss off the bat the fact that some clients might not be able to understand ACRs or that the current session might not give the full access to ACRs an actor might be entitled to otherwise.

[bblfish]

I am asking for a generic mechanism to advertise required credentials that would not be restricted to but also include group membership.

Ok, I am saying that can be part of the ACR. I have given many examples of this over the past 8 months such as this in December 2020

<#adultPermission> 
          :accessToClass :AdultContent;
          :agentClass :PersonOver21 ;
          :mode :Read .

I don't think it is really constructive to dismiss off the bat the fact that some clients might not be able to understand ACRs

Why? The browser vendors don't start by specifying browser technology on the presupposition that some other tool may not understand HTML, CSS, JS, HTTP, TLS, etc...
Instead they build libraries to make these standards easy to use. Some of these tools are extremely advanced, often much more than what we are building here. If there is interest the tools will get better as there is more competition in developing them.

If you go down the road of creating protocols that need to work for the lowest common denominator, you end up in the indy-web camp where even RDF triples end up being too complicated to explain to Mom and Pops building web sites. True, RDF is not something Mom and Pops need to learn: we have Apps to intermediate between them.

or that the current session might not give the full access to ACRs an actor might be entitled to otherwise.

Well ok, we need to think through the access control restrictions on rules.
If you hide them so that nobody sees them, but then invent another protocol to show them, then why did you bother hiding them in the first place? All you will end up doing is spending a huge amount of time re-creating a non-web friendly protocol.

[elf-pavlik]

Say I have 2 WebIDs, how do I chose which one to use to access a resource?

@matthieubosquet are you currently using any application (I don't mean solid application) that doesn't require you to explicitly 'switch account' and while you are using it it assumes that you are using it as that specific currently logged in user?

I can't recall seeing an application like that, on contrary 'choose account you want act as' are rather common

Maybe group membership is a good abstraction layer for chosing between WebIDs and could be advertisable consistently with the way required VCs might be.

I think group membership credential is a good use case and we have it captured in 2.9.1. Possession of a group membership verifiable credential. To complement it I plan to add similar use case following my understanding of Authorization Capabilities for Linked Data, which seems quite similar to what we do with Access Grants in Interop Panel

• Omni corp. issues ZCAP-LD to ACME corp.
• based on that access grant ACME corp. issues (child) ZCAP-LD to their (possibly specific) employees
• those employees now can access those resources owned by Omni corp. and shared with ACME corp. based on ZCAP-LD delegation chain

I believe in some scenario it will be preferred from even advertising publicly that one has to have membership credential of some specific group.

A client that cannot read (no access) or understand such rules will nonetheless need to understand which credentials to present in order to gain specific access permissions to a resource.
[...]
Maybe something completely different is required.

IMO normal resource clients (not dedicated authz managing apps) shouldn't need to understand any of those rules, at the same time we need to have some resource client focused protocol for communicating what needs to be presented. I think something inspired by User-Managed Access (UMA) 2.0 - Claims-Gathering may be a decent approach to explore further.

EDIT I think we also need to have very clear understanding of credential disclosure UX, we want to avoid resource clients silently disclose any user credentials since malicious resource servers could be used to bait that disclosure. At the same time we don't want to get back to 'choose your client ssl certificate' pop up for every background request 😓