PushDeliveryBindings Class
What a CIBA push notification's ID Token must bind itself to, so the notification cannot be replayed against a different request.
public record PushDeliveryBindings : System.IEquatable<Abblix.Oidc.Server.Features.Tokens.PushDeliveryBindings>Inheritance System.Object → PushDeliveryBindings
Implements System.IEquatable<PushDeliveryBindings>
Remarks
Its presence is what says "this delivery is a push". CIBA Core 1.0 Section 10.3.1 requires these claims in push mode and says so in as many words - "Note that these claims are only required in Push mode" - so a null here is a poll or a ping, or a flow that is not CIBA at all, and those ID Tokens are left exactly as they were.
The mode is CARRIED rather than inferred, and that is a choice rather than a necessity. It could be derived - the client's registered delivery mode is on the request, and combined with the grant type it identifies a push delivery. Two things argue against deriving it. The token processor would have to know CIBA's delivery rules to make that judgement, which couples the path every grant type takes to the semantics of one of them. And the derivation is a conjunction whose two halves are right for different reasons, so a later change to either silently moves who gets these claims - whereas the caller that IS the push path states the fact directly, and hands over the identifier it already holds in the same breath.
Push is also the one mode where the client never asked for these tokens by holding the identifier in its own hand. A poll client sends the identifier and reads the answer to that call; a push client receives an unsolicited body and has nothing tying its three parts together but this.
Constructors
PushDeliveryBindings(string, string) Constructor
What a CIBA push notification's ID Token must bind itself to, so the notification cannot be replayed against a different request.
public PushDeliveryBindings(string AuthenticationRequestId, string? RefreshToken);Parameters
AuthenticationRequestId System.String
The auth_req_id this delivery answers, carried into the
ID Token verbatim.
RefreshToken System.String
The refresh token travelling in the same notification, or null when none is sent - in which case the specification asks for no hash.
Remarks
Its presence is what says "this delivery is a push". CIBA Core 1.0 Section 10.3.1 requires these claims in push mode and says so in as many words - "Note that these claims are only required in Push mode" - so a null here is a poll or a ping, or a flow that is not CIBA at all, and those ID Tokens are left exactly as they were.
The mode is CARRIED rather than inferred, and that is a choice rather than a necessity. It could be derived - the client's registered delivery mode is on the request, and combined with the grant type it identifies a push delivery. Two things argue against deriving it. The token processor would have to know CIBA's delivery rules to make that judgement, which couples the path every grant type takes to the semantics of one of them. And the derivation is a conjunction whose two halves are right for different reasons, so a later change to either silently moves who gets these claims - whereas the caller that IS the push path states the fact directly, and hands over the identifier it already holds in the same breath.
Push is also the one mode where the client never asked for these tokens by holding the identifier in its own hand. A poll client sends the identifier and reads the answer to that call; a push client receives an unsolicited body and has nothing tying its three parts together but this.
Properties
PushDeliveryBindings.AuthenticationRequestId Property
The auth_req_id this delivery answers, carried into the
ID Token verbatim.
public string AuthenticationRequestId { get; init; }Property Value
PushDeliveryBindings.RefreshToken Property
The refresh token travelling in the same notification, or null when none is sent - in which case the specification asks for no hash.
public string? RefreshToken { get; init; }