Client identification

[csarven]

Clients making HTTP requests on behalf of agents (social entities) may need to be given different set of access privileges than the agents.

Considerations:

• Client is authenticated - protocol agnostic.
• Specific predicate for the client (eg. acl:client as possibly a subPropertyOf acl:agent) vs. reuse acl:agent since the object ie. the WebID that's changing.
• Access privileges given to a client is same as agent's or can be different.
• Related but may not be relevant: whether an access subject (eg. agent, agentGroup, agentClass) delegates (acl:delegates) a client to act on behalf of the agent.

[timbl]

When a person with one webid does something using an authenticated client app, then they both need to have access. Both in this case have a webid. Seems logical to use acl:agent to connect to both.

[timbl]

("delegation"? No, when you are talking about a bot, a free running system with its own webid, not an app, then delegation is when I say that I want to confer some rights which I have to the bot, say, or another person)

[elf-pavlik]

I believe this use case may help with illustrating case where user delegates subset of their access rights to an application they use to exercise their access rights, while following the principle of least privilege.
https://solid.github.io/authorization-panel/authorization-ucr/#uc-client-constraints

[TallTed]

"Clients" appear to be, and should likely be referred to as, "agents (software)" or "software agents" when used alongside or with "agents (social entities)" or "social agents" (which appear to be "users", which are commonly discussed alongside "clients" and "servers").

This will likely help to simplify some things (though it may complicate others) when you get deeply into delegation and such, as I would think there's less "special" handling needed for a "delegate client" (which is a new class that largely duplicates agent) than for a "delegate agent" (which is a slightly specialized case of the agent class).

[matthieubosquet]

Specific predicate for the client (eg. acl:client as possibly a subPropertyOf acl:agent) vs. reuse acl:agent since the object ie. the WebID that's changing.

I don't think the same predicate can be used for identifying agent and client in a WAC Authorization.

A server will receive a request performed by an agent x using a client y. The WAC engine will need to be able to discriminate between the two since I assume the aim here will be to further restrict access depending on which client an agent uses, that is, if agent x has read/write/control and the client y they're using has only read, then read should be the only granted permission.

Is my assumption correct?

Maybe it is worth considering that it might imply a significant departure from WAC's current "grant permission" on first match approach.

Maybe I'm naively thinking the client would be defined alongside agents in an Authorization and actually what is meant here would be a completely separate mechanism for filtering access permissions altogether. I'd be curious to understand what would be envisaged if that were the case, maybe an AuthorizationFilter?

[elf-pavlik]

A server will receive a request performed by an agent x using a client y.

That's the assumption in Solid-OIDC, Resource Server (Solid Storage) should have both identifiers available for any request. The only exception is access by navigating the web browser directly to the resource, in which case the Solid Storage itself acts as OAuth client.

Grant Negotiation and Authorization Protocol: 1.1. Roles uses following terminology:

Resource Client (RC, aka "client")

Requests tokens from the AS and uses tokens at the RS. An instance of the RC software is identified by its key, which can be known to the AS prior to the first request. The AS determines which policies apply to a given RC, including what it can request and on whose behalf.

Requesting Party (RQ, aka "user")

Operates and interacts with the RC.

---

Maybe I'm naively thinking the client would be defined alongside agents in an Authorization and actually what is meant here would be a completely separate mechanism for filtering access permissions altogether.

I would like to emphasize that UC linked above has title 2.5.2. Limiting application access while not acting as resource controller.

[acoburn]

The GNAP terminology is very useful here, even if one is not using the GNAP protocol.

I am 👍 on any mechanism that is able to distinguish between an App (i.e. "Resource Client") and a User (i.e. "Requesting Party")

[matthieubosquet]

I would like to emphasize that UC linked above has title 2.5.2. Limiting application access while not acting as resource controller.

I also think it would be useful and make sense to be able to filter resource access permissions based on Resource Client globally. The natural fit for expressing such restrictions in my opinion would be the WebID. But then, that is a completely new mechanism, so I wouldn't jump on it.

Additionally, I think it will be quite prevalent to restrict resource access permissions based on Resource Client for specific resources over which one is acting as the resource controller. Almost no app should be unrestricted to access my data and I'd be keen to see what such access permissions filters might look like too.

[elf-pavlik]

The natural fit for expressing such restrictions in my opinion would be the WebID. But then, that is a completely new mechanism, so I wouldn't jump on it.

Do you refer to https://github.com/solid/web-access-control-spec#other-ideas-about-specifying-trusted-apps ?

This approach has some privacy issues, person may no want to make public what authorization they give to which app. We have prior conversation on alternative approaches. One would involve out of band notification to relevant parties where app access restrictions have to be enforced. Another alternative would just require client application to present claim (credential / capability) proving authorization that user granted it. I believe this conversation should continue elsewhere, just hinting here that we have prior discussions around those requirements.

[jeff-zucker]

The term "client" has multiple possible meanings. What makes sense to me is sub properties of acl:agent:

  acl:user [a foaf:Agent, foaf:Person]
  acl:app [a foaf:Agent, dc:Software; rdfs:comment "an OIDC Resource Client"]
  acl:group [a foaf:Agent, vcard:Group] 

[elf-pavlik]

client is pretty established in OAuth2 and GNAP which aims to learn from OAuth2 experience.

[jeff-zucker]

And how many people who aren't familiar with those standards are going to know or remember the difference? Am I the agent or the client? And in this case, the client is an agent which adds an additional confusion.

[elf-pavlik]

In Interop spec we refer to Person or Organization as Social Agent and to clients as Applications. I think we should still map them to GNAP / OAuth2 terminology.

• Social Agent can act as End-user or Resource Owner
• Application pretty much acts as a Client.

[AJamesPhillips]

@jeff-zucker your comment: #81 (comment) reminds me of hueniverse 's insightful and ardent critique of OAuth2: https://web.archive.org/web/20160304014802/http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/
https://web.archive.org/web/20160306192304/http://hueniverse.com/2012/07/30/on-leaving-oauth/
https://vimeo.com/52882780
https://web.archive.org/web/20160304014608/http://hueniverse.com/2015/09/19/auth-to-see-the-wizard-or-i-wrote-an-oauth-replacement/