Integrate enmeshed

It is not yet possible to utilize the use cases regarding the IdentityDeletionProcesses mentioned below as an Integrator of a Connector. Instead, these functionalities are currently only offered to App users in order to be able to delete their Identity. Even if some use cases still have to be provided to the Integrators of Connectors for deleting their Identity, they benefit from the description of the process of Identity deletion given in this guide. Indeed, if an App user with whom a Connector has established a Relationship deletes their Identity, it is affected by side effects on this Relationship.

Regardless of whether an Identity is an App user or a Connector, it is stored on the Backbone. This guide describes the different options for Identity deletion from the Backbone. There is usually a predefined grace period in each process of Identity deletion, during which the Identity can cancel its deletion if it no longer wants to be deleted. Please note that an Identity can never trigger the process of deletion of another Identity.

IdentityDeletionProcesses

From a technical perspective, the process of Identity deletion is described by a data object of type IdentityDeletionProcess. It can be uniquely identified by its id. An IdentityDeletionProcess can have "WaitingForApproval", "Rejected", "Approved" or "Cancelled" as its status.

Please note that the feature of triggering the deletion of an Identity via the Backbone Admin UI is currently disabled. For this reason, an IdentityDeletionProcess currently cannot have "WaitingForApproval" as status. In addition, the use cases for approving and rejecting IdentityDeletionProcesses are not needed for the time being.

If an IdentityDeletionProcess has "WaitingForApproval" or "Approved" as status, it is also referred to as an active IdentityDeletionProcess. There can be at most one active IdentityDeletionProcess per Identity. There are three use cases for getting one or more already existing IdentityDeletionProcesses:

  • If the id of an IdentityDeletionProcess is known, it can be viewed by calling the Get IdentityDeletionProcess use case.
  • All IdentityDeletionProcesses of an Identity can be viewed by utilizing the Get IdentityDeletionProcesses use case. This includes IdentityDeletionProcesses with "Cancelled" or "Rejected" as status in particular.
  • The Get active IdentityDeletionProcess use case can be executed to view the currently active IdentityDeletionProcess if one exists. If none exists, the error code error.runtime.identityDeletionProcess.noActiveIdentityDeletionProcess will arise if an attempt is made to apply the use case anyway.

Options for Identity Deletion

In principle, there are several options for deleting an Identity from the Backbone. For example, depending on the Backbone environment, it is conceivable to set up automatic Identity deletion after a long period of Identity inactivity. More essential is the option of actively initiating the process of Identity deletion from the Backbone by the Identity itself. Whenever a new IdentityDeletionProcess has been created or the status of an existing IdentityDeletionProcess has changed, the Connector event transport.identityDeletionProcessStatusChanged is raised.

Self-Initiated Identity Deletion

An Identity can actively trigger its own process of deletion by executing the Initiate IdentityDeletionProcess use case. Successful execution leads to the creation of an IdentityDeletionProcess with "Approved" as status. No further approval of the Identity is required. Instead, the Identity is immediately in deletion and will be irreversibly deleted from the Backbone once the end of the associated grace period of the IdentityDeletionProcess specified within its gracePeriodEndsAt property has been reached. Within the grace period, the Cancel IdentityDeletionProcess use case can be applied by the Identity if it no longer wants to be deleted. In this case, the status of the IdentityDeletionProcess changes to "Cancelled". Trying to cancel an IdentityDeletionProcess that does not have "Approved" as status causes an error with error.runtime.identityDeletionProcess.noApprovedIdentityDeletionProcess as error code to be thrown. Furthermore, please note that the use of the Initiate IdentityDeletionProcess use case is not permitted if there is already an active IdentityDeletionProcess. The corresponding error code is given by error.runtime.identityDeletionProcess.activeIdentityDeletionProcessAlreadyExists.

Effects of Identity Deletion on Relationships

The initiation of the deletion of an Identity as well as the actual deletion logically have an impact on the peers who have established a Relationship with it. All peers of the Identity that is currently in deletion are informed that the deletion of the Identity has been initiated. This is done via the transport.peerToBeDeleted Connector event. In addition, it is stored within the peerDeletionInfo property of the Relationship that the Identity currently has "ToBeDeleted" as deletionStatus. The status of the Relationship remains "Active" for the time being. If the Identity is finally deleted, the deletionStatus will change to "Deleted" and the Connector event transport.peerDeleted can be received. Since the deletion of an Identity leads to the decomposition of its Relationships, the status of the Relationship is changed to "DeletionProposed" and "DecompositionDueToIdentityDeletion" is specified as the reason of the associated RelationshipAuditLogEntry. Otherwise, if the Identity decides against its deletion within the grace period, the peerDeletionInfo of the Relationship is set back to undefined and the transport.peerDeletionCancelled Connector event is triggered. The deletion of an Identity has effects on creating a new Relationship to it, sending Messages to it, sending Requests to it and responding to Requests from it.

Creation of New Relationships

To establish a Relationship, an Identity must first create a RelationshipTemplate, which is then used by its peer to create a Relationship with "Pending" as status. However, if the creator of the RelationshipTemplate is meanwhile in deletion or has already deleted itself, the peer will receive an error with error code error.transport.relationships.activeIdentityDeletionProcessOfOwnerOfRelationshipTemplate or error.transport.relationships.deletedOwnerOfRelationshipTemplate, respectively, when trying to create a new Relationship using the RelationshipTemplate.

Sending Messages

An Identity is not permitted to send a Message to a peer with which a Relationship has been established if the peer has already been deleted. As long as the content of a Message is not a Notification, this also applies to a peer in deletion. If the Identity tries to send a Message anyway to such a peer, an error with error code error.runtime.messages.peerIsInDeletion or error.transport.messages.peerIsDeleted is thrown. Sent Messages whose content is a Notification cannot be received by a peer which is in deletion, but they are queued in case the peer cancels its deletion. After the peer has cancelled its deletion, it receives the queued Notifications.

Sending and Responding to Requests

An incoming Request sent by an Identity with which a Relationship has been established cannot be responded to if the Identity is in deletion or has already been deleted. If an attempt is nevertheless made to accept or reject the incoming Request, an error with code error.consumption.requests.peerIsInDeletion or error.consumption.requests.peerIsDeleted, respectively, is thrown. Similarly, it is not possible to create an outgoing Request to be sent to an Identity with which a Relationship has been established and which is in deletion or has already been deleted.