#### [Abblix\.SecurityEvents](https://www.abblix.com/en/docs/api/abblix-securityevents 'index')
### [Abblix\.SecurityEvents\.BackChannelLogout](https://www.abblix.com/en/docs/api/abblix-securityevents/Abblix.SecurityEvents.BackChannelLogout 'Abblix\.SecurityEvents\.BackChannelLogout')

## BackChannelLogoutError Class

How an RP tells a provider that a logout request was bad: the optional body of the 400 response
\(OpenID Connect Back\-Channel Logout 1\.0 Section 2\.8\)\.

```csharp
public sealed record BackChannelLogoutError : System.IEquatable<Abblix.SecurityEvents.BackChannelLogout.BackChannelLogoutError>
```

Inheritance [System\.Object](https://learn.microsoft.com/en-us/dotnet/api/system.object 'System\.Object') → BackChannelLogoutError

Implements [System\.IEquatable&lt;](https://learn.microsoft.com/en-us/dotnet/api/system.iequatable-1 'System\.IEquatable\`1')[BackChannelLogoutError](https://www.abblix.com/en/docs/api/abblix-securityevents/Abblix.SecurityEvents.BackChannelLogout.BackChannelLogoutError 'Abblix\.SecurityEvents\.BackChannelLogout\.BackChannelLogoutError')[&gt;](https://learn.microsoft.com/en-us/dotnet/api/system.iequatable-1 'System\.IEquatable\`1')

### Remarks
The same shape as a push delivery's error and deliberately not the same type\. Section 2\.8 sends
the reader to "Section 5\.2 of OAuth 2\.0" for these parameters, so they travel as `error`
and `error_description`, where a SET delivery's travel as `err` and
`description` \(RFC 8935 Section 2\.3\)\. One record serving both would put one vocabulary's
names on the other's wire\.

Section 2.8 also says what the body is for and what it is not for: "the information conveyed in
the response body is intended to help debug deployments; it is not intended that
implementations use different error values to trigger different runtime behaviors." So the
description is where the detail belongs, and the code stays coarse.
### Constructors

## BackChannelLogoutError\(string, string\) Constructor {#Abblix.SecurityEvents.BackChannelLogout.BackChannelLogoutError.BackChannelLogoutError(string,string)}

How an RP tells a provider that a logout request was bad: the optional body of the 400 response
\(OpenID Connect Back\-Channel Logout 1\.0 Section 2\.8\)\.

```csharp
public BackChannelLogoutError(string Error, string Description);
```
#### Parameters

###### `Error` [System\.String](https://learn.microsoft.com/en-us/dotnet/api/system.string 'System\.String') {#Abblix.SecurityEvents.BackChannelLogout.BackChannelLogoutError.BackChannelLogoutError(string,string).Error}

The error code\. Section 2\.8 names only `invalid_request`\.

###### `Description` [System\.String](https://learn.microsoft.com/en-us/dotnet/api/system.string 'System\.String') {#Abblix.SecurityEvents.BackChannelLogout.BackChannelLogoutError.BackChannelLogoutError(string,string).Description}

A human\-readable account of what failed \- the half an operator on the provider's side reads\.
Optional by Section 2\.8, always supplied here, since a code this coarse says almost nothing on
its own\.

### Remarks
The same shape as a push delivery's error and deliberately not the same type\. Section 2\.8 sends
the reader to "Section 5\.2 of OAuth 2\.0" for these parameters, so they travel as `error`
and `error_description`, where a SET delivery's travel as `err` and
`description` \(RFC 8935 Section 2\.3\)\. One record serving both would put one vocabulary's
names on the other's wire\.

Section 2.8 also says what the body is for and what it is not for: "the information conveyed in
the response body is intended to help debug deployments; it is not intended that
implementations use different error values to trigger different runtime behaviors." So the
description is where the detail belongs, and the code stays coarse.
### Fields

## BackChannelLogoutError\.InvalidRequest Field {#Abblix.SecurityEvents.BackChannelLogout.BackChannelLogoutError.InvalidRequest}

The one code the specification names: "An error value of `invalid_request` MAY be used
to indicate that there was a problem with the syntax of the logout request\."

```csharp
public const string InvalidRequest = "invalid_request";
```

#### Field Value
[System\.String](https://learn.microsoft.com/en-us/dotnet/api/system.string 'System\.String')
### Properties

## BackChannelLogoutError\.Description Property {#Abblix.SecurityEvents.BackChannelLogout.BackChannelLogoutError.Description}

A human\-readable account of what failed \- the half an operator on the provider's side reads\.
Optional by Section 2\.8, always supplied here, since a code this coarse says almost nothing on
its own\.

```csharp
public string Description { get; init; }
```

#### Property Value
[System\.String](https://learn.microsoft.com/en-us/dotnet/api/system.string 'System\.String')

## BackChannelLogoutError\.Error Property {#Abblix.SecurityEvents.BackChannelLogout.BackChannelLogoutError.Error}

The error code\. Section 2\.8 names only `invalid_request`\.

```csharp
public string Error { get; init; }
```

#### Property Value
[System\.String](https://learn.microsoft.com/en-us/dotnet/api/system.string 'System\.String')
