Integrate enmeshed

The exact process of deleting an Attribute depends on the kind of Attribute at hand. Creating an Attribute, we must distinguish between IdentityAttributes and RelationshipAttributes. In the former case, a so-called OwnIdentityAttribute is created. Afterwards, you may share it with a peer, which yields the creation of associated AttributeForwardingDetails. Doing so, also a PeerIdentityAttribute with the same content is created for the peer. In the case of RelationshipAttributes we have OwnRelationshipAttributes and PeerRelationshipAttributes. Analogeously, sharing an OwnRelationshipAttribute or a PeerRelationshipAttribute with a third party leads to the the creation of associated AttributeForwardingDetails for the emitter and a ThirdPartyRelationshipAttribute for the third party. These different kinds of Attributes have different demands that need to be taken into account, wanting to delete them. For example, it is straightforward to delete an OwnIdentityAttribute that has not been shared with a peer. To delete such an Attribute, simply specify its attributeId.

In general, you can only delete data from your own wallet and never from the peer’s. So, for example you can delete Attributes a peer shared with you from your wallet, but you can’t delete Attributes you shared with a peer from their wallet. Wanting to do so, you need to send a Request to the peer, asking them to delete the respective Attribute. Note that this doesn’t automatically delete their Attribute, since the peer may have a valid reason to still keep it for a certain amount of time.

Request the deletion of emitted Attributes from recipient

Wanting to delete an emitted Attribute from its recipient technically describes the endeavor of withdrawing the permission you gave them to use your Attribute. To this end, a Request must be used with a DeleteAttributeRequestItem. As a parameter, the attributeId of the Attribute you would like the recipient to delete must be provided. Note, that the Attribute at the recipient’s side has the same id like the emitted Attribute at your side. A possible Request for deleting an Attribute could look as follows:

{
  "@type": "Request",
  "items": [
    {
      "@type": "DeleteAttributeRequestItem",
      "mustBeAccepted": true,
      "attributeId": "<ID of emitted Attribute>"
    }
  ]
}

Of course, it is also possible to request the deletion of multiple Attributes within a single Request. For this purpose, several DeleteAttributeRequestItems or suitable RequestItemGroups can be inserted into the items property of the Request.

Before sending the Request, we recommend to validate its content, since this will give you additional information in case of an error.

Next, send the Request to the Attribute recipient. You can either do so by Message or by a RelationshipTemplate, using the onExistingRelationship property of a RelationshipTemplateContent. For a detailed explanation check out our guides on how to send Requests via Messages and Requests via RelationshipTemplates. Once the Request is sent, the AttributeForwardingDetails associated with the emitted Attribute of the Sender or the emitted Attribute itself, in case it is an OwnRelationshipAttribute and the deletion of the PeerRelationshipAttribute is requested from the peer, get an EmittedAttributeDeletionInfo. There, "DeletionRequestSent" is set as deletionStatus and the time of sending the Request is stored as deletionDate.

When the recipient receives the Request, they can accept or reject it. If they want to accept it, they must use the AcceptDeleteAttributeRequestItemParameters. Doing so, they specify a deletionDate on which they plan to delete the received Attribute. In the given example, the payload would look like the following:

{
  "items": [
    {
      "accept": true,
      "deletionDate": "<date the received Attribute will be deleted>"
    }
  ]
}

Now, the enmeshed Runtime sets the deletionInfo of the corresponding Attribute of the recipient with deletionStatus "ToBeDeleted" and the specified deletionDate. The same is done for all predecessors of the received Attribute. Then, the appropriate DeleteAttributeAcceptResponseItem is generated and sent back in the Reponse to the Sender of the Request. There, the deletionInfo of the corresponding emitted Attribute and its predecessors, in case it is an OwnRelationshipAttribute and the deletion of the PeerRelationshipAttribute was requested from the peer, or of the associated AttributeForwardingDetails is set with deletionStatus "ToBeDeletedByRecipient" and the deletionDate received in the Response.

It is also possible for the recipient to reject the DeleteAttributeRequestItem, if its mustBeAccepted property is set false, or to reject the Request for deleting a received Attribute as a whole, if they have a valid reason for keeping the respective received Attribute. In this case, the RejectRequestItemParameters must be used and it is advised to provide a message, informing the Sender of the Request about the reason not to delete the received Attribute. Receiving the Response with the RejectResponseItem, the emitted Attribute of the Sender, in case it is an OwnRelationshipAttribute and the deletion of the PeerRelationshipAttribute was requested from the peer, or the associated AttributeForwardingDetails are given "DeletionRequestRejected" as deletionStatus and the receiving time is stored in the property deletionDate.

Delete received Attributes

The actual deletion of a received Attribute happens in a separate step. This can either be triggered if the deletionInfo.deletionDate is reached, in case the deletion was requested by the emitter of the Attribute, or if the recipient decides they no longer need it.

To delete a received Attribute, only its attributeId must be specified. Internally, not just the given Attribute is deleted, but also all its predecessors, in case there were any. Moreover, if the received Attribute had a successor, its succeeds property will be set to undefined, as the corresponding predecessor no longer exists. Then, a Notification with a ForwardedAttributeDeletedByPeerNotificationItem or a PeerRelationshipAttributeDeletedByPeerNotificationItem is generated and sent to the emitter of the Attribute, informing them that you deleted the Attribute they shared with you. Consequently, the deletionInfo of their corresponding emitted Attribute and of all potential predecessors, in case it is an OwnRelationshipAttribute and the PeerRelationshipAttribute was deleted by the peer, or of the associated AttributeForwardingDetails is updated with deletionStatus "DeletedByRecipient" and the time of receiving the Notification as deletionDate. In case the emitter already deleted their Attribute, nothing happens. Please further note that the Notification is queued if the Relationship is currently terminated but not yet decomposed. It can then only be received and processed if the Relationship is reactivated. The Notification is also queued if the Attribute recipient is currently in deletion but not yet deleted. It can then only be received and processed if the Attribute recipient cancels its deletion.

Delete emitted Attributes

The emitter can always delete their LocalAttributes without having to ask for consent. Then, associated AttributeForwardingDetails are deleted as well. Doing so before the recipient deleted their copy of the shared Attribute, however, you lose the information of having shared the Attribute with them and whether they keep their Attribute or delete it. Thus, we recommend to request the deletion of emitted Attributes from their recipients before deleting them yourself.

If you decide to delete an emitted Attribute, you must specifiy its attributeId. Then, in addition to the emitted Attribute itself, also all its predecessors will be deleted, given there were any. Moreover, if the emitted Attribute had a successor, its succeeds property will be set to undefined, as the corresponding predecessor no longer exists. Then, a Notification with an OwnAttributeDeletedByOwnerNotificationItem or a PeerRelationshipAttributeDeletedByPeerNotificationItem is generated and sent to the recipient you shared the Attribute with, informing them that you deleted that Attribute. If they already deleted their corresponding Attribute or marked it for deletion, nothing will change. However, if the deletionInfo of their Attribute was undefined before, since you didn’t send a Request for Attribute deletion or the Request was rejected, a deletionInfo will be set. Its deletionStatus will be set to "DeletedByEmitter" and the deletionDate will be the time of receiving the Notification. Please note that the Notification is queued if the Relationship is currently terminated but not yet decomposed. It can then only be received and processed if the Relationship is reactivated. Furthermore, the Notification is also queued if the Attribute recipient is currently in deletion but not yet deleted. It can then only be received and processed if the Attribute recipient cancels its deletion.