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).
public sealed record BackChannelLogoutError : System.IEquatable<Abblix.SecurityEvents.BackChannelLogout.BackChannelLogoutError>Inheritance System.Object → BackChannelLogoutError
Implements System.IEquatable<BackChannelLogoutError>
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
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).
public BackChannelLogoutError(string Error, string Description);Parameters
Error System.String
The error code. Section 2.8 names only invalid_request.
Description System.String
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
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."
public const string InvalidRequest = "invalid_request";Field Value
Properties
BackChannelLogoutError.Description Property
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.
public string Description { get; init; }Property Value
BackChannelLogoutError.Error Property
The error code. Section 2.8 names only invalid_request.
public string Error { get; init; }