7.2 Access Control

7.2.1 Direct ACP control via semantic graph store

7.2.1.1 Introduction

When realizing semantic functionalities and operations (e.g. semantic resource discovery or semantic query), a centralized Semantic Graph Store (SGS) can be used in the system to store RDF triples which are collected from the <semanticDescriptor> resources distributed in the resource tree. However, oneM2M uses <accessControlPolicy> resources to define Access Control Policies (ACP) and those resources are hosted in the resource tree and referred/used by other resources through accessControlPolicyIDs attribute. In other words, any resource accesses (e.g. CRUD or discovery) to a specific resource shall be compliant to certain access control policies as specified by the accessControlPolicyIDs attribute of this resource. Since <semanticDescriptor> resources have their own access control policies as defined in the accesscontrolPolicyIDs attribute, semantic operations to be executed directly on the RDF triples stored at the SGS shall follow those access control policies in the sense that RDF triples from certain <semanticDescriptor> resources shall not be used or involved in a semantic operation processing if it is not allowed by the corresponding access control policies.

Figure 7.2.1.1-1 gives an example of an access control policy for two <semanticDescriptor> resources, where there are two access control policies (i.e. <accessControlPolicy1> and <accessControlPolicy2> ). The access to <semanticDescriptor1> is controlled by <accessControlPolicy1> and <accessControlPolicy2> , while the access to <semanticDescriptor2> is only controlled by <accessControlPolicy2> .

Figure 7.2.1.1-1: Example of access control policy for <semanticDescriptor>

In direct ACP control via semantic graph store, access control for any semantic operation (e.g. semantic resource discovery, semantic query, etc.) shall be directly enforced in the SGS. For this purpose, the following types of semantic triples shall be generated according to the oneM2M resource tree (i.e. <semanticDescriptor> and <accessControlPolicy> resources) and added to the SGS before the semantic operation is executed at the SGS; in addition, those four types of semantic triples shall be synchronized with the oneM2M resource tree (i.e. changes on or related to <semanticDescriptor> and <accessControlPolicy> resources):

• SD Original Triples: RDF triples or other semantic representation contained in the descriptor attribute of a <semanticDescriptor> resource. In addition, the relationship between a <semanticDescriptor> resource and its accessControlPolicyIDs shall be represented in a semantic form and stored in the SGS.
• SD Relationship Triples: RDF triples or other semantic representation used to describe the belonging relationship between each SD Original Triple (i.e. contained in the descriptor attribute of a <semanticDescriptor> resource) and the corresponding <semanticDescriptor> resource.
• ACP-SD Binding Triples: RDF triples or other semantic representation used to describe which <accessControlPolicy> shall be applied to which <semanticDescriptor> (i.e. the binding relationship between a <semanticDescriptor> resource and its accessControlPolicyIDs attribute). For oneM2M, such binding relationship shall be obtained from the resource <semanticDescriptor> 's accessControlPolicyIDs attribute.
• ACP Triples: RDF triple or other semantic representation used to describe ACP policies/rules (as defined in <accessControlPolicy> resources) for semantic resources (e.g. <semanticDescriptor> ).

Overall, direct ACP control via the SGS shall consist of the following tasks:

• Task 1: Store SD Original Triples in the SGS. Generate SD Relationship Triples, store them in the SGS. This task is detailed in clause 7.2.1.2.
• Task 2: Generate ACP-SD Binding Triples and ACP Triples; store them in the SGS. This task is detailed in clause 7.2.1.3.
• Task 3 : Conduct semantic operations with direct ACP control in the SGS. Semantic operations are conducted with the selected semantic triples which are associated with the Access Control Rules allowing the Originator to operate (which is based on the work of Task 1 and Task 2). This task is detailed in clause 7.2.1.4.
• Task 4 : Synchronize ACP Triples, ACP-SD Binding Triples, SD Relationship Triples, and SD Original Triples as stored in the SGS with any updated <semanticDescriptor> and/or <accessControlPolicies> resources in the oneM2M resource tree. This task is detailed in clause 7.2.1.5.

7.2.1.2 Create SD relationship triples

Access control policies for a <semanticDescriptor> resource have been defined in its accesscontrolPolicyIDs attribute. In other words, the granularity for defining ACP is on a resource-level in the sense that all the RDF triples stored in the descriptor attribute of the <semanticDescriptor> resource should be compliant to the same ACP as specified by the accessControlPolicyIDs attribute of this <semanticDescriptor> resource. However, when those RDF triples (i.e. SD Original Triples) are copied to the SGS, they are not stored under any resource/attribute anymore which is different than the way oneM2M resource tree works. Therefore, a way is needed to re-represent the association relationship between a SD Original Triple and its <semanticDescriptor> resource in SGS in order to perform the same ACP enforcement directly in the SGS. In other words, SD Relationship Triples shall be generated and stored in the SGS.

