#### [Abblix\.Oidc\.Server](https://www.abblix.com/en/docs/api/abblix-oidc-server 'index') ### [Abblix\.Oidc\.Server\.Features\.Tokens](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Features.Tokens 'Abblix\.Oidc\.Server\.Features\.Tokens') ## PushDeliveryBindings Class What a CIBA push notification's ID Token must bind itself to, so the notification cannot be replayed against a different request\. ```csharp public record PushDeliveryBindings : System.IEquatable ``` Inheritance [System\.Object](https://learn.microsoft.com/en-us/dotnet/api/system.object 'System\.Object') → PushDeliveryBindings Implements [System\.IEquatable<](https://learn.microsoft.com/en-us/dotnet/api/system.iequatable-1 'System\.IEquatable\`1')[PushDeliveryBindings](https://www.abblix.com/en/docs/api/abblix-oidc-server/Abblix.Oidc.Server.Features.Tokens.PushDeliveryBindings 'Abblix\.Oidc\.Server\.Features\.Tokens\.PushDeliveryBindings')[>](https://learn.microsoft.com/en-us/dotnet/api/system.iequatable-1 'System\.IEquatable\`1') ### 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 {#Abblix.Oidc.Server.Features.Tokens.PushDeliveryBindings.PushDeliveryBindings(string,string)} What a CIBA push notification's ID Token must bind itself to, so the notification cannot be replayed against a different request\. ```csharp public PushDeliveryBindings(string AuthenticationRequestId, string? RefreshToken); ``` #### Parameters ###### `AuthenticationRequestId` [System\.String](https://learn.microsoft.com/en-us/dotnet/api/system.string 'System\.String') {#Abblix.Oidc.Server.Features.Tokens.PushDeliveryBindings.PushDeliveryBindings(string,string).AuthenticationRequestId} The `auth_req_id` this delivery answers, carried into the ID Token verbatim\. ###### `RefreshToken` [System\.String](https://learn.microsoft.com/en-us/dotnet/api/system.string 'System\.String') {#Abblix.Oidc.Server.Features.Tokens.PushDeliveryBindings.PushDeliveryBindings(string,string).RefreshToken} The refresh token travelling in the same notification, or [null](https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/null 'https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/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 {#Abblix.Oidc.Server.Features.Tokens.PushDeliveryBindings.AuthenticationRequestId} The `auth_req_id` this delivery answers, carried into the ID Token verbatim\. ```csharp public string AuthenticationRequestId { get; init; } ``` #### Property Value [System\.String](https://learn.microsoft.com/en-us/dotnet/api/system.string 'System\.String') ## PushDeliveryBindings\.RefreshToken Property {#Abblix.Oidc.Server.Features.Tokens.PushDeliveryBindings.RefreshToken} The refresh token travelling in the same notification, or [null](https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/null 'https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/null') when none is sent \- in which case the specification asks for no hash\. ```csharp public string? RefreshToken { get; init; } ``` #### Property Value [System\.String](https://learn.microsoft.com/en-us/dotnet/api/system.string 'System\.String')