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] Sovereign decision which identity provider, applications, and users to trust #29

Open
uvdsl opened this issue Dec 9, 2024 · 0 comments
Labels
triage Issues needing triage uc-authorization usecase LWS Use Case

Comments

@uvdsl
Copy link

uvdsl commented Dec 9, 2024

Status: Draft

As a data provider,
I want to sovereingly decide which identity provider, which applications and which agents (user identities) to trust for accessing my data,
So that I can ensure (protocol) security when sharing my data.

Example: limiting user identities
Alice only wants to share her private holiday blog only with her friends, e.g. Bob and Charlie, but not with others.

Example: limiting identity providers
Alice assumes that the identity provider "EvilCorp" asserts that some malicious agent is actually Alice or one of her friends.
To keep her data secure, she disallows any request that uses a token issued "EvilCorp" as an identity provider.

Example: limiting applications
Alice wants to use "myTaxApp" to process her finance data and create a tax report.
Alice does not want her finance data to be available to "myShadyImageApp", even when she is logged in herself.

Preconditions:

What conditions must be in place or assumed before this use case can begin?

  • data storage where the data provider can set access rules on their data

Trigger:

What (user or system) event or action initiates this use case?

  • there may exist malicious or compromised identity providers
  • there may exist malicious or compromised users (identities)
  • there may exist malicious or compromised applications
  • some use cases restrict access to certain identity providers, applications, users

Actors:

Describe the primary actor, and any other relevant actors involved in this use case

  • data provider
  • data storage

Distinction:

What unique challenges or distinguishing factors (like technical issues, user experience needs, workflow integration, etc.) are associated with this use case?

  • expressivity of the access control description
  • correponding enforcement

Scenario:

Describe an ideal or happy-case scenario where this use case would play out as intended.

In case a data provider wants to restrict access to specific users, from specific identity providers, and to specific applications,
the data provider describes their choice in the access control rules that are applied to the data storage.

Alternative case(s):

What alternative flows or variations should the system handle for this use case?

Error scenario:

What unexpected issues or errors might arise, and how should the system handle them?

Acceptance Criteria:

What conditions or criteria must be met for this use case to be considered successfully handled? What limitations are acceptable?

Security of the corresponding (authentication and) authorization protocol must be ensured.

References:

List any relevant resources or examples that could inform this use case, possibly from other domains or solutions.

Solid Community:

This use case is in the spirit of

@uvdsl uvdsl added triage Issues needing triage usecase LWS Use Case labels Dec 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage Issues needing triage uc-authorization usecase LWS Use Case
Projects
None yet
Development

No branches or pull requests

1 participant