In order to do so, an internal ontology (referred to as Semantic Descriptor Ontology) with two classes semanticDescriptor and atomDescription, and several properties describedIn , hasSubject hasObject and hasProperty shall be used (see Figure 7.2.1.2-1). Note that the class semanticDescriptor is the concept to model a <semanticDescriptor> resource, while atomDescription is used to model a SD Original Triple; the atomDescription has four properties describedIn , hasSubject, hasObject and hasProperty . For example, for a triple like "classX propertyY classZ " stored in a <semanticDescriptor> resource (which is termed as SD Original Triple), the following association triples shall be created for building the association and stored in the SGS; those association triples are termed as SD Relationship Triples.

atomDescriptionA   hasSubject     classX
atomDescriptionA   hasObject      classZ
atomDescriptionA   hasproperty    propertyY
atomDescriptionA   describedIn    semanticDescriptorA

Figure 7.2.1.2-1: Association between a SD original triple and the semanticDescriptor instance

An illustration of such a process is shown in Figure 7.2.1.2-1. As an example, consider a <semanticDescriptor> resource called <SD-1>, which include 4 SD Original Triples:

HomeA       rdf:type         ex:Home.
HomeA       ex:hasLocation   LocationA.
LocationA   ex:hasLatitude   "300".
LocationA   ex:hasLongitude  "200".

When those four SD Original Triple are copied to SGS, the following SD Relationship Triple shall be shall be generated:

@PREFIX            sd:              <http://semanticDescriptor.org>.
atomDescription1   rdf:type         sd:atomDescription.
<SD-1>             rdf:type         sd:semanticDescriptor.
atomDescription1   sd:hasSubject    HomeA.
atomDescription1   sd:hasObject     ex:Home.
atomDescription1   sdhasProperty    rdf:type.
atomDescription1   sd:describedIn   <SD-1>.
atomDescription2   sd:hasSubject    HomeA.
atomDescription2   sd:hasObject     LocationA.
atomDescription2   sd:hasProperty   ex:hasLocation.
atomDescription2   sd:describedIn   <SD-1>.
atomDescription3   sd:hasSubject    LocationA.
atomDescription3   sd:hasObject     "300".
atomDescription3   sd:hasProperty   ex:Latitude.
atomDescription3   sd:describedIn   <SD-1>.
atomDescription4   sd:hasSubject    LocationA.
atomDescription4   sd:hasObject     "200".
atomDescription4   sd:hasProperty   ex:hasLongtitude.
atomDescription4   sd:describedIn   <SD-1>.

7.2.1.3 Create ACP triples and ACP binding triples

7.2.1.3.1 Access Control Ontology

In order to represent an ACP in a semantic form, the Access Control Ontology is introduced, which is shown in Figure 7.2.1.3.1-1. This ontology is defined by following how an oneM2M <accessControlPolicy> resource is specified in oneM2M TS-0001 [1], where an access-control-rule-tuple consists of parameters such as accessControlOriginators, accessControlOperations, and accessControlContexts. Accordingly, this ontology defines two new classes:

• accessControlPolicy; and
• accessControlRule.

In addition, five new properties (i.e. hasACPRule, hasACOriginator, hasACOperations, hasACContexts and appliedTo) are defined. More details about those terms are introduced as follows:

• The property hasACPRule is used to link an accessControlPolicy instance with an accessControlRule instance. Properties hasACOriginator, hasACOperations and hasACContexts (optional) basically describe an accessControlRule instance and are used to specify who shall issue what operations under which conditions. As these triples describe the ACP themselves, they are referred to as ACP Triples.
• The property appliedTo is used to describe which <semanticDescriptor> resource an accessControlPolicy instance shall be applied to. As these triples bind <accessControlPolicy> and <semanticDescriptor>, they are referred to as ACP-SD Binding Triples.

Figure 7.2.1.3.1-1: Access control ontology model

7.2.1.3.2 Example of Using Access Control Ontology

Figure 7.2.1.3.2-1 shows an example of the eHealth Ontology Reference Model, which will be used to develop the SGS example in Figure 7.2.1.3.2-2.

Figure 7.2.1.3.2-1: eHealth ontology reference model

Figure 7.2.1.3.2-2 describes an example of ACP Triples and ACP-SD Binding Triples in the SGS, based on the <semanticDescriptor> resource example shown in Figure 7.2.1.1-1 and the Access Control Ontology defined in Figure 7.2.1.3.1-1. In this example, there are two patients Jack and Alice; their doctors are John and Steve, respectively. There are three blood pressure meansurement samples (i.e. Sample1 for Jack, Sample2 and Sample3 for another patient3). Corresponding triples are shown in black text in Figure 7.2.1.3.2-2, which are generated based on the eHealth Ontology Reference Model in Figure 7.2.1.3.2-1.

