Requirement of use.id customers: requiring the user to be logged in to access data

[tomhgmns]

When you share data with another WebID (e.g. I share data with use.id/wouter), the party with the other WebID can access my data as long as my store is online (e.g. Wouter can access my data).

However, now that use.id and its customers are ready to launch, we've noticed that most of them had the same requirement...

They would only like to access data when the user is actually logged in...

Has the panel thought about this requirement?

[elf-pavlik]

They would only like to access data when the user is actually logged in...

Do you mean that Resource Owner has to be online for some other Requesting Party (who RO shared access with) to access that data?

If that is the case, how precise do you expect it to be, if someone is on the spotty mobile network, should the access to their storage go on and off for others? Or as long as RO has an active session with the OP I assume, access to their storage should be available.

I think I would need the use case defined with little more precision to consider it properly.

[tomhgmns]

The use case is indeed defined vaguely. Nevertheless, even though the requirement is vague, it is an actual requirement of two of our customers.

I think a first step would be to define the meaning of "online", indeed. We think that it can be defined as the case when an app has a valid access token for a user.

[elf-pavlik]

I think a first step would be to define the meaning of "online", indeed. We think that it can be defined as the case when an app has a valid access token for a user.

Each user uses any number of apps, some of them will valid access (more likely refresh) tokens while other apps do not. When we try to determine if the user is 'online' we probably can only rely on their OIDC provider and active ID Token.

In your case, can the Resource Owner and Requesting Party use different apps to collaborate or the app creates sort of a silo around itself and both parties have to use the same app?

[msnm]

Let me try to explain the use case and how I interpret the interoperability specification:

• Our end-users are social agents who have a webid
• Our acme-backend-application is a Solid Application with a webid (webid.acme.com)
• Our acme-mobile-application is not a Solid Application
• In absence of the Authorization Agent when our acme-backend-application provisions a solid pod for an end-user at Use.id the Application is given CRUD access to a specific acme-sub-container in the pod

Use Case 1: acme-backend-application writes data in the pod

• The acme-backend-application can write data in the pod after authentication via a custom solid client credential flow provided by UseID.
• This use case is fine for us because we need to be able to write data in the pod without the end-user being available.

Use Case 2: An end-user using our acme-mobile-app must be able to see the data we have stored in the pod. Our acme-mobile-app integrates via GraphQL with the acme-backend-application.

• AS IS: The acme-webid has CRUD access so we can retrieve the data of the logged-in consumer and proxy it back via GraphQL service to the mobile app. However, we don't like the fact that we have READ access. This means if someone can somehow get into the backend and obtain our client credentials they can read all data of all the end-users we have access to.

• TO BE: The acme-webid has only READ access to the data of the acme-sub-container only when the end-user is online. Online means being able to present a valid Solid Access Token. The acme-backend application can then READ the data by presenting its own AccessToken + accessToken of the end-user to the Solid Server. This minimizes our attack surface.

[elf-pavlik]

• Our acme-mobile-application is not a Solid Application [...] Use Case 2: An end-user using our acme-mobile-app must be able to see the data we have stored in the pod. Our acme-mobile-app integrates via GraphQL with the acme-backend-application.

Based on that I would consider this mobile app as an implementation detail of ACME app. It seems to me that we can ignore it in the flow and only consider acme-backend-application as OAuth client, this means it should be denoted in Authn with client_id claim.

The acme-webid has CRUD access so we can retrieve the data of the logged-in consumer and proxy it back via GraphQL service to the mobile app. However, we don't like the fact that we have READ access. This means if someone can somehow get into the backend and obtain our client credentials they can read all data of all the end-users we have access to.

If you use ACME app (again the backend, since mobile is ACME impl. detail) as OAuth client (so client_id in AuthN). When some End-user uses it should use Solid-OIDC to get a token (before access token, now ID Token) with:

{
  webid: "alice.use.id", // End-user WebID
  client_id: "webid.acme.com" // Client ID
}

The acme-webid has only READ access to the data of the acme-sub-container only when the end-user is online. Online means being able to present a valid Solid Access Token. The acme-backend application can then READ the data by presenting its own AccessToken + accessToken of the end-user to the Solid Server. This minimizes our attack surface.

If you take the approach I described, I believe this will be accomplished by not requesting offline scope from OIDC Provider, so it will not issue the refresh_token which will result in token with a mentioned combination of webid and client_id expiring.

Please let me know I misunderstood your scenario or miss something in the approach I described.

Described approach assumes incorporating client_id in access control for example acp:client matcher

EDIT please also see example in https://github.com/solid/authorization-panel/blob/main/proposals/evaluation/uc-2.5.2-client-constraints.md