You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ability to control who/what can access specific resources in your pod is great. An important complement is to be able to see how and when they are using this access.
Being able to query how the access you've given is being used is a great way to determine whether those grants are too broad, still necessary, or being abused.
Extreme caution needs to be taken in how this is designed, lest it turn into an avenue for denial of service. For example, limiting it only to those requests that successfully pass authorization would restrict any recorded activity to entities that should have some semblance of trust already. Similarly, recording and updating only aggregate metrics may reduce resource usage without losing much practical value.
This is a fine idea but can it be first incubated in solid/solid-spec and preferably even before that have implementation experience (from servers and applications)? I think we need to prioritise spec/documenting items that are somewhat tangible.
This is a fine idea but can it be first incubated in solid/solid-spec and preferably even before that have implementation experience (from servers and applications)?
Absolutely - the issue wasn't created with an expectation that this needs to be included in 1.0. - only to ensure that it be tracked for consideration. (IMO) A key part of realizing any of that implementation experience is to identify things that we'd like to see be incorporated into the specification at some point - which hopefully catalyzes those same implementation efforts.
I'm not sure if this issue is intended to be about querying (and mechanisms) or reading the description of a resource about activities. Whether the complete activity information is desired to be readable by all agents with Read or only the the subset of that information that's relevant to the observing agent...
I'm not sure if this issue is intended to be about querying (and mechanisms) or reading the description of a resource about activities.
It's the latter. I've removed the topic:querying tag so there's no further confusion
Whether the complete activity information is desired to be readable by all agents with Read or only the the subset of that information that's relevant to the observing agent...
Agree this will be important to sort out. We'll have to see what the use cases bear out, and take a look at how other systems handle similar patterns.
Activity
csarven commentedon Aug 4, 2019
This is a fine idea but can it be first incubated in solid/solid-spec and preferably even before that have implementation experience (from servers and applications)? I think we need to prioritise spec/documenting items that are somewhat tangible.
justinwb commentedon Aug 4, 2019
Absolutely - the issue wasn't created with an expectation that this needs to be included in 1.0. - only to ensure that it be tracked for consideration. (IMO) A key part of realizing any of that implementation experience is to identify things that we'd like to see be incorporated into the specification at some point - which hopefully catalyzes those same implementation efforts.
RubenVerborgh commentedon Aug 4, 2019
Good idea. Probably would need to be its own separate document.
csarven commentedon May 1, 2020
I'm not sure if this issue is intended to be about querying (and mechanisms) or reading the description of a resource about activities. Whether the complete activity information is desired to be readable by all agents with Read or only the the subset of that information that's relevant to the observing agent...
justinwb commentedon May 2, 2020
It's the latter. I've removed the topic:querying tag so there's no further confusion
Agree this will be important to sort out. We'll have to see what the use cases bear out, and take a look at how other systems handle similar patterns.