# Identity.Delete Request

A user can use the identity.delete request to delete an indirectly connected device identity only. It is not possible to delete the identity for a directly connected device via this request. The request will alert the platform to route the request to the principal manager to delete a device identity. An identity.delete action message is sent to the platform by a connected device (i.e. Edge) via IoTHub.

In the Principal Manager, the Request identity must exist and must be connected via the directly connected device (i.e. Edge)

# Idempotency

This request is idempotent, meaning that sending several identical requests will result in the identity being successfully deleted in PM. One of the two following outcomes will occur due to this design:

  • First delete of an existing identity will be successful
  • Following deletes of this identity will be rejected

# Event Properties

# Unique Message Headers

Property Mandatory Description
parent Optional A parent of identity that needs to be removed, as a relative path. This identity must already exist and must be connected via this directly connected device. If absent, a directly connected device is a parent of this new identity

# Message Body

Property Mandatory Data Type Description
identity Mandatory string Identity that needs to be removed, must be unique within the parent

# Message format

The identity.delete action message has the following format when it is received and ready for processing. This example only shows data relevant for message processing.

{
    "action": "identity.delete",
    "msgType": "action",
    "version": 2,
    "ack": "<ack>",
    "correlationId": "<GUID>",
    "target": "<connected device path>",
    "parent": "<relative path>",
    "body": {
      "identity": "<identity value>"
    }
}

# Expected Acknowledgment Responses

# Positive Acknowledgement

{
  "properties": {
    "msgType": "ack",
    "action": "identity.delete",
    "correlationId": "<correlation id>",
    "version": 2,
    "target": "<some_target>"
  },
  "body": {
    "success": true,
    "code": "<error code>",
    "detail": "<error detail>",
    "parent": "<parent from the identity.delete message>",
    "identity": "<identity from the identity.delete message>"
  }
}

# Negative Acknowledgement

{
  "properties": {
    "msgType": "ack",
    "action": "identity.delete",
    "correlationId": "<correlation id>",
    "version": 2,
    "target": "<some_target>"
  },
  "body": {
    "success": false,
    "code": "<error code>",
    "detail": "<error detail>",
  }

# Validation Rules

DCS validates all message properties, message body is in proper JSON format. DCS does not validate message body property identity as specified in the summary of all v2 Device API messages. Message body is then passed to Region API DELETE /devices/{deviceId} endpoint where the remaining validation is performed.

# Functionality

# Description

The device principal for requested identity is deleted in PM when the message is ingested. DCS will never send back a 'request-response' notification message. Any platform events generated by the IM service related to this request are ignored by the DCS. If requested, an acknowledgement c2d message can be sent back to the directly connected device where it can also be propagated further if needed (based on target).

# Error handling

When an error occurs the error information is logged inside platform in the Azure Portal on the Application Insight blade.

If a response can be delivered back to device then the acknowledgments are sent back to device, only if requested. More details can be found here: Acknowledgement Handling

Last updated: 9/6/2021, 1:25:50 PM
Feedback