search

solid / authorization-panel

Github repository for the Solid Authorization Panel
MIT License
19 stars 20 forks source link

acp:CreatorAgent logic #262

Closed bblfish closed 2 years ago

bblfish commented 3 years ago

On proposal

ACP

Details

Acp haș defined an acp:CreatorAgent. It says:

The ACP Creator Agent matches all contexts where the creator matches the defined agent. In an authorization graph, the ACP Creator Agent can be used as the object in a triple where the subject is a matcher and the predicate is acp:agent.

What kind of Agent is such an Agent? Is not everyone with a Solid Account a creator of some resource?

Acceptance criteria

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

If those cannot be shown satisfactorily, remove the definition from the PR.

bblfish commented 3 years ago

I have opened a discussion space for this: #261 giving rights to the creator of a resource.

matthieubosquet commented 2 years ago

The acp:CreatorAgent is the agent that created the resource that is being requested access over.

That would be denoted by a context graph where the instance of resource access is described with both the agent and the creator having matching URIs. For example:

  _:context
    a acp:Context ;
    acp:agent ex:Bob ;
    acp:creator ex:Bob ;
    acp:target ex:resourceX ;
    acp:owner ex:Alice ;
    acp:client ex:ClientApplicationY ;
    acp:issuer ex:IdentityProviderZ .

See also: https://solid.github.io/authorization-panel/acp-specification/#context-attributes

In that case, if Bob tries to access ex:resourceX and there is a Matcher defined:

  ex:matcherA
    a acp:Matcher, acp:AgentMatcher ;
    acp:agent ex:Djamila, acp:CreatorAgent .

See also: https://solid.github.io/authorization-panel/acp-specification/#agent-matcher

Then agent ex:Bob would have the policies relying on ex:matcherA consider it as a positive match, because in the context graph the agent requesting ex:resourceX is also the agent having created it as per _:context acp:agent ex:Bob; acp:creator ex:Bob ..

It is up to the Solid server to keep record and send as part of the context this piece of information (who created the resource) to the authorization server.

See also: https://github.com/solid/specification/issues/315

bblfish commented 2 years ago

If I can start with just this point

ex:matcherA
    a acp:Matcher, acp:AgentMatcher ;
    acp:agent ex:Djamila, ex:CreatorAgent .

we have acp:agent that links a matcher in one case to a Person ex:Djamila and in another case to something completely different ex:CreatorAgent . I am told that acp:agent is

An agent trying to access a resource.

But that is not what ex:CreatorAgent is. That cannot refer to one and the same agent every time it is used. It can only refer to a description of an agent.

matthieubosquet commented 2 years ago

There was a typo in my example, apologies about that. The only one specific correct URI that refers to the agent who created the resource being queried over something is fixed by ACP: acp:CreatorAgent.

"An agent trying to access a resource."

That formulation is clumsy, thank you for pointing it out!

Here, the simplicity of using the acp:agent predicate to perform matching against the WebID that has been asserted as controlled (via an access token with a webid claim) seems correct to me.

Let's imagine for an instant that we introduce a second predicate, let's say acp:agentClass.

All this would enable is to let people match on both the specific WebID being asserted and qualities of the WebID in regard to the resource being queried.

For example:

ex:matcherA
    a acp:Matcher, acp:AgentMatcher, acp:AgentClassMatcher ;
    acp:agent ex:Djamila ;
    acp:agentClass acp:CreatorAgent .

Would only match if ex:Djamila is querying AND if she happens to also be the acp:creator.

I believe it is more useful and makes more sense to perform all forms of matching of the WebID asserted as controlled at once or at least to allow it.

That is, in the current form, it is easy to say I want to give access to ex:Djamila and to the acp:CreatorAgent. It would be more convoluted if we were to introduce a new predicate.

And if someone wanted to only allow access to Djamila if she is the Creator Agent, that would be perfectly possible via an acp:Policy using acp:allOf:

ex:isDjamilaCreatorAgentPolicy
  acp:allow acl:Read, acl:Write ;
  acp:allOf ex:matchDjamila, ex:matchCreatorAgent .

ex:matchDjamila acp:agent ex:Djamila .

ex:matchCreatorAgent  acp:agent acp:CreatorAgent .

That obviously is a matter of preference, I see your point (creating an agentClass matcher would simply mean using anyOf policies instead).

I do have to agree that from a purity point of view, we might think that mixing matching of agents and qualities of agents is bad. But I am not 100% certain what the best tradeoff is here. I think that the convenience of matching on one aspect of the request at once (the controlled WebID) might outweight the purity and does have beauty and sense in itself.

matthieubosquet commented 2 years ago

In the latest ACP Draft, the definition of acp:CreatorAgent has been clarified as such:

In a Matcher, agent attributes using the Creator Agent named individual MUST match Contexts where a defined creator matches the defined agent. — https://solid.github.io/authorization-panel/acp-specification/#matcher

The acp:creator Context attribute has been clarified as such:

The creator attribute describes creators of requested resources. — https://solid.github.io/authorization-panel/acp-specification/#context

It is substantiated by pseudocode for the satisfied matcher algorithm.

I will close this specific issue as the pseudocode shows a detailed example where this is used and the acp:creatorattribute and acp:CreatorAgent named individual definitions have been clarified.