Access token needed to access registry sets?

[woutermont]

As I understand the current draft, an application would need an Agent's Access Token to retrieve the Agent's Application Registry set. This seems to defeat the purpose of limiting access of Applications to specific Resources as descibed by the draft, since the Application could simply use the Token to access all resources as if it were the Agent itself.

Do I miss something here?

[elf-pavlik]

I think this situation is still not perfectly clear in general solid ecosystem. Even with current state of Solid-OIDC, access token includes webid claim denoting the User and client_id claim denoting the application.

Application could simply use the Token to access all resources as if it were the Agent itself.

Authorization guard enforcing access control policies will need to take both webid and client_id claims into account so what you said can not happen!

---

It is still unclear how to handle this use case 2.5.2. Limiting application access while not acting as resource controller. IMO Solid-OIDC shouldn't be issuing access tokens but only draw the line to issuing id token. In that case we could use combination of OAuth 2.0 Token Exchange and something inspired from User-Managed Access (UMA) 2.0 - Claims Gathering. This would allow application to exchange id token and provide additional claims. One of those additional claims could be data grant relevant to the resource server it requests data from. Above may require to separate Data Access Consent, representing user's consent decision and Data Grants which would need to be more granular with specific audience (RS hosting particular data registration).

[woutermont]

Authorization guard enforcing access control policies will need to take both webid and client_id claims into account so what you said can not happen!

Aren't we then unnecessarily duplicating access control policies? If an end-user autherizes a client app using OIDC, why would the resource server need to perform additional checks on the client id?

Since interaction between end-users and different client apps happens on-the-fly, authorizing the client seems i.m.o. something that should be done by the end-user at the OIDC provider. Have we looked into resource indicators as a possible solution?

[elf-pavlik]

Since interaction between end-users and different client apps happens on-the-fly, authorizing the client seems i.m.o. something that should be done by the end-user at the OIDC provider.

Currently Solid Application Interoperability - 6. Data Authorization describes consent screen and issuing Data Grants to applications. It still does needs some work but we are pretty confident that this responsibility will lay with user associated trusted agent. Actually you could take a look at some early sequence diagrams in Solid Application Interoperability Primer - 2.15. Sequence diagrams, currently I have them for case where IdP and Authorization Agent are combined together, while we want it to be possible we also want to support separate IdP and Authorization Agent with some extra redirects happening.

Have we looked into resource indicators as a possible solution?

Could you clarify where would you see them used and how it would work with current form of 7. Access Needs

[justinwb]

Aren't we then unnecessarily duplicating access control policies? If an end-user autherizes a client app using OIDC, why would the resource server need to perform additional checks on the client id?

Because the application I use to manage my financial information shouldn't automatically get access to my medical data, and vice versa. The value of Client Identifiers is realized when you provide a scheme to compartmentalize information based on them. They are not perfect, but as applied in this specification for someone managing data in their control, they're pretty effective.

[elf-pavlik]

Since interaction between end-users and different client apps happens on-the-fly, authorizing the client seems i.m.o. something that should be done by the end-user at the OIDC provider.

I started a Draft PR in Solid-OIDC solid/solid-oidc#18 which aims at removing notion of OIDC provider acting as Authorization Server. It proposes RS associated AS which should not be conflated with Requesting Party's (user of the client) Authorization Agent. We still should clarify distinction between Resource Owner (so also RS) associated Authorization Server and Requesting Party associated Authorization Agent.

@woutermont do you think this issue requires further discussion or we can close it?

[woutermont]

If that is the way the panel wants to go, then you can close this issue. Just seems like a waste of good functionality if we extend OIDC and then don't use the underlying authorization capabilities.

[elf-pavlik]

@woutermont now we also have this issue solid/authentication-panel#186

I think we also need to keep something in mind, in many cases the End-user (aka. Requesting Party) will be different from Resource Owner. In that case End-user uses their Authorization Agent (similar as they use their Idp). At the same time after changes we are discussing Access Token gets issued by Authorization Server associated with Resource Server so also Resource Owner. So we have distinct Authorization Agent (associated with End-user) and Authorization Server (associated with Resource Owner). Part of the Authorization we focus on in this panel pretty much focuses on the Authorization Agent and Applications (Client instances). IMO Authorization Server should be defined in AuthZ panel once we correct Solid-OIDC to only be responsible for AuthN, so pretty much only ID Token.

I also should add that I do find it tricky that AuthN and AuthZ work is happening in 3 different panels and we should be syncing it up much better than we currently do.

[justinwb]

I also should add that I do find it tricky that AuthN and AuthZ work is happening in 3 different panels and we should be syncing it up much better than we currently do.

+1 - @woutermont would be great to get your use cases included (or make sure we have them reflected somewhere already) as we try to consolidate the attentions around authz

[woutermont]

@justinwb, there's no specific use case underlying this issue; rather a worry about the user's access token still being needed in the application's flow, and thus still not closing all the doors for malicious token replay.

[elf-pavlik]

rather a worry about the user's access token still being needed in the application's flow and thus still not closing all the doors for malicious token replay.

Do you refer to Access Token as currently specified by Solid-OIDC? Does it still apply once Solid-OIDC moves away from issuing global access tokens?

I think we should focus on documenting the scenario where we have potential vulnerability.

[woutermont]

@elf-pavlik, I'm not sure, since I do not entirely comprehend which way the authentication panel wants to go without global access tokens. This issue dates from before that intention was known to me, and it is unclear to me if it would still exist in that regard.

In any case, the interoperability specification, or more specifically the API document, seems to indicate that the application will need to access non-public resources, e.g. the application registry set. As it currently stands, this would be done by using the user's access token, which means the application must be able to add this token to requests, and thus can also access other resources. Moving away from global access tokens will only prevent such misuse if the alternative does not consist in a similar flow where the application has such a capability.

But again, as to what the details of such an alternative would be, I'm not yet up to speed.

[elf-pavlik]

As it currently stands, this would be done by using the user's access token, which means the application must be able to add this token to requests, and thus can also access other resources.

I don't understand where does the assumption that application would be able to access anything else beyond what user authorized it to access. Application can access:

• Application registration created for it by it's user, it contains Access Receipt (soon Access Grant) with all the Data Grants
• Data that each Data Grant issued for this specific application, based on User's authorization consent, allows to access

Besides above application can't access anything else.

Current Solid-OIDC oversteps into authorization in a way that doesn't leave space to put those Data Grants into the flow, but even here we could look into defining out of band mechanism to deliver them to where access is being guarded.
In solid/solid-oidc#18 I'm proposing how to change the flow that Data Grants issued for application would need to be included in the flow, based on them access restrictions which user puts on application would be enforced.

[woutermont]

Unless I'm missing something, the application must be able to send some form of credential to access the application registry. For example, in this access request diagram the ACME project gets an access token from Alice's IdP. As it currently stands, using that token grants global access to everything Alice can access.

How would a restriction of Solid-OIDC to mere authentication with an id token change this? Even in the diagram from solid/solid-oidc#18, the resource client first gets an id token from the IdP, and then exchanges it for a (local) access token at the RS-bound AS. What prevents the client from using the id token to get a local access token at another RS/AS, or using the (local) access token to access other resources than the application registry?

Edit: note that in this scenario, the application is not yet known to the RS/AS, and possibly not to the user either; the only way to identify the application and/or its rights is by way of the tokens, which are those of the user, and thus indistinguishable from an immediate (i.e. not application mediated) request by the user.

[elf-pavlik]

As it currently stands, using that token grants global access to everything Alice can access.

IMO this is only due to lagging work on AuthZ panel. Data Grants from this panel provide big part of possible solution, it's still matter of integrating it with AuthN and rest of AuthZ.

What prevents the client from using the id token to get a local access token at another RS/AS, or using the (local) access token to access other resources than the application registry?

By default any application should have no access, an opposite to what currently seems to be the case. We currently look in two directions of addressing it:

1. Authorization Agent updates access policies for all the resources 'out of band' adding client restrictions. Here Authorization Agent has special designation in user's WebID Document which gives it rights equal to the user, so it shouldn't be considered a regular application.

I don't like this approach personally since it may lead to racing conditions, this UC would also not be supported by current WAC and I find it unclear if ACP would address it.

2. Authorization Agent issues Data Grants as tokens which can be pushed as claims when obtaining access tokens

solid/solid-oidc#18 includes pushing optional tokens but doesn't show getting one from Authorization agent
Last week I started a thread on GNAP mailing list where I would try to get suggestions how GNAP would handle issuing and exchanging such 'client permissions tokens'.

I'm also looking at Authorization Capabilities for Linked Data if we could align Data Grants with them and use as 'client permissions tokens'.