HomeGuidesRecipesAPI ReferenceChangelog
Log In

Access Needs Example

Suggest Edits

Access Needs, as described by chapter 8 of the solid interoperability specification, describe access that is requested to data of a user, either by an Application that this user wants to use, or by a Social Agent (i.e. another person).

Planning ahead for the upcoming evolutions of the Solid specifications, in which the interoperability specification will play an important role, we will already use Access Needs to track which access has been granted to which Data Registrations in the period before the transition to newer versions of the specifications. From these Access Needs, we will be able to automatically generate Access Authorizations, Data Authorizations, Access Grants and Data Grants. To do so we will assume that all Access Needs up to the transition are implicitly accepted by the user. Since access control in the current evolution of the specifications is based on user identification, only the Access Needs for Social Agents need to be recorded; upon transition, access for applications will implicitly be granted to any of the client’s applications.

In the rest of this document, we will look into an example of the RDF data (in Turtle format) that describes the Access Needs for a Social Agent called Bob to the Projects of a Social Agent called Alice, and to the Tasks included therein. All code snippets together can be seen as a single Turtle file, that uses the following prefixes (the prefix ex: is used for examples of external URIs; examples of internal URIs have the format <#xyz>).

PREFIX interop: <http://www.w3.org/ns/solid/interop#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX acl: <http://www.w3.org/ns/auth/acl#>
PREFIX ex: <https://example.org/>

The registration of Access Needs starts with an Access Request pointing to both Social Agents and an Access Need Group.

<#example-access-request>
  a interop:AccessRequest ;
  interop:fromSocialAgent ex:webid-of-bob ;
  interop:toSocialAgent ex:webid-of-alice ;
  interop:hasAccessNeedGroup <#example-access-need-group> .

This Access Need Group contains some general information:

  • whether the access is required or optional;
  • whether the access is personal or can be shared further; and
  • whether when accessing the resources the requesting party must be authenticated as a Social Agent or as an Application

It points further to an Access Description Set, and to the Access Needs contained in the group.

<#example-access-need-group>
  a interop:AccessNeedGroup ;
  interop:accessNecessity interop:AccessRequired ;  # or interop:AccessOptional
  interop:accessScenario interop:PersonalAccess ;   # or interop:SharedAccess
  interop:authenticatesAs interop:SocialAgent ;     # or interop:Application
  interop:hasAccessDescriptionSet <#example-access-description-set-en> ;
  interop:hasAccessNeed <#example-access-need-project> ;
  interop:hasAccessNeed <#example-access-need-task> .

Access Needs point to the Shape Tree describing the data to which access is needed. They also tell

  • whether this specific access is required or optional;
  • which mode(s) of access are needed; and
  • which extra mode(s) of access are needed when it is the creator of the data accessing it.

Possible ACL access modes are Read, Write, Update, Create, Delete, and Append.

If nothing else is specified, the Access Need asks for access to all (existing and future) instances of that Shape Tree. Alternatively, a concrete instance can be specified, or a pointer to a parent Access Need can be provided, to limit the access to that specific instance or all instances included in the parent need according to its Shape Tree (e.g. all Tasks included in a Project).

<#example-access-need-project>
  a interop:AccessNeed ;
  interop:registeredShapeTree ex:url-of-project-tree ;
  interop:accessNecessity interop:accessRequired ; # or interop:AccessOptional
  interop:accessMode acl:Read, acl:Create ;
  interop:creatorAccessMode acl:Update, acl:Delete ;
  interop:hasDataInstance ex:\/url\/of\/instance . # only for specific instance

<#example-access-need-task>
  a interop:AccessNeed ;
  interop:registeredShapeTree ex:url-of-task-tree ;
  interop:accessNecessity interop:accessRequired ; # or interop:AccessOptional
  interop:accessMode acl:Read, acl:Create ;
  interop:creatorAccessMode acl:Update, acl:Delete ;
  interop:inheritsFromNeed <#example-access-need-project> . # only if inherited

In order to present Access Needs to the user for approval or for reference, Access Need Groups point to one or more Access Description Sets (one per language), consisting of Access Need Group Descriptions and Access Need Descriptions, which provide labels and a description for the Access Need Groups and Access Needs they point to.

<#example-access-description-set-en>
  a interop:AccessDescriptionSet ;
  interop:usesLanguage "en"^^xsd:language .

<#example-access-need-group-description-en>
  a interop:AccessNeedGroupDescription ;
  interop:inAccessDescriptionSet <#example-access-description-set-en> ;
  interop:hasAccessNeedGroup <#example-access-need-group> ;
  skos:prefLabel "Read and Contribute to Projects"@en ;
  skos:description "Allow Bob to read the Projects you select, and create new ones. Bob won't modify existing data, but can add more."@en .

<#example-access-need-description-project-en>
  a interop:AccessNeedDescription ;
  interop:inAccessDescriptionSet <#example-access-description-set-en> ;
  interop:hasAccessNeed <#example-access-need-project> ;
  skos:prefLabel "Access to Projects is essential for Bob to perform his core function of Project Management"@en .

<#example-access-need-description-task-en>
  a interop:AccessNeedDescription ;
  interop:inAccessDescriptionSet <#example-access-description-set-en> ;
  interop:hasAccessNeed <#example-access-need-task> ;
  skos:prefLabel "Access to Tasks allows Bob to identify and manage the work to be done in a given Project."@en .

Updated 6 months ago