The triples in red text in Figure 7.2.1.3.2-2 are added for access control purpose according to the proposed Access Control Ontology model in Figure 7.2.1.3.1-1, when new ACPs are created or updated. In this example, it is assumed two access control polices be created. First, two <semanticDescriptor> resources are described (i.e. semanticDescriptor1 contains Sample1 and Sample2, while semanticDescriptor2 contains Sample3. Then, two access control policies are defined (i.e. accessControlPolicy1 is applied to semanticDescriptor1, while accessControlPolicy2 is applied to both semanticDescriptor1 and semanticDescriptor2). Next, the detailed Access Control Rules for accessControlPolicy1 and accessControlPolicy2 are described:

• accessControlPolicy1 has two accessControlRules, which states that 1) AE-ID-1, AE-ID-2, and AE-ID-3 can RETRIEVE and DISCOVER triples in the semanticDescriptor which accessControlPolicy1 is applied to (i.e. semanticDescriptor1); 2) AE-ID-1 and AE-ID-3 can CREATE, UPDATE, or DELETE triples in the semanticDescriptor which accessControlPolicy1 is applied to (i.e. semanticDescriptor1).
• For accessControlPolicy2, only one accessControlRule is defined; this accessControlRule states that AE-ID-1 and AE-ID-2 can DISCOVER triples in the semanticDescriptor which accessControlPolicy2 is applied to (i.e. semanticDescriptor1 and semanticDescriptor2).

Figure 7.2.1.3.2-2: eHealth triples in the SGS

7.2.1.4 Conduct semantic operations with direct ACP control

This clause is to introduce more details on implementing Task-3 as discussed in clause 7.2.1.1. This clause uses semantic query as an example of semantic operatoins to be excuted with direct ACP control in the SGS.

When the Hosting CSE receives a SPARQL query from the Originator, it shall:

1. add the access control related patterns according to the ID of the Originator and the request operation to be conducted (e.g. semantic discovery) into the received SPARQL statement;
2. add ACP-SD binding related patterns into the received SPARQL statement (i.e. constraints on ACP-SD Binding Triples). For each triple pattern contained in the original SPARQL query statement, a new ACP-SD binding triple pattern shall be added;
3. add SD relationship related patterns (i.e. constraints on SD Relationship Triples) to the received SPARQL statement. For each triple in the original SPARQL query statement, four new triple patterns shall be added to describe the SD relationship; and
4. execute the revised SPARQL statement to make query on the SGS.

For example, in the scenario of the example in Figure 7.2.1.3.2-2, when AE-ID-3 sends the following SPARQL query request to the Hosting CSE:

select distinct ?sample ?sValue ?dValue
where
{  
  ?sample      rdf:type      ex:BPMeasurementSample .
  ?sample      ex:sValue      ?sValue .
  ?sample      ex:dValue      ?dValue .
}

The Hosting CSE shall add some access control related statements according to the ID (i.e. AE-ID-3) of the Originator and the request operation (i.e. DISCOVERY) of the query, the revised SPARQL query is given as below (red text for ACP constraints, blue text for ACP-SD binding constraints, and orange text for SD relationship constraints):

select distinct ?sample ?sValue ?dValue
where
{ 
  ?accessControlRule    acp:hasACOriginator  "AE-ID-3" .              #---
  ?accessControlRule    acp:hasACOperations  "DISCOVERY" .            #  |---> ACP Triples
  ?accessControlPolicy  acp:hasACPRule       ?accessControlRule .     #---

  ?accessControlPolicy  acp:appliedTo        ?semanticDescriptor1 .   #---
  ?accessControlPolicy  acp:appliedTo        ?semanticDescriptor2 .   #  |---> ACP-SD Binding Triples
  ?accessControlPolicy  acp:appliedTo        ?semanticDescriptor3 .   #---

  ?atomDescription1     sd:describedIn       ?semanticDescriptor1 .   #---
  ?atomDescription1     sd:hasSubject        ?sample .                #  |
  ?atomDescription1     sd:hasObject         ex:BPMeasurementSample . #  |
  ?atomDescription1     sd:hasProperty       rdf:type .               #  |
  ?atomDescription2     sd:describedIn       ?semanticDescriptor2 .   #  |
  ?atomDescription2     sd:hasSubject        ?sample .                #  |---> SD Relationship Triples
  ?atomDescription2     sd:hasObject         ?sValue .                #  |
  ?atomDescription2     sd:hasProperty       ex:sValue .              #  |
  ?atomDescription3     sd:describedIn       ?semanticDescriptor3 .   #  |
  ?atomDescription3     sd:hasSubject        ?sample .                #  |
  ?atomDescription3     sd:hasObject         ?dValue .                #  |
  ?atomDescription3     sd:hasProperty       ex:dValue .              #---    
  ?sample               rdf:type             ex:BPMeasurementSample .
  ?sample               ex:sValue            ?sValue .
  ?sample               ex:dValue            ?dValue .
}

