Skip to content

[UC] Freedom of policy modelling language/mechanism #60

@termontwouter

Description

@termontwouter

As an Authorization Service Provider,
I want to be free in how to implement policies, as long as I adhere to the interfaces defined by LWS,
So that I can develop policy mechanisms/languages that are better suited to my users.

Preconditions:

  • A 3rd party provides an Authorization Service for RO/RC's, where the latter can manage the policies protecting their resources on one or more LWS-compatible Resource Servers.

Trigger:

A new Authorization Service is being developed, or an existing provider reevaluates the technologies it employs (e.g. policy modelling language, evaluation/decision engine …).

Actors:

  • [Primary] The Authorization Service provider, i.e., the party making decisions related to the implementation of an the access management system used by RO/RC's to protect their resources.

Distinction:

This use case primarily involves a thorough separation of orthogonal concerns, enabling different parties to take up different responsibilities and to be free in how to implement them, based on the state of the art evolutions in their respective domains of expertise.

Scenario:

  1. The provider implements a new part of their Authorization Service (e.g. policy modelling language, evaluation/decision engine …), as well as a mapping from the LWS authorization-related interfaces to their internal implementation.

  2. After having set up the new implementation, interactions with Resource Servers and Client Applications (continue to) work as prescribed by the LWS protocol(s), without the latter knowing anything about this specific Authorization Service implementation.

Alternative case(s):

NA

Error scenario:

The implementation of the Authorization Service does not fully adhere to the LWS interface(s). Resource Servers and Client Applications interacting with it should then follow the directions of the LWS specification(s) for such error cases.

Acceptance Criteria:

  • Given the LWS protocols and interfaces, the Authorization Service implementation (e.g. policy modelling language, evaluation/decision engine …) should be freely interchangeable. Apart from outward-facing interfaces, this freedom should be absolute.

References:

Jacobs, Ian, and Norman Walsh (eds.). 2004. ‘General Architecture Principles’. In Architecture of the World Wide Web 1 (W3C Recommendation). https://www.w3.org/TR/webarch/#general.

Metadata

Metadata

Assignees

No one assigned

    Labels

    triageIssues needing triageusecaseLWS Use Case

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions