Authorization layer should limit the amount of data permitted to be stored by a application

[kdenhartog]

An application could maliciously store a lot of junk data in the identity hub which overloads the storage capabilities of the user. There should be a permission set at the authorization layer to prevent a malicious application from overstoring and costing the hub user additional costs in storage.

[csuwildcat]

Sounds like a good thing to add to a capability formulation, which is something we need to pick in general. Something to consider is large single files vs tons of small ones - tracking and enforcing total limits on the latter might be a fair bit of work.

[agropper]

In general, we should keep the authorization server role separate from the resource server role in case these two roles are implemented as separate domains. In the general case, a single authorization server might be trusted to control multiple resource servers (e.g. replicates) or a single resource server can trust multiple authorization server (e.g. for separate customers).

This separation of concerns allows major cost savings when the resource server (RS) doesn't need to worry about privacy because that is handled by the authorization server (AS). For its part, the AS can add value by making it easier for resource owners to switch RSs.

Denial of Service attacks like this issue #96 are primarily a RS (security) issue and need not be handled by the AS except to the extent that a RS chooses to notify the AS of an exception.

That said, the RS can also issue a capability that makes explicit the parameters for a DoS attack in which case the resource owner, as recipient of the capability, can choose to use it themselves, pass it on to an authorization server of their choice, or pass it to a requesting party. The difference between these delegation options becomes interesting when the resource owner controls both a mobile wallet and a cloud wallet (as authorization server).

• Adrian

On Sun, Nov 7, 2021 at 1:02 PM Daniel Buchner @.***> wrote:

Sounds like a good thing to add to a capability formulation, which is something we need to pick in general. Something to consider is large single files vs tons of small ones - tracking and enforcing total limits on the latter might be a fair bit of work.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/decentralized-identity/identity-hub/issues/96#issuecomment-962655137, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YMGYLAWQCU4TDMI553UK25LXANCNFSM5HQPVR4Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[gobengo]

@csuwildcat has anything changed in the impl. Is it obvious how the current spec would accomodate this?

Sounds like a good thing to add to a capability formulation, which is something we need to pick in general

do you still think this should be specified as part of the cap?

[LiranCohen]

We are considering and thinking about these things as we are building the protocol rules. Keeping this open for now.

[andorsk]

revisited over DIF call. Discussed to keep this open and discuss later in more detail.