Next, the revised SPARQL query statement is excuted within the SGS. Since ACP have already been reprensented in a semantical form, the query result of the revised SPARQL query is the desried result with enforced direct acceess control. Figure 7.2.1.4-1 shows the SPARQL query result in the above example over the eHealth SGS in Figure 7.2.1.3.2-2. According to the access control triples added to the SGS (i.e. red text in Figure 7.2.1.3.2-2), AE-ID-3 is only allowed to DISCOVER samples included in semanticDescriptor1 (i.e. Sample1 and Sample2). As a result, the returned result for SPARQL query in Figure 7.2.1.4-1 presents the selected content of Sample1 and Sample2.

Figure 7.2.1.4-1: Example for eHealth semantic query result with access control

7.2.1.5 Synchronization ACP triples and SD-related triples in the SGS with the resource tree

7.2.1.5.1 Introduction

When making ACP policies/rules be also available in a semantical form (i.e. ACP Triples) in the SGS for supporting direct access control, synchronization between <accessControlPolicy> resources at the Hosting CSE and ACP Triples at the SGS is required. Depending on different cases, the Hosting CSE shall perform the following tasks in order to maintain such synchronization:

• When a new <accessControlPolicy> resource is created, the Hosting CSE shall generate new ACP Triples according to the ACP ontology and stores these new ACP Triples in the SGS (see clause 7.2.1.5.2).
• When the privileges attribute of an existing <accessControlPolicy> resource is updated, the Hosting CSE shall generate new ACP Triples and update corresponding old ACP Triples at the SGS accordingly (see clause 7.2.1.5.3).
• When an existing <accessControlPolicy> resource is deleted, the Hosting CSE shall remove the corresponding ACP Triples at the SGS (see clause 7.2.1.5.4).

Similar to ACP Triples, others such as SD Original Triples, SD Relationship Triples, and ACP-SD Binding Triples shall be synchronized. Depending on different cases, the Hosting CSE shall perform the following tasks in order to maintain such synchronization:

• When a <semanticDescriptor> is created:
  • In this case, the Hosting CSE shall generate SD Relationship Triples and ACP-SD Binding Triples and then store them in the SGS (see clause 7.2.1.5.5).
• When the accessControlPolicyIDs attribute of a <semanticDescriptor> resource changes:
  • In this case, the Hosting CSE shall generate new ACP-SD Binding Triples and use them to update corresponding old ACP-SD Binding Triples in the SGS. This case may apply also when the accessControlPolicyIDs attribute of the parent changes (see clause 7.2.1.5.6).
• When the descriptor attribute of a <semanticDescriptor> resource changes:
  • In this case, the Hosting CSE shall generate new SD Relationship Triples and use them to update old SD Relationship Triples in the SGS (see clause 7.2.1.5.7).
• When a <semanticDescriptor> resource is deleted:
  • In this case, the Hosting CSE shall delete all corresponding SD Original Triples, SD Relationship Triples and ACP-SD Binding Triples from the SGS (see clause 7.2.1.5.8).

7.2.1.5.2 Procedure for creating ACP triples when a new <accessControlPolicy> resource is created

Figure 7.2.1.5.2-1 illustrates the procedure for creating ACP Triples in SGS, which is triggered when an Originator requests to create a new <accessControlPolicy> resource at the Hosting CSE.

The following steps shall be performed:

• Step 1: The Originator sends a request to create a new <accessControlPolicy> resource to the Hosting CSE. This message contains the representation of <accessControlPolicy> to be created (e.g. the value of privileges attribute).
• Step 2: The Hosting CSE receives the request in Step 1 and, subject to the Originator access rights verification, shall create the requested <accessControlPolicy> resource.

Note

EXAMPLE 1: Assume <acp1> be the newly created ACP resource and its URI "acp1URI". Assuming <acp1> has one access control rule (e.g. acr11) and the URI of the corresponding privileges attribute is "acr11URI". For exemplification, assume also that acr11 allows an AE ("AE-ID-1") to perform DISCOVERY operations.

• Step 3: The Hosting CSE sends a response to the Originator.

Note

EXAMPLE 2: If Step 1 was successful, "acp1URI" will be contained in this response message.

• Step 4: The Hosting CSE generates corresponding ACP Triples based on the content of <acp1> and the ACP ontology.

Note

EXAMPLE 3: An example of ACP Triples for <acp1> resource created in Step 1 is illustrated in Figure 7.2.1.5.2-2.

• In Figure 7.2.1.5.2-2:
  • line#1 defines prefix "acp" which will used in lines #2-#6.
  • line#2 defines a new acp:accessControlPolicy class instance for <acp1> resource. The subject value of this triple (i.e. acp:acp1) is "acp1URI", therefore the subject value of this triple makes it possible to locate the corresponding resource <acp1>. The Hosting CSE shall also use "acp1URI" to locate corresponding triples in the SGS (e.g. when updating existing ACP Triples).
  • line#3 defines that acp:acp1 instance has an associated access control rule acr11. The object value of this triple (i.e. acp:acr11) is "acr11URI", therefore the object value of this triple, makes it possible to locate the corresponding privileges attribute of <acp1> resource. The Hosting CSE shall use "acr11URI" to locate the corresponding triples in the SGS (e.g. when updating existing ACP Triples).
  • line#4 defines that acp:acr11 (i.e. the object on line#3) is an acp:accessControlRule class instance.
  • line#5 and line#6 give the values of two properties of acp:acr11 based on the assumptions in this example.

Note

The triples on lines #4-#6 define the access control rule acr11. If <acp1> has more access control rules, additional access control rules will be defined similarly to those on lines #4-#6.

• Optionally: The Hosting CSE may add the address of the SGS to the <accessControlPolicy> resource created in Step 2 in a new attribute, to enable direct addressing of the triples.

• Step 5: The Hosting CSE sends a SPARQL request to store the ACP Triples created in Step 4 to the selected SGS.

Note

EXAMPLE 4: The ACP Triples shown in Figure 7.2.1.5.2-2 will be contained in the SPARQL request.

• Step 6: The SGS receives the SPARQL request, processes it and saves the ACP Triples into its graph store.
• Step 7: The SGS sends a response back to the Hosting CSE to confirm the request in Step 6 is successfully executed.

Editor's Note: Replace with PlantUML Diagram

Editor's Note: This seems to be the wrong diagram. It is the same as Figure 7.2.1.5.3-1. It is already the wrong diagram in R3 of the spec.

Figure 7.2.1.5.2-1: Procedure for creating ACP triples in the SGS

Figure 7.2.1.5.2-2: Example ACP triples corresponding to <acp1> resource

7.2.1.5.3 Procedure for updating ACP triples when an existing <accessControlPolicy> resource is updated

The procedure for updating ACP Triples in a SGS follows a similar flow to the procedure used when a new <accessControlPolicy> resource is created. In this case the Originator requests to update the privileges attribute of an existing <accessControlPolicy> resource, as shown in Figure 7.2.1.5.3-1.

Note

This procedure applies also for updates of the accessControlPolicyIDs attribute of the <semanticDecriptor> resource.

The following steps shall be performed:

• Steps 1 - 3: Similar to those describing Figure 7.2.1.5.2-1, but reflecting normal processing of an UPDATE operation. In this case the Originator triggers an update of the privileges attribute of an existing <accessControlPolicy> .
• Step 4: Based on the new value of the privileges attribute the Hosting CSE generates new ACP Triples

Note

EXAMPLE 1: Assume the Originator aims to update the privileges attribute of <acp1> resource from "DISCOVERY" to "DISCOVERY" and "RETRIEVE" as the new accessControlOperations . To implement these changes in Figure 7.2.1.5.2-2 the Hosting CSE can simply add a new triple e.g. acp:acr11 acp:hasACOperations "RETRIEVE". Alternatively, the Hosting CSE can replace the triple on Line#6 to the new triple acp:acr11 acp:hasACOperations "DISCOVERY", "RETRIEVE".

• Step 5: The Hosting CSE sends a SPARQL request to the SGS to update existing ACP Triples related to <acp1> resource to reflect the update being requested:

Note

EXAMPLE 2: As described in Step 4, there are two options to implement this. - The Hosting CSE adds a new triple with the following SPARQL request: ```sparql

@PREFIX acp: http://accessControlPolicy.org. INSERT DATA

Note

- The Hosting CSE replaces Line#6 in Figure 7.2.1.5.1-2 with the SPARQL request:sparql

@PREFIX acp: http://accessControlPolicy.org. DELETE {?acr acp:hasACOperations ?operation } WHERE { ?acr acp:hasACOperations ?operation FILTER (?acr=acp:acr11) } INSERT DATA

Note

```

• Step 6: The SGS processes the received SPARQL request and updates the corresponding ACP Triples.
• Step 7: The SGS sends a response to the Hosting CSE to inform it whether the request has successfully executed.

Figure 7.2.1.5.3-1: Procedure for updating ACP triples in SGS

Editor's Note: Replace with PlantUML Diagram

7.2.1.5.4 Procedure for deleting ACP triples when an existing <accessControlPolicy> resource is deleted

The procedure for deleting ACP Triples in a SGS follows a similar flow to the procedure used when a new <accessControlPolicy> resource is created. In this case, the Originator requests to delete an existing <accessControlPolicy> resource, as shown in Figure 7.2.1.5.4-1.

The following steps shall be performed:

• Steps 1 - 3: Similar to those describing Figure 7.2.1.5.2-1, but reflecting normal processing of a DELETE operation. In this case the Originator triggers the deletion of an existing <accessControlPolicy> resource.
• Step 4: The Hosting CSE shall send a SPARQL request to the SGS to delete existing ACP Triples

Note

EXAMPLE: The following SPARQL request implements this request: ```sparql

@#PREFIX acp: http://accessControlPolicy.org. DELETE { ?acp ?p ?o ?s ?p2 ?acp ?acr ?p1 ?o1 } WHERE { ?acp ?p ?o ?s ?p2 ?acp ?acp acp:hasACPRule ?acr ?acr ?p1 ?o1 FILTER (?acp=acp:acp1) }

Note

```

• Step 5: The SGS processes the received SPARQL request and removes all requested ACP Triples.
• Step 6: The SGS sends a response to the Hosting CSE to inform it whether the request was successfully executed.

Figure 7.2.1.5.4-1: Procedure for Deleting ACP Triples in the SGS

Editor's Note: Replace with PlantUML Diagram

7.2.1.5.5 Procedure for creating ACP-SD binding triples and SD relationship triples in SGS

Figure 7.2.1.5.5-1 illustrates the procedure for creating ACP-SD Binding Triples and SD Relationship Triples in SGS, which shall be triggered when an Originator requests to create a new <semanticDescriptor> resource.

After checking the access rights and other related security functions, the Hosting CSE shall create the <semanticDescriptor> resource locally (referred to as sd1 and its URI assumed to be sd1URI). Then, the Hosting CSE shall store all semantic triples as described in the descriptor attribute of SD1 resource to the SGS. More importantly, the Hosting CSE shall generate new SD Relationship Triples and ACP-SD Binding Triples and shall store them to the SGS as well. Note that if sd1 has no accessControlPolicyIDs attribute, ACP-SD Binding Triples shall not be generated.

The following steps shall be performed:

• Step 1: The Originator sends Create _<semanticDescriptor>_ Resource request to the Hosting CSE. It is assumed that the value of descriptor attribute and accessControlPolicyIDs attribute of <semanticDescriptor> resource will be given in this request message:
  • Assume the descriptor attribute contains only one SD Original Triple "S1 P1 O1".
  • Assume the value of accessControlPolicyIDs is "acp1URI", i.e. the access control policy acp1 will be applied.
• Step 2: The Hosting CSE accordingly creates the <semanticDescriptor> resource (referred to as sd1):
  • Assume its URI is sd1URI.
• Step 3: The Hosting CSE sends a response to Originator to inform it if Step 2 is successfully completed.
• Step 4: Bases don the SD Original Triple contained in the descriptor attribute of sd1, the Hosting CSE generates SD Relationship Triples.
  • In our example, there is only one SD Original Triple, as shown below:

Note

```rdf

@PREFIX                 sd:               <http://semanticDescriptor.org>.
sd:sd1                  rdf:type          sd:semanticDescriptor.
sd:tripleInstance11     rdf:type          sd:atomDescription
sd:tripleInstance11     sd:describedIn    sd:sd1
sd:tripleInstnace11     sd:hasSubject     sd:S1.
sd:tripleInstnace11     sd:hasProperty    sd:P1.
sd:tripleInstnace11     sd:hasObject      sd:O1.

Note

```

• Step 5: The Hosting CSE will generate the ACP-SD Binding Triples:
  • In our example, since sd1's accessControlPolicyIDs attribute points to acp1 resource as shown below:

Note

```rdf

@PREFIX                 sd:               <http://semanticDescriptor.org>.
@PREFIX                 acp:              <http://accessControlPolicy.org>.
acp:acp1                rdf:type          acp:accessControlPolicy.
sd:sd1                  rdf:type          sd:semanticDescriptor.
acp:acp1                acp:appliedTo     sd:sd1.

Note

```

