DIP-150 Update spec to include details of un-delegation on past data/batches

[saraswatpuneet]

Abstract

Updating spec with details about outcomes, of removing delegation, have on batch announcements, historical [delegated] announcements

Motivation

• Currently a dsnp user can revoke delegation from past.
• How batch validation handle such cases where batches have un-delegated user
• Does ability to remove delegation in past still holds true? If not, then should user tombstone past content/announcements

Specification Pull Request

Current change pull request: https://github.com/LibertyDSNP/spec/pull/186

Rationale

DSNP 1.0 allows a dsnp user to revoke delegation from past. This proposal extends a discussion to update spec with planned procedure around de-delegation and its affects on newest batches as well as ownership.

Backwards Compatibility

• This is a breaking change

Reference Implementation and/or Tests

• https://spec.dsnp.org/DSNP/Identity#delegation
• https://spec.dsnp.org/DSNP/BatchPublications

Security Considerations

Ensuring a delegate was still delegated to by dsnp user before the batch was published. Considerations around ownership of historical announcements

With reference to https://github.com/LibertyDSNP/spec/issues/145 enabling user trust to delegate, how do we ensure trust between delegate and dsnp (Only upto a block in future it will be allowed to publish such batches?)

Dependencies

None

References

None

Copyright

Copyright and related rights waived via CC0.

[wilwade]

Notes from DSNP Spec meeting 2022-03-31

Alternative / Additional Details for DIP-150:

• Allow revocation of delegation in the past, but the delegation is valid for batch validation for now + n blocks.
• Effectively "tombstoning" all messages from a user + delegate from a given block number
• So we store two pieces of information on undelgation when it happened, and how much the user asked to remove from the record.

Data

• Undelegation block number
  • generated and stored by the chain in the transaction
  • value + n blocks of slippage for batch validation
• Revoke block number
  • requested by the user
  • effectively a mass tombstone based on DSNP Id + Delegate + block number >= revoke block number

If you want to leave a delegate, but not remove the data you created via that delegate, then just consider undelegation block number == "revoke from block number" (needs a better name)

Why do I want to remove a delegate in the past?

• Bad delegate doing things without my permission
• EU Right to be forgotten?
  • This might be more than the law requires, but that might be good.
  • https://curia.europa.eu/juris/document/document.jsf?text=&docid=163494&pageIndex=0&doclang=EN&mode=req&dir=&occ=first&part=1&cid=10850128

Issues:

• Mixing two things a user might want: leaving a delegate and punishing a delegate

[wilwade]

Another alternative via @enddynayn

Delegation can only be revoked at a given point in time (just like above). (slippage given for batch validation). Reduce the choice from choosing a block number to all or nothing

User Stories:

• As a DSNP user I want to stop using a delegate such that the delegate can no longer pass any NEW messages on my behalf
• As a DSNP user I want to stop using a delegate and have the network act as if I NEVER delegated to that delegate in the first place.

User Story for the block number version:

• As a DSNP user I want to stop using a delegate such that the delegate can no longer pass any NEW messages on my behalf and act as if I tombstoned all messages from that delegate from a given point in time.

[jvasile]

A lot of the bulk tombstoning could be handled in UI that lets users identify and select a group of messages, then fire off a lot of tombstone actions. @enddynayn is right that baking this in at the protocol level is a convenience or an efficiency, but not a base requirement. And that edges me over into thinking that we could leave this for later without catastrophic consequences.

[wilwade]

Closed with #186