search

solid / authorization-panel

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

Draft specification proposal for ACP #183

Closed justinwb closed 3 years ago

justinwb commented 3 years ago

First draft of the ACP Specification proposal.

matthieubosquet commented 3 years ago

Preview document at: https://solid.github.io/authorization-panel/acp-specification/

matthieubosquet commented 3 years ago

The proposal is missing the bibliography section and I want to add a primer. But I think it is ready for review in its current form.

It can be conveniently previewed at: https://htmlpreview.github.io/?https://github.com/solid/authorization-panel/blob/initial-acp-spec/proposals/acp-specification/index.html

langsamu commented 3 years ago

Summary

Don't reuse acp:resource. Create a distinct property to link an access control resource to the resource it controls.

Background

2.2. Context attributes defines the acp:resource property as

[a] resource subjected to ACP access control.

acp:resource is a rdfs:subPropertyOf acp:attribute, which in turn has rdfs:domain of acp:Context.

This means any resource that is the subject of a statement with the predicate acp:resource is a acp:Context.

In other words:

CONSTRUCT {
    ?s a acp:Context .
}
WHERE {
    ?s acp:resource ?o .
}

acp:resource is also used in 3.1. Access control resource to create a link

between the access control resource and the resource it mandates access over.

Because of the axioms above, this means that every access control resource ends up being an instance of acp:Context.

Taking the example from 3.1:

ex:accessControlResourceA
    a acp:AccessControlResource ;
    acp:resource ex:resourceX .

This would imply:

ex:accessControlResourceA a acp:Context .

This does not seem intentional. An ACP Access control resource is wholly distinct from an ACP Context.

Proposal 1

I propose to separate these two properties, namely

In my opinion there is a practical reason to separate them in addition to the logical one. Any software making use of these properties (for example by mapping them to programmatic constructs) would suffer from the ambiguity. If the same property is used in two ways then any parsing of statements with this predicate will need to be context-aware to decide which usage is intended. If there were two distinct properties instead, then parsing would be unambiguous.

Proposal 2

I further propose that the following colloquial statement in 6.1 Resource management is made concrete:

There is a one to one relationship between an access control resource and the resource it mandates access permissions over.

This should be echoed ontologically such that acp:resource (the property linking an access control resource to the resouce being controlled) is functional and inverse functional:

acp:resource
    a owl:FunctionalProperty ;
    a owl:InverseFunctionalProperty ;
.

This would mean that

This is practically equivalent to a one-to-one 'cardinality restriction'.

In this case the following:

ex:acr1
    acp:resource
        ex:resource1 ,
        ex:resource2 .

would imply:

ex:resource1 owl:sameAs ex:resource2 .

while these statements:

ex:acr1 acp:resource ex:resource1 .
ex:acr2 acp:resource ex:resource1 .

would imply:

ex:acr1 owl:sameAs ex:acr2 .

Suggestion

Perhaps the properties could be defined as

  1. acp:target for linking a context to the resource it's about,
  2. acp:resource for linking an access control resource to the resource it controls and
  3. acp:accessControlResource for linking a resource to the access control resource that controls access to it (inverse of 2 above).
matthieubosquet commented 3 years ago

Thank you @TallTed for the review!

I applied some of your suggestions in: