Delegator and Delegate communication

[edytapawlak]

I tried to split the logic for Delegator and Delegate, but it seems to be quite tangled up.

I thought about a delegating event as an impulse for the Delegate to make a delegated event. However, the Delegator can't create one without a delegated event hash. If generating a delegation events pair starts with the delegated event, how does the Delegate know that it should create one?

So the question is how Delegator and Delegate communicate with each other, especially how and who initiates the delegation operation?

[SmithSamuelM]

Delegation is cooperative. This enables enhanced security because the delegator and delegate may cooperate to recover compromised keys of the delegate. An attacker would have to exploit both the delegate and delegator to succeed. But cooperative delegation requires an interaction or set of interactions between the delegator and delegate.

One possible exchange sequence is as follows:

1- Potential Delegate requests delegation from Delegator 2- Delegator responds with location seal of proposed future delegating event that will house the delegation 3- Delegate creates delegated event and responds with seal of delegated event

4- Delegator creates delegating event and adds seal of delegated event to its delegating event. Responds with acknowledgment or refuses (times out) 5- Delegate confirms publication of delegating event and if true publishes delegated event. Else restart at 1- 6- Else if time out or refusal of 4- then delegator responds with new location seal of a new proposed delegating event and resume at 3 above.

[blelump]

Hi Sam,

regarding steps 1-3, should we consider them as steps that perform out of KERI core capabilities, ie. this should be a KERI consumer concern or that should be on KERI side?

Thinking about this, especially about steps 1-3, both options are viable. If that pre-pair phase would be a part of KERI core features, that would also require additional (configuration?) messages that any KERI instance understand and is able to reply. (if needed). This, however, comes to mind an idea that it does not fit to KERI as the steps 1-3 do not conform to the event shape so they are not events. They sound more like a configuration phase, like press green button to turn it on. In essence, it seems it's more related to the communication protocol and can be (has to be?) done out of KERI. It is then a KERI consumer responsibility to cover this.

One thing that bothers me is that should the, let's call it a KERI-core be wrapped by another piece (library), that covers such common, yet not KERI-core related cases, so it provides a common understanding of ie. how to deal with these steps 1-3.

WDYT?

[bumblefudge]

Group agrees that these issues are out of scope of core KERI spec BUT will circle back when initiating a new work item to specify issues at this layer. Otherwise it's been noted and discussed in terms of interop/testing script assumptions.

[bumblefudge]

Waiting on spec additions to various KIDs

[chunningham]

We should keep in mind that proposal #140 will remove the interactive component of the delegation procedure and simplify the process.