Sharing the key comments to bring visibility to the topic.
From @pospi: I think @david-hand was planning on leading the fact-finding we need for this at the moment, but to start perhaps a summary of our current thinking to pull apart & discuss is the most worthwhile thing:
A common use-case in REA networks is to have application-specific behaviour in other modules coded to respond to different types of AgentRelationships. For example, a Person who is a member of an Organisation may have special privileges that non-members do not.
This module deals with People, Organisations and recording the AgentRelationships between different entities- nothing further. Having a separate collaboration space to record this information allows for organisational structures to be shared with other modules without the logic for managing such structures needing to be replicated in each module. It may be accessed via other modules to perform access checks; though it is more likely that such access checks would reference the local Holochain capability register rather than data in other modules.
The expected parameters needed to allow for delegated authority are detailed in this Github issue but the details are pending decisions to be made by the HDK core team.
We probably want this module to orchestrate permissions and bridging for agents who join & leave managed groups, and filter those permissions down through the connected / deployed networks via way of capability grants. In implementing this we may want a split- one zome for the governance processes & agent relationships, another for applying REA-specific capabilities to the rest of the network. The latter would be reusable with other governance frameworks, the former would not. Capabilities (and access control logic) are always local to each module- to modules other than agent relationships, the agents who interact with them are all just anonymous people who happen to have permission to do certain things.
^referenced GH issue: https://github.com/holo-rea/holo-rea/issues/9
Related, more direct questions:
- Can you have an agent key which no single person has access to? NO.
- (failing that:) can you generate a capability token for a non-agent identity?
- (failing that:) can you generate arbitrary capability tokens on the fly & validate them by hand within a zome callback?
- (failing that:) can you generate a capability token for a non-agent identity?
- Is it possible to create a capability token and lock it up within a DNA somehow, so that it can only be used in operations that are triggered by the DNA (rather than triggered directly by an agent)?
From David-Hand: What I would like to know is as follows:
- Is there a way for one app to generate a capability token for another app?
- Are the capability tokens specific to an agent or by agent-app?
- if app A issues a capability token, then in app B on the same agent, does that token still exist?
- Can app B query that token somehow to validate that it exists?
- If app A requests a token from app C, can app A then pass that token to app B? Can app B still use it to access app C?