8000 [UC] Restricting client access to sensitive data · Issue #147 · w3c/lws-ucs · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[UC] Restricting client access to sensitive data #147

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.

Sign up for GitHub

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

Jump to bottom
Open
NSeydoux opened this issue Apr 25, 2025 · 2 comments
Open

[UC] Restricting client access to sensitive data #147

NSeydoux opened this issue Apr 25, 2025 · 2 comments
Labels
triage Issues needing triage usecase LWS Use Case

Comments

@NSeydoux
Copy link

As a person (Charlie) storing personal finance information in y storage,
I want to be able to restrict access to this sensitive data to certain trusted clients,
So that my sensitive data is n't available by default to any client I log into.

Preconditions:

  1. There must exist a mechanism for clients to be identified
  2. There must exist an access control mechanism to discriminate access to data based on client identity
    a. As a corollary, there must exist a mechanism for clients to request access to data they are not trusted for so that the data owner may extend their trust to new clients over time.

Trigger:

There are two main entry points to this use case:

  1. A client issues an authenticated request on behalf of the resource owner to a protected resource. In this use case, my personal finance management app should be allowed to access financial data from my storage, while my note-taking app should not.
  2. A client requests access to some data to the resource owner. In this use case, a new personal finance management app I am starting to use should, by default, not have access to financial data on my storage, and I as the resource owner should be able to grant such access so that the app may perform its function.

Actors:

  1. The resource owner (e.g. Charlie), who decides which clients should be allowed to interact with which data they own. This is orthogonal to permissions granted to agents to interact with the same data.
  2. The client (e.g. my personal finance management app), which is either allowed or not allowed to interact with the data owned by the resource owner logging in to the client.
  3. The storage, where the resource owner's data is stored. Client access restrictions are expressed by the resource owner and enforced by the storage upon client request.

Distinction:

  1. In order to deliver a good user experience, it might be good for the client to be able to distinguish whether access is being restricted because of client access restriction or agent access restrictions. This however may not be possible for security concerns.
  2. Existing client authentication mechanisms, such as Dynamic Client Registration and Static Client Registration, scope the client identity to the OpenID Provider, which may be a restriction in the case of the work of the LWS WG.
  3. There bootstrapping user experience will be important, so that users start with secure defaults and can manage which clients are allowed or revoked over time.
  4. The storage will need some way to verify the client assertions.

Scenario:

  1. Charlie logs in to their personal finance management application, PFM. Charlie's storage is already configured to allow PFM to access finance data.
  2. Charlie is able to use PFM to manage their personal finances, and to generate new finance data with the same access restrictions.
  3. Charlie logs in to a brand new alternative personal finance management application, MyBudget. MyBudget does not have access to Charlie's finance data on their storage.
  4. MyBudget requests access to Charlie to their financial data, and Charlie grants access in a trusted context.
  5. Charlie is now able to use MyBudget to visualize the same data from their storage.
  6. Being more satisfied with MyBudget, Charlie revokes access to their finance data to PFM. Charlie is no longer able to access their data using PFM.
  7. Charlie opens their calendar app to set a reminder for later. This app does not have access to Charlie's finance data on their storage.
  8. Charlie's spouse, Alex, has access to Charlies personal finances on their storage. Alex can access this data using MyBudget, but not using PMF.

Alternative case(s):

An alternative would be to be able to express access restrictions not for individual clients, but for clients having specific characteristics. For instance, Charlie could trust any client being approved by a trusted authority or having a certain certification to handle their personal finances, without explicitly trusting PFM or MyBudget individually. Clients should then be able to discover the expected criteria, and to demonstrate their compliance.

Error scenario:

Because this use case is related to access management, error scenarios are akin to data breaches, that is a client gets access to data it should not have access to. The system should handle this in the way it is expected to handle any other data breach, by patching it as soon as possible when found out, then private disclosure to the impacted parties, and finally public disclosure. This is most likely is out of scope of the specification.

An unexpected situation might be a client issuing a request to the storage without any identifier, or with an identifier not compliant with the specification. In this case, the default system behavior should be not to allow access to any data for which any client restrictions apply.

Acceptance Criteria:

  1. A client can present an identifier to the storage as part of an authenticated request
  2. The data owner can express restrictions regarding which clients should have access to some data.
  3. A client not compliant with restrictions expressed by the owner to some data is refused access by the storage.
  4. A client may discover when it is prohibited data access because of owner restrictions, and may follow steps to request access to the owner.

References:
@NSeydoux NSeydoux added triage Issues needing triage usecase LWS Use Case labels Apr 25, 2025
@hzbarcea
Copy link
Contributor

@NSeydoux this is a very good use case and, as you pointed out, is addressed by other use case. There are other aspects of the use case you didn't mention directly. For instance, if Charlie is a member of a community, in some case the use of the storage may be governed by the community not even necessarily by the user. Other example cases are for medical records, education or even criminal records, where users MUST not be able to alter records.

@NSeydoux
Copy link
Author

That's correct, I focused the use case here on client access restrictions for brevity and clarity but agent access restrictions are also crucial.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
triage Issues needing triage usecase LWS Use Case
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@hzbarcea @NSeydoux
0