Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[UC] Resource Aggregation #88

Open
termontwouter opened this issue Jan 1, 2025 · 0 comments
Open

[UC] Resource Aggregation #88

termontwouter opened this issue Jan 1, 2025 · 0 comments
Labels
triage Issues needing triage usecase LWS Use Case

Comments

@termontwouter
Copy link

termontwouter commented Jan 1, 2025

As a Resource User,
I want to access many different resources of many Resource Owners at once, and/or have access to a derivative/aggregate without having to query them all separately,
So that I can enable applications that are otherwise not practically possible.

Preconditions:

  • One or more Resource Owners/Controllers provide access to some resources on one or more LWS-compatible resource servers.
  • An LWS-compatible Aggregation Service exists that is configured to provide aggregated and/or derived data based on the resources of the ROs/RCs.
  • Resource Users can make requests to the Aggregation Service as if it were an LWS resource server, to efficiently access the aggregated/derived information.

Trigger:

A Resource User wants to access an aggregate or derivative of multiple resources of possibly multiple Resource Owners.

Actors:

  • [Primary] The Resource User (~ Data User/Customer): an agent who wants to access resources that are under the control of the RO/RC, typically through a certain Client Application (~ Data Consumer).

  • [Secondary] The Resource Owner/Controller (~ Data Holder/Supplier): an agent who has partial/delegated (controller) or ultimate (owner) control over policies concerning certain resources.

  • [Technical] The Aggregation Service (~ Data Provider): the LWS-compatible system that provides the aggregated/derived resources to the Resource User.

  • [Technical] The Resource Servers (~ Data Providers): the LWS-compatible system that provides the original resources to the Aggregation Service.

  • [Technical] The Authorization Services: the access management systems used by the ROs/RCs to protect their resources on the RSs.

  • [Technical] The Aggregation Service's Authorization Service: the access management system of the Aggregation Service.

Distinction:

This use case primarily addresses concerns about the performance/efficiency of decentralised web storage. While in theory most functionality could be achieved without aggregation, in practice real applications involving multiple servers/owners/... will quickly bump into unacceptable performance issues when each resource needs to be retrieved/computed individually every time.

This use case also applies to caches.

Scenario:

  1. The Resource User wants to to access an aggregate or derivative of multiple resources of possibly multiple Resource Owners.
  2. The RU discovers an Aggregation Service offering the desired aggregate/derivative.
  3. The RU requests access to the aggregate/derivative from the Aggregation Service's Authorization Service.
  4. If unknown (e.g. no valid cache/token), or upon initialisation, the Aggregation Service's Authorization Service requests access to aggregate (under certain conditions) from the Authorization Services of the relevant Resource Owners/Controllers.
  5. From each Authorization service (of which the RO/RC grants the access), the Aggregation Service's Authorization Service gets an access token.
  6. The Aggregation Service's Authorization Service communicates the conditions/requirements to the RU.
  7. The RU attempts to fulfil the requirements by providing the necessary credentials to the Aggregation Service's Authorization Service.
  8. When all requirements are fulfilled, the Aggregation Service's Authorization Service provides the RU with an access token.
  9. Using the access token, the RU requests the aggregated/derived information from the Aggregation Service.
  10. If the aggregate/derivate has not yet been calculated, or needs to be updated, the Aggregation Service uses its own access tokens to retrieve the relevant resources at their respective Resource Servers.
  11. Having calculated the aggregate/derivative, the Aggregation Service delivers it to the authorised RU.

Alternative case(s):

  • The Authorization Service might have access only to a subset of the data the RU wants to have aggregated.
  • The Authorization Service might have to wait on async approval by one of the ROs/RCs, before being able to address the request of the RU.

Error scenario:

NA.

Acceptance Criteria:

  • Aggregation Services can request access to build aggregates/derivatives.
  • Aggregation Services provide those aggregates/derivatives to RUs.
  • The RU can request access to aggregates/derivatives without having to address all individual Authorization Services.
  • The RU can retrieve the aggregate/derivative without having to address all individual Resource Servers.

References:

NA.

@termontwouter termontwouter added triage Issues needing triage usecase LWS Use Case labels Jan 1, 2025
@termontwouter termontwouter changed the title [UC] Resource Aggregation <DRAFT> [UC] Resource Aggregation Jan 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage Issues needing triage usecase LWS Use Case
Projects
None yet
Development

No branches or pull requests

1 participant