[Manageable Affordances TF] Context-Based Authorized Access to Thing Affordances

[asorici]

Title: Context-Based Authorized Access to Thing Affordances

Submitter(s): Alexandru Sorici

Motivation:

Current ThingDescription specifications provide for Security Schemes which can control access to the affordances provided by a Thing. However, the current options are mostly limited to token-based access which are less responsive to the possible dynamics of web agents (e.g. in terms of physical mobility, change of roles in an activity, change of role in an organization). Attribute-Based Access Control methods seem a more appropriate approach for authorization granting/revocation, since they condition the access on properties of both an agent (human user or software agent) and Thing, which can change at runtime. Notably, the different properties and events known about agents and Things in a hypermedia platform can be qualified as context information. This context information is generated by the participants in the hypermedia platform itself (web services, software agents, human users, IoT devices, etc). Developers of Things should therefore be able to leverage such information to condition access to the Thing itself (as a resource) or to its individual affordances, when deploying them in different hypermedia platforms.

Expected Participating Entities:

• Things in a hypermedia platform as authorized entities
• Human or software agents as entities to which an access authorization is granted
• Web Services and other Things in the hypermedia platform as providers of information qualified as context

Workflow:

A human or software agent accesses an affordance provided by a Thing. The request is intercepted by the hypermedia agent platform in which the Thing is deployed. The Thing has specified a set of context conditions which a requester agent must satisfy for access. The conditions involve both static and dynamic (rapidly changing) information (e.g. the physical location of the requesting agent) context which are provided by other services and Things available in the hypermedia platform. The hypermedia platform provides a service to validate the context-based access conditions on behalf of the Thing and forwards the request for the affordance only if the access conditions are valid.

A more detailed description of envisioned interactions is provided in this short paper written in a technical report style, whereby an assumption is made that the hypermedia platform conforms to design principles and uses elements stemming from the Agents and Artifacts paradigm.

Related Use Cases (if any):

None, but all can be extended to encompass provisioning of authorized access as described here.

Existing solutions:

The CASHMERE project designs an approach to address this concern in particular, integrating with the Yggdrasil HMAS platform, though the prototype implementation is a work in progress.

Identified Requirements by the TF:

1. Target entities of the motivating scenario:

   • resources and services in an HMAS platform, representable as ThingDescriptions, whose Affordances require a dynamic means of authorization (i.e. based on attributes that characterize the situation in the HMAS environment in which the interaction between an agent and a resource takes place). The conceptual model of the resources is assumed to conform to the Agents & Artifacts paradigm, but is not necessarily limited to it.
   • the HMAS platform itself, as the facilitator to dyanamic / context-based authorized access.

2. Life cycle of the target entities: i.a) A TD entity is deployed in an HMAS platform, whereby its RDF representation specifies that it is context authorized. The representation indicates a SHACL shape that contains the context conditions which the requesting agent / service needs to satisfy in order to access affordances of the entity. i.b) The HMAS platform that deploys the entity indexes the resource as a context authorized one and retains the required context conditions. ii. An agent invokes an affordance of the HMAS entity that is context authorized. iii. The HMAS platform proceeds to identify the effective authorization policy to the resource. The effective policy is obtained based on the indexed context conditions of the entity, if such conditions are specified. If the entity does not specify authorization conditions, then the policy is determined on hand of policies in the entity containment hierarchy, should such a hierarchy exist. If no hierarchy exists, authorization is granted by default. iv. If context authorization conditions are identified, then the HMAS platform validates the conditions against the corresponding static (always true), profiled (limited validity), and dynamic (event-like) RDF graphs holding the necessary context information v. If all context conditions are validated, authorization is granted for the current invocation of the requested entity affordance . If a context condition is invalid, the result of the SHACL validator is returned to the requesting agent / client.

3. Information conveyed about affordances: allowed or disallowed access to the affordance when invoked. The list of context conditions required to be satisfied for authorized access to the affordance.

4. How the life cycle is influenced:

   • through addition or removal of context conditions for authorized access to the affordances of the entity
   • through addition or removal of context conditions at the level of the containment hierarchy of the entity in the HMAS platform, should a hierarchy exist
   • through the addition or removal of context sources within the platform
   • through the management of RDF context graphs at the level of the entity vs. the platform in which it is deployed.

5. Communication protocols: bespoke REST APIs that are introduced as part of a context management service at the level of the HMAS platform in which context authorized entities are deployed.

6. Representation formats: RDF, using vocabulary from several ontologies, such as:

   • the HMAS Ontology,
   • SHACL,
   • Web Access Control ontrology from SOLID,
   • the CASHMERE ontology (introduced in the CASHMERE project to describe context authorized resources, as well as context management at the level of an HMAS platform),
   • the CONSERT ontology (see CASHMERE project ) used to represent the context information.

7. Security and privacy considerations: Though not currently enforced, the design envisions identification of requesting agents / clients by means of a WebID, as well as their semantic description as a type of foaf:Agent.

Possible Gaps:

• The need for a specification and a mechanism to cache authorization requests for context conditions that would be frequently validated for the agent requesting the affordances.
• The need to manage network latency when obtaining the context graphs required to validate the context conditions expressed as SHACL shapes.

Comments:

[egekorkan]

@asorici thank you for the scenario proposal! We are now going to extract the requirements from each use case and we need you to extend your first comment with the types of requirements listed at https://github.com/w3c-cg/webagents/issues/34. You can have a look at an example at https://github.com/w3c-cg/webagents/issues/24

[asorici]

@egekorkan I have extended the description of the scenario with respect to the items in the Identified Requirements list that you referenced.

[egekorkan]

Thank you @asorici ! This is nicely thorough and identifies some gaps. I would include everything you currently do in part of the research projects as gaps since they are not in the standards. A vocabulary for conditional access is definitely missing and can be better highlighted here.

[egekorkan]

Also see https://w3c.github.io/wot-usecases/#UC-education-shared-devices-1 as a relevant UC