• Step 6: The Hosting CSE sends a SPARQL request to the SGS to store these SD Relationship Triples and ACP-SD Binding Triples to the SGS.
• Step 7: The SGS processes the SPARQL request and store corresponding SD Relationship Triples and ACP-SD Binding Triples in the SGS.
• Step 8: The SGS sends a response message to the Hosting CSE to inform it if the SPARQL request in Step 6 is successfully executed.

Note

If the <semanticDescriptor> resource being created in Step 2 does not have accessControlPolicyIDs attribute, the accessControlPolicyIDs attribute of the parent resource may be used or system default access privileges may be applied. The new ACP-SD Binding Triples will also be generated using either the parent resource's accessControlPolicyIDs attribute or based on the default privileges.

Figure 7.2.1.5.5-1: Procedure for creating SD relationship triples and ACP-SD binding triples

Editor's Note: Replace with PlantUML Diagram

7.2.1.5.6 Procedure for updating ACP-SD binding triples in SGS

Figure 7.2.1.5.6-1 shows the procedure for updating ACP-SD Binding Triples when the accessControlPolicyIDs attribute of a <semanticDescriptor> resource is updated. For example, assume the sd1 resource created earlier have its accessControlPolicyIDs changed from acp1 to acp2; with the ACP Triples for the resource acp2 as follows:

@PREFIX        acp:                    <http://accessControlPolicy.org>.
acp:acp2       rdf:type                acp:accessControlPolicy.
acp:acp2       acp:hasACPRule          acp:acr21.
acp:acr21      rdf:type                acp:accessControlRule.
acp:acr21      acp:hasACOriginator     "AE-ID-2".
acp:acr21      acp:hasACOperations     "RETRIEVE".

The following steps shall be performed:

• Step 1: The Originator sends a request to update the resource sd1's accessControlPolicyIDs from the URI of the resource acp1 to the URI of the resource acp2. The URI of the resource acp2 (i.e. acp2URI) is contained in this request. The URI of the resource sd1 (i.e. sd1URI) is also contained in this request.
• Step 2: The Hosting CSE checks access rights. If it is allowed, the Hosting CSE updates sd1's accessControlPolicyIDs with acp2's URI given in Step 1.
• Step 3: The Hosting CSE sends a response back to the Originator to inform it if the request in Step 1 is successful or not.
• Step 4: Since the sd1's accessControlPolicyIDs is changed, the Hosting CSE generates a new ACP-SD Binding Triple ("acp:acp2 acp:appliedTo sd:sd1") to reflect this change. This new ACP-SD Binding Triple will replace the old ACP-SD Binding Triple (i.e. acp:acp1 acp:appliedTo sd:sd1):

  (new ACP-SD Binding Triple) acp:acp2    acp:appliedTo     sd:sd1
  (old ACP-SD Binding Triple) acp:acp1    acp:appliedTo     sd:sd1
  

• Step 5: The Hosting CSE sends an SPARQL request to replace the old ACP-SD Binding Triple in the SGS with the new ACP-SD Binding Triple as shown in above Step 4. This SPARQL request for this example is shown below:

  @PREFIX      acp:            <http://accessControlPolicy.org>.
  @PREFIX      sd:             <http:semanticDescriptor.org>.
  DELETE
  { ?acp       acp:appliedTo   sd:sd1 }
  WHERE
  {
      ?acp     acp:appliedTo   sd:sd1
  }
  INSERT DATA
  { acp:acp2   acp:appliedTo   sd:sd1 . }
  

• Step 6: The SGS processes the SPARQL request and updates the specified ACP-SD Binding Triples in Step 5.
• Step 7: The SGS sends a response to the Hosting CSE to inform it if the SPARQL request in Step 5 is successfully performed.

Note

If the accessControlPolicyIDs attribute of the <semanticDescriptor> resource was empty to start with, its parent resource's accessControlPolicyIDs may be enforced. The hosting CSE will apply this step based on updates to the accessControlPolicyIDs attribute of the parent resource.

Figure 7.2.1.5.6-1: Procedure for updating ACP-SD binding triples in the SGS

Editor's Note: Replace with PlantUML Diagram

7.2.1.5.7 Procedure for updating SD relationship triples in SGS

Figure 7.2.1.5.7-1 shows the procedure for updating SD Relationship Triples when the descriptor attribute of a <semanticDescriptor> resource is changed. For example, the descriptor of the sd1 resource created earlier is changed to have two SD Original Triples (Old one - S1 P1 O1; New one - S2 P2 O2).

The following steps shall be performed:

• Step 1: The Originator sends a request to update the resource sd1's descriptor to include one new SD Original Triple (i.e. S2 P2 O2). The URI of the resource sd1 (i.e. sd1URI) is also contained in this request.
• Step 2: The Hosting CSE checks access rights. If it is allowed, the Hosting CSE updates sd1's descriptor attribute by adding one new SD Original Triple (i.e. S2 P2 O2).
• Step 3: The Hosting CSE sends a response back to the Originator to inform it if the request in Step 1 is successful or not.

