11.7.1   sha256

This algorithm MUST be supported by clients and servers at a minimum. It is additionally the preferred algorithm for lookups.

When using this algorithm, the client converts the query first into strings separated by spaces in the format <address> <medium> <pepper>. The <pepper> is retrieved from /hash_details, the <medium> is typically email or msisdn (both lowercase), and the <address> is the 3PID to search for. For example, if the client wanted to know about alice@example.org's bindings, it would first format the query as alice@example.org email ThePepperGoesHere.

After formatting each query, the string is run through SHA-256 as defined by RFC 4634. The resulting bytes are then encoded using URL-Safe Unpadded Base64 (similar to room version 4's event ID format).

An example set of queries when using the pepper matrixrocks would be:

"alice@example.com email matrixrocks" -> "4kenr7N9drpCJ4AfalmlGQVsOn3o2RHjkADUpXJWZUc"
"bob@example.com email matrixrocks"   -> "LJwSazmv46n0hlMlsb_iYxI0_HXEqy_yj6Jm636cdT8"
"18005552067 msisdn matrixrocks"      -> "nlo35_T5fzSGZzJApqu8lgIudJvmOQtDaHtr-I4rU7I"

The set of hashes is then given as the addresses array in /lookup. Note that the pepper used MUST be supplied as pepper in the /lookup request.

11.7.2   none

This algorithm performs plaintext lookups on the identity server. Typically this algorithm should not be used due to the security concerns of unhashed identifiers, however some scenarios (such as LDAP-backed identity servers) prevent the use of hashed identifiers. Identity servers (and optionally clients) can use this algorithm to perform those kinds of lookups.

Similar to the sha256 algorithm, the client converts the queries into strings separated by spaces in the format <address> <medium> - note the lack of <pepper>. For example, if the client wanted to know about alice@example.org's bindings, it would format the query as alice@example.org email.

The formatted strings are then given as the addresses in /lookup. Note that the pepper is still required, and must be provided to ensure the client has made an appropriate request to /hash_details first.

12.2.1   Deprecated: POST /_matrix/identity/api/v1/validate/email/requestToken

Create a session for validating an email address.

The identity server will send an email containing a token. If that token is presented to the identity server in the future, it indicates that that user was able to read the email for that email address, and so we validate ownership of the email address.

Note that homeservers offer APIs that proxy this API, adding additional behaviour on top, for example, /register/email/requestToken is designed specifically for use when registering an account and therefore will inform the user if the email address given is already registered on the server.

Note: for backwards compatibility with previous drafts of this specification, the parameters may also be specified as application/x-form-www-urlencoded data. However, this usage is deprecated.

Request format:

Response format:

Example request:

POST /_matrix/identity/api/v1/validate/email/requestToken HTTP/1.1
Content-Type: application/json

{
  "client_secret": "monkeys_are_GREAT",
  "email": "foo@example.com",
  "send_attempt": 1
}

Responses:

Status code 200:

Session created.

Example

{
  "sid": "123abc"
}

Status code 400:

An error ocurred. Some possible errors are:

• M_INVALID_EMAIL: The email address provided was invalid.
• M_EMAIL_SEND_ERROR: The validation email could not be sent.

Example

{
  "errcode": "M_INVALID_EMAIL",
  "error": "The email address is not valid"
}

12.2.2   Deprecated: POST /_matrix/identity/api/v1/validate/email/submitToken

Validate ownership of an email address.

If the three parameters are consistent with a set generated by a requestToken call, ownership of the email address is considered to have been validated. This does not publish any information publicly, or associate the email address with any Matrix user ID. Specifically, calls to /lookup will not show a binding.

The identity server is free to match the token case-insensitively, or carry out other mapping operations such as unicode normalisation. Whether to do so is an implementation detail for the identity server. Clients must always pass on the token without modification.

Note: for backwards compatibility with previous drafts of this specification, the parameters may also be specified as application/x-form-www-urlencoded data. However, this usage is deprecated.

Request format:

Response format:

Example request:

POST /_matrix/identity/api/v1/validate/email/submitToken HTTP/1.1
Content-Type: application/json

{
  "sid": "1234",
  "client_secret": "monkeys_are_GREAT",
  "token": "atoken"
}

Response:

Status code 200:

The success of the validation.

Example

{
  "success": true
}

12.2.3   Deprecated: GET /_matrix/identity/api/v1/validate/email/submitToken

Validate ownership of an email address.

If the three parameters are consistent with a set generated by a requestToken call, ownership of the email address is considered to have been validated. This does not publish any information publicly, or associate the email address with any Matrix user ID. Specifically, calls to /lookup will not show a binding.

Note that, in contrast with the POST version, this endpoint will be used by end-users, and so the response should be human-readable.

Request format:

Example request:

GET /_matrix/identity/api/v1/validate/email/submitToken?sid=1234&client_secret=monkeys_are_GREAT&token=atoken HTTP/1.1

Responses:

Status code 200:

Email address is validated.

Status code 3xx:

Email address is validated, and the next_link parameter was provided to the requestToken call. The user must be redirected to the URL provided by the next_link parameter.

Status code 4xx:

Validation failed.

12.2.4   POST /_matrix/identity/v2/validate/email/requestToken

Create a session for validating an email address.

The identity server will send an email containing a token. If that token is presented to the identity server in the future, it indicates that that user was able to read the email for that email address, and so we validate ownership of the email address.

Note that homeservers offer APIs that proxy this API, adding additional behaviour on top, for example, /register/email/requestToken is designed specifically for use when registering an account and therefore will inform the user if the email address given is already registered on the server.

Note: for backwards compatibility with previous drafts of this specification, the parameters may also be specified as application/x-form-www-urlencoded data. However, this usage is deprecated.

Request format:

Response format:

Example request:

POST /_matrix/identity/v2/validate/email/requestToken HTTP/1.1
Content-Type: application/json

{
  "client_secret": "monkeys_are_GREAT",
  "email": "foo@example.com",
  "send_attempt": 1
}

Responses:

Status code 200:

Session created.

Example

{
  "sid": "123abc"
}

Status code 400:

An error ocurred. Some possible errors are:

• M_INVALID_EMAIL: The email address provided was invalid.
• M_EMAIL_SEND_ERROR: The validation email could not be sent.

Example

{
  "errcode": "M_INVALID_EMAIL",
  "error": "The email address is not valid"
}

Status code 403:

The user must do something in order to use this endpoint. One example is an M_TERMS_NOT_SIGNED error where the user must agree to more terms.

Example

{
  "errcode": "M_TERMS_NOT_SIGNED",
  "error": "Please accept our updated terms of service before continuing"
}

12.2.5   POST /_matrix/identity/v2/validate/email/submitToken

Validate ownership of an email address.

If the three parameters are consistent with a set generated by a requestToken call, ownership of the email address is considered to have been validated. This does not publish any information publicly, or associate the email address with any Matrix user ID. Specifically, calls to /lookup will not show a binding.

The identity server is free to match the token case-insensitively, or carry out other mapping operations such as unicode normalisation. Whether to do so is an implementation detail for the identity server. Clients must always pass on the token without modification.

Note: for backwards compatibility with previous drafts of this specification, the parameters may also be specified as application/x-form-www-urlencoded data. However, this usage is deprecated.

Request format:

Response format:

Example request:

POST /_matrix/identity/v2/validate/email/submitToken HTTP/1.1
Content-Type: application/json

{
  "sid": "1234",
  "client_secret": "monkeys_are_GREAT",
  "token": "atoken"
}

Responses:

Status code 200:

The success of the validation.

Example

{
  "success": true
}

Status code 403:

The user must do something in order to use this endpoint. One example is an M_TERMS_NOT_SIGNED error where the user must agree to more terms.

Example

{
  "errcode": "M_TERMS_NOT_SIGNED",
  "error": "Please accept our updated terms of service before continuing"
}

12.2.6   GET /_matrix/identity/v2/validate/email/submitToken

Validate ownership of an email address.

If the three parameters are consistent with a set generated by a requestToken call, ownership of the email address is considered to have been validated. This does not publish any information publicly, or associate the email address with any Matrix user ID. Specifically, calls to /lookup will not show a binding.

Note that, in contrast with the POST version, this endpoint will be used by end-users, and so the response should be human-readable.

Request format:

Example request:

GET /_matrix/identity/v2/validate/email/submitToken?sid=1234&client_secret=monkeys_are_GREAT&token=atoken HTTP/1.1

Responses:

Status code 200:

Email address is validated.

Status code 3xx:

Email address is validated, and the next_link parameter was provided to the requestToken call. The user must be redirected to the URL provided by the next_link parameter.

Status code 403:

The user must do something in order to use this endpoint. One example is an M_TERMS_NOT_SIGNED error where the user must agree to more terms.

Example

{
  "errcode": "M_TERMS_NOT_SIGNED",
  "error": "Please accept our updated terms of service before continuing"
}

Status code 4xx:

Validation failed.

12.3.1   Deprecated: POST /_matrix/identity/api/v1/validate/msisdn/requestToken

Create a session for validating a phone number.

The identity server will send an SMS message containing a token. If that token is presented to the identity server in the future, it indicates that that user was able to read the SMS for that phone number, and so we validate ownership of the phone number.

Note that homeservers offer APIs that proxy this API, adding additional behaviour on top, for example, /register/msisdn/requestToken is designed specifically for use when registering an account and therefore will inform the user if the phone number given is already registered on the server.

Note: for backwards compatibility with previous drafts of this specification, the parameters may also be specified as application/x-form-www-urlencoded data. However, this usage is deprecated.

Request format:

Response format:

Example request:

POST /_matrix/identity/api/v1/validate/msisdn/requestToken HTTP/1.1
Content-Type: application/json

{
  "client_secret": "monkeys_are_GREAT",
  "country": "GB",
  "phone_number": "07700900001",
  "send_attempt": 1
}

Responses:

Status code 200:

Session created.

Example

{
  "sid": "123abc"
}

Status code 400:

An error ocurred. Some possible errors are:

• M_INVALID_ADDRESS: The phone number provided was invalid.
• M_SEND_ERROR: The validation SMS could not be sent.
• M_DESTINATION_REJECTED: The identity server cannot deliver an SMS to the provided country or region.

Example

{
  "errcode": "M_INVALID_ADDRESS",
  "error": "The phone number is not valid"
}

12.3.2   Deprecated: POST /_matrix/identity/api/v1/validate/msisdn/submitToken

Validate ownership of a phone number.

If the three parameters are consistent with a set generated by a requestToken call, ownership of the phone number is considered to have been validated. This does not publish any information publicly, or associate the phone number address with any Matrix user ID. Specifically, calls to /lookup will not show a binding.

The identity server is free to match the token case-insensitively, or carry out other mapping operations such as unicode normalisation. Whether to do so is an implementation detail for the identity server. Clients must always pass on the token without modification.

Note: for backwards compatibility with previous drafts of this specification, the parameters may also be specified as application/x-form-www-urlencoded data. However, this usage is deprecated.

Request format:

Response format:

Example request:

POST /_matrix/identity/api/v1/validate/msisdn/submitToken HTTP/1.1
Content-Type: application/json

{
  "sid": "1234",
  "client_secret": "monkeys_are_GREAT",
  "token": "atoken"
}

Response:

Status code 200:

The success of the validation.

Example

{
  "success": true
}

12.3.3   Deprecated: GET /_matrix/identity/api/v1/validate/msisdn/submitToken

Validate ownership of a phone number.

If the three parameters are consistent with a set generated by a requestToken call, ownership of the phone number address is considered to have been validated. This does not publish any information publicly, or associate the phone number with any Matrix user ID. Specifically, calls to /lookup will not show a binding.

Note that, in contrast with the POST version, this endpoint will be used by end-users, and so the response should be human-readable.

Request format:

Example request:

GET /_matrix/identity/api/v1/validate/msisdn/submitToken?sid=1234&client_secret=monkeys_are_GREAT&token=atoken HTTP/1.1

Responses:

Status code 200:

Phone number is validated.

Status code 3xx:

Phone number address is validated, and the next_link parameter was provided to the requestToken call. The user must be redirected to the URL provided by the next_link parameter.

Status code 4xx:

Validation failed.

12.3.4   POST /_matrix/identity/v2/validate/msisdn/requestToken

Create a session for validating a phone number.

The identity server will send an SMS message containing a token. If that token is presented to the identity server in the future, it indicates that that user was able to read the SMS for that phone number, and so we validate ownership of the phone number.

Note that homeservers offer APIs that proxy this API, adding additional behaviour on top, for example, /register/msisdn/requestToken is designed specifically for use when registering an account and therefore will inform the user if the phone number given is already registered on the server.

Note: for backwards compatibility with previous drafts of this specification, the parameters may also be specified as application/x-form-www-urlencoded data. However, this usage is deprecated.

Request format:

Response format:

Example request:

POST /_matrix/identity/v2/validate/msisdn/requestToken HTTP/1.1
Content-Type: application/json

{
  "client_secret": "monkeys_are_GREAT",
  "country": "GB",
  "phone_number": "07700900001",
  "send_attempt": 1
}

Responses:

Status code 200:

Session created.

Example

{
  "sid": "123abc"
}

Status code 400:

An error ocurred. Some possible errors are:

• M_INVALID_ADDRESS: The phone number provided was invalid.
• M_SEND_ERROR: The validation SMS could not be sent.
• M_DESTINATION_REJECTED: The identity server cannot deliver an SMS to the provided country or region.

Example

{
  "errcode": "M_INVALID_ADDRESS",
  "error": "The phone number is not valid"
}

Status code 403:

The user must do something in order to use this endpoint. One example is an M_TERMS_NOT_SIGNED error where the user must agree to more terms.

Example

{
  "errcode": "M_TERMS_NOT_SIGNED",
  "error": "Please accept our updated terms of service before continuing"
}

12.3.5   POST /_matrix/identity/v2/validate/msisdn/submitToken

Validate ownership of a phone number.

If the three parameters are consistent with a set generated by a requestToken call, ownership of the phone number is considered to have been validated. This does not publish any information publicly, or associate the phone number address with any Matrix user ID. Specifically, calls to /lookup will not show a binding.

The identity server is free to match the token case-insensitively, or carry out other mapping operations such as unicode normalisation. Whether to do so is an implementation detail for the identity server. Clients must always pass on the token without modification.

Note: for backwards compatibility with previous drafts of this specification, the parameters may also be specified as application/x-form-www-urlencoded data. However, this usage is deprecated.

Request format:

Response format:

Example request:

POST /_matrix/identity/v2/validate/msisdn/submitToken HTTP/1.1
Content-Type: application/json

{
  "sid": "1234",
  "client_secret": "monkeys_are_GREAT",
  "token": "atoken"
}

Responses:

Status code 200:

The success of the validation.

Example

{
  "success": true
}

Status code 403:

The user must do something in order to use this endpoint. One example is an M_TERMS_NOT_SIGNED error where the user must agree to more terms.

Example

{
  "errcode": "M_TERMS_NOT_SIGNED",
  "error": "Please accept our updated terms of service before continuing"
}

12.3.6   GET /_matrix/identity/v2/validate/msisdn/submitToken

Validate ownership of a phone number.

If the three parameters are consistent with a set generated by a requestToken call, ownership of the phone number address is considered to have been validated. This does not publish any information publicly, or associate the phone number with any Matrix user ID. Specifically, calls to /lookup will not show a binding.

Note that, in contrast with the POST version, this endpoint will be used by end-users, and so the response should be human-readable.

Request format:

Example request:

GET /_matrix/identity/v2/validate/msisdn/submitToken?sid=1234&client_secret=monkeys_are_GREAT&token=atoken HTTP/1.1

Responses:

Status code 200:

Phone number is validated.

Status code 3xx:

Phone number address is validated, and the next_link parameter was provided to the requestToken call. The user must be redirected to the URL provided by the next_link parameter.

Status code 403:

The user must do something in order to use this endpoint. One example is an M_TERMS_NOT_SIGNED error where the user must agree to more terms.

Example

{
  "errcode": "M_TERMS_NOT_SIGNED",
  "error": "Please accept our updated terms of service before continuing"
}

Status code 4xx:

Validation failed.

12.4.1   Deprecated: GET /_matrix/identity/api/v1/3pid/getValidated3pid

Determines if a given 3pid has been validated by a user.

Request format:

Response format:

Example request:

GET /_matrix/identity/api/v1/3pid/getValidated3pid?sid=1234&client_secret=monkeys_are_GREAT HTTP/1.1

Responses:

Status code 200:

Validation information for the session.

Example

{
  "medium": "email",
  "validated_at": 1457622739026,
  "address": "louise@bobs.burgers"
}

Status code 400:

The session has not been validated.

If the session has not been validated, then errcode will be M_SESSION_NOT_VALIDATED. If the session has timed out, then errcode will be M_SESSION_EXPIRED.

Example

{
  "errcode": "M_SESSION_NOT_VALIDATED",
  "error": "This validation session has not yet been completed"
}

Status code 404:

The Session ID or client secret were not found.

Example

{
  "errcode": "M_NO_VALID_SESSION",
  "error": "No valid session was found matching that sid and client secret"
}

12.4.2   Deprecated: POST /_matrix/identity/api/v1/3pid/bind

Publish an association between a session and a Matrix user ID.

Future calls to /lookup for any of the session's 3pids will return this association.

Note: for backwards compatibility with previous drafts of this specification, the parameters may also be specified as application/x-form-www-urlencoded data. However, this usage is deprecated.

Request format:

Response format:

Example request:

POST /_matrix/identity/api/v1/3pid/bind HTTP/1.1
Content-Type: application/json

{
  "sid": "1234",
  "client_secret": "monkeys_are_GREAT",
  "mxid": "@ears:matrix.org"
}

Responses:

Status code 200:

The association was published.

Example

{
  "address": "louise@bobs.burgers",
  "medium": "email",
  "mxid": "@ears:matrix.org",
  "not_before": 1428825849161,
  "not_after": 4582425849161,
  "ts": 1428825849161,
  "signatures": {
    "matrix.org": {
      "ed25519:0": "ENiU2YORYUJgE6WBMitU0mppbQjidDLanAusj8XS2nVRHPu+0t42OKA/r6zV6i2MzUbNQ3c3MiLScJuSsOiVDQ"
    }
  }
}

Status code 400:

The association was not published.

If the session has not been validated, then errcode will be M_SESSION_NOT_VALIDATED. If the session has timed out, then errcode will be M_SESSION_EXPIRED.

Example

{
  "errcode": "M_SESSION_NOT_VALIDATED",
  "error": "This validation session has not yet been completed"
}

Status code 404:

The Session ID or client secret were not found

Example

{
  "errcode": "M_NO_VALID_SESSION",
  "error": "No valid session was found matching that sid and client secret"
}

12.4.3   Deprecated: POST /_matrix/identity/api/v1/3pid/unbind

Remove an association between a session and a Matrix user ID.

Future calls to /lookup for any of the session's 3pids will not return the removed association.

The identity server should authenticate the request in one of two ways:

1. The request is signed by the homeserver which controls the user_id.
2. The request includes the sid and client_secret parameters, as per /3pid/bind, which proves ownership of the 3PID.

If this endpoint returns a JSON Matrix error, that error should be passed through to the client requesting an unbind through a homeserver, if the homeserver is acting on behalf of a client.

Request format:

Example request:

POST /_matrix/identity/api/v1/3pid/unbind HTTP/1.1
Content-Type: application/json

{
  "sid": "1234",
  "client_secret": "monkeys_are_GREAT",
  "mxid": "@ears:example.org",
  "threepid": {
    "medium": "email",
    "address": "monkeys_have_ears@example.org"
  }
}

Responses:

Status code 200:

The association was successfully removed.

Example

{}

Status code 400:

If the response body is not a JSON Matrix error, the identity server does not support unbinds. If a JSON Matrix error is in the response body, the requesting party should respect the error.

Status code 403:

The credentials supplied to authenticate the request were invalid. This may also be returned if the identity server does not support the chosen authentication method (such as blocking homeservers from unbinding identifiers).

Example

{
  "errcode": "M_FORBIDDEN",
  "error": "Invalid homeserver signature"
}

Status code 404:

If the response body is not a JSON Matrix error, the identity server does not support unbinds. If a JSON Matrix error is in the response body, the requesting party should respect the error.

Status code 501:

If the response body is not a JSON Matrix error, the identity server does not support unbinds. If a JSON Matrix error is in the response body, the requesting party should respect the error.

12.4.4   GET /_matrix/identity/v2/3pid/getValidated3pid

Determines if a given 3pid has been validated by a user.

Request format:

Response format:

Example request:

GET /_matrix/identity/v2/3pid/getValidated3pid?sid=1234&client_secret=monkeys_are_GREAT HTTP/1.1

Responses:

Status code 200:

Validation information for the session.

Example

{
  "medium": "email",
  "validated_at": 1457622739026,
  "address": "louise@bobs.burgers"
}

Status code 400:

The session has not been validated.

If the session has not been validated, then errcode will be M_SESSION_NOT_VALIDATED. If the session has timed out, then errcode will be M_SESSION_EXPIRED.

Example

{
  "errcode": "M_SESSION_NOT_VALIDATED",
  "error": "This validation session has not yet been completed"
}

Status code 403:

The user must do something in order to use this endpoint. One example is an M_TERMS_NOT_SIGNED error where the user must agree to more terms.

Example

{
  "errcode": "M_TERMS_NOT_SIGNED",
  "error": "Please accept our updated terms of service before continuing"
}

Status code 404:

The Session ID or client secret were not found.

Example

{
  "errcode": "M_NO_VALID_SESSION",
  "error": "No valid session was found matching that sid and client secret"
}

12.4.5   POST /_matrix/identity/v2/3pid/bind

Publish an association between a session and a Matrix user ID.

Future calls to /lookup for any of the session's 3pids will return this association.

Note: for backwards compatibility with previous drafts of this specification, the parameters may also be specified as application/x-form-www-urlencoded data. However, this usage is deprecated.

Request format:

Response format:

Example request:

POST /_matrix/identity/v2/3pid/bind HTTP/1.1
Content-Type: application/json

{
  "sid": "1234",
  "client_secret": "monkeys_are_GREAT",
  "mxid": "@ears:matrix.org"
}

Responses:

Status code 200:

The association was published.

Example

{
  "address": "louise@bobs.burgers",
  "medium": "email",
  "mxid": "@ears:matrix.org",
  "not_before": 1428825849161,
  "not_after": 4582425849161,
  "ts": 1428825849161,
  "signatures": {
    "matrix.org": {
      "ed25519:0": "ENiU2YORYUJgE6WBMitU0mppbQjidDLanAusj8XS2nVRHPu+0t42OKA/r6zV6i2MzUbNQ3c3MiLScJuSsOiVDQ"
    }
  }
}

Status code 400:

The association was not published.

If the session has not been validated, then errcode will be M_SESSION_NOT_VALIDATED. If the session has timed out, then errcode will be M_SESSION_EXPIRED.

Example

{
  "errcode": "M_SESSION_NOT_VALIDATED",
  "error": "This validation session has not yet been completed"
}

Status code 403:

The user must do something in order to use this endpoint. One example is an M_TERMS_NOT_SIGNED error where the user must agree to more terms.

Example

{
  "errcode": "M_TERMS_NOT_SIGNED",
  "error": "Please accept our updated terms of service before continuing"
}

Status code 404:

The Session ID or client secret were not found

Example

{
  "errcode": "M_NO_VALID_SESSION",
  "error": "No valid session was found matching that sid and client secret"
}

12.4.6   POST /_matrix/identity/v2/3pid/unbind

Remove an association between a session and a Matrix user ID.

Future calls to /lookup for any of the session's 3pids will not return the removed association.

The identity server should authenticate the request in one of two ways:

1. The request is signed by the homeserver which controls the user_id.
2. The request includes the sid and client_secret parameters, as per /3pid/bind, which proves ownership of the 3PID.

If this endpoint returns a JSON Matrix error, that error should be passed through to the client requesting an unbind through a homeserver, if the homeserver is acting on behalf of a client.

Request format:

Example request:

POST /_matrix/identity/v2/3pid/unbind HTTP/1.1
Content-Type: application/json

{
  "sid": "1234",
  "client_secret": "monkeys_are_GREAT",
  "mxid": "@ears:example.org",
  "threepid": {
    "medium": "email",
    "address": "monkeys_have_ears@example.org"
  }
}

Responses:

Status code 200:

The association was successfully removed.

Example

{}

Status code 400:

If the response body is not a JSON Matrix error, the identity server does not support unbinds. If a JSON Matrix error is in the response body, the requesting party should respect the error.

Status code 403:

The credentials supplied to authenticate the request were invalid. This may also be returned if the identity server does not support the chosen authentication method (such as blocking homeservers from unbinding identifiers).

Another common error code is M_TERMS_NOT_SIGNED where the user needs to agree to more terms in order to continue.

Example

{
  "errcode": "M_FORBIDDEN",
  "error": "Invalid homeserver signature"
}

Status code 404:

If the response body is not a JSON Matrix error, the identity server does not support unbinds. If a JSON Matrix error is in the response body, the requesting party should respect the error.

Status code 501:

If the response body is not a JSON Matrix error, the identity server does not support unbinds. If a JSON Matrix error is in the response body, the requesting party should respect the error.