• Step 4: The Hosting CSE generates new SD Relationship Triples below to reflect this change:

  • In our example:

    sd:tripleInstance12     rdf:type          sd:atomDescription.
    sd:tripleInstance12     sd:describedIn    sd:sd1
    sd:tripleInstance12     sd:hasSubject     sd:S2.
    sd:tripleInstance12     sd:hasProperty    sd:P2.
    sd:tripleInstance12     sd:hasObject      sd:O2.
    

• Step 5: The Hosting CSE sends an SPARQL request to replace old SD Relationship Triples and/or add new SD Relationship Triple in the SGS with the new SD Relationship Triple generated in above Step 4. This SPARQL request for this example is shown below:

  @PREFIX   acp:     <http://accessControlPolicy.org>.
  @PREFIX     sd:    <http://semanticDescriptor.org>.
  
  INSERT DATA
  {
      sd:tripleInstance12      rdf:type          sd:atomDescription.
      sd:tripleInstance12      sd:describedIn    sd:sd1 . 
      sd:tripleInstance12      sd:hasSubject     sd:S2 .
      sd:tripleInstance12      sd:hasProperty    sd:P2 .
      sd:tripleInstance12      sd:hasObject      sd:O2 .
  }
  

• Step 6: The SGS processes the SPARQL request and adds new SD Relationship Triples.
• Step 7: The SGS sends a response to the Hosting CSE to inform it if the SPARQL request in Step 5 is successfully performed.

Note

If an old SD Original Triple is removed or updated by a new SD Original Triple, the corresponding SD Relationship Triples related to this old SD Original Triple will be removed from the SGS.

The update of triples in the descriptor attribute may be performed also by targeting the semanticOpExec attribute of the <semanticDescriptor> parent resource with a SPARQL query; when this SPARQL query is executed, new SD Original Triples may be added to the descriptor attribute of the <semanticDescriptor> resource. In this case Steps 4 - 7 will be performed. More specifically, SPARQL Update consists of DELETE and ADD operations, so the SD relationship triples associated with the old original triples will be deleted, and the new ones stored.

Figure 7.2.1.5.7-1: Procedure for updating SD relationship triples in the SGS

Editor's Note: Replace with PlantUML Diagram

7.2.1.5.8 Procedure for deleting SD relationship triples and ACP-SD binding triples in SGS

Figure 7.2.1.5.8-1 shows a procedure for deleting SD Relationship Triples and ACP-SD Binding Triples from the SGS, which could be triggered by the Initiating AE/CSE or the Hosting CSE to delete a <semanticDescriptor> resource. For example, the sd1 resource created earlier is removed.

The following steps shall be performed.

• Step 1: The Originator sends "Delete <semanticDescriptor> Resource" to the Hosting CSE to delete sd1 resource. The URI of sd1 resource (i.e. sd1URI) is contained in this request.
• Step 2: The Hosting CSE deletes sd1 resource locally.
• Step 3: The Hosting CSE sends a response to the Originator to inform it if the deletion request in Step 1 is successful.
• Step 4: The Hosting CSE sends an SPARQL request to the SGS to remove SD Relationship Triples and ACP-SD Binding Triples related to sd1 resource. The SPARQL will look like:

  @PREFIX        acp:                 <http://accessControlPolicy.org>.
  @PREFIX        sd:                 <http:semanticDescriptor.org>.
  
  DELETE
  { 
      ?sd                ?p               ?o
      ?tripleInstance    ?p1              ?o1
      ?acp               acp:AppliedTo    ?sd
  }
  
  WHERE
  {
      ?sd                ?p               ?o.
      ?tripleInstance    ?p1              ?o1.
      ?tripleInstance    sd:describedIn   ?sd.
      ?acp               acp:AppliedTo    ?sd
      FILTER ( ?sd = sd:sd1)
  }
  

• Step 5: The SGS processes the SPARQL request in Step 4 and removes corresponding SD Relationship Triples and ACP-SD Binding Triples.
• Step 6: The SGS sends a response to the Hosting CSE to inform it if the SPARQL request in Step 4 is successfully performed.

Note

Steps 4 - 6 will also be performed if a SPARQL query targeting the semanticOpExec attribute of a <semanticDescriptor> resource results in the deletion of existing SD Original Triples.

Figure 7.2.1.5.8-1: Procedure for deleting SD relationship triples and ACP-SD binding triples from the SGS

Editor's Note: Replace with PlantUML Diagram