CIBA: rt_hash and auth_req_id in ID Token from Token Endpoint

Issue #127 resolved
Takahiko Kawasaki created an issue

In the "push" mode, an ID token is directly issued to the client notification endpoint. The non-normative example of a base64url decoded ID token in "10.3.1. Successful Token Delivery" contains the following claims.

  • urn:openid:params:jwt:claim:rt_hash
  • urn:openid:params:jwt:claim:auth_req_id

On the other hand, the ID token in the non-normative example in "10.1.1. Successful Token Response", which is an ID token issued from the token endpoint, does not contain the claims. Is this difference intentional?

The ID token in 10.1.1. before decoding:


The payload part of the ID token in 10.1.1. after decoding:

  "iss": "",
  "sub": "248289761001",
  "aud": "s6BhdRkqt3",
  "email": "",
  "exp": 1537819803,
  "iat": 1537819503

BTW, it would be better to change the scheme part of the iss claim from http to https because 2. ID Token in OIDC Core 1.0 says as follows:


REQUIRED. Issuer Identifier for the Issuer of the response. The iss value is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.

Comments (14)

  1. Dave Tonge

    So this is definitely intentional.

    Those 2 claims are only needed in the push callback to ensure that the access/refresh tokens are bound to the id_token and the auth_req_id. This is because of the different security context of the push callback - the RP can't rely on the TLS connection to ensure that there has been no tampering with the values.

    When the tokens are retrieved via the token endpoint the RP is directly passing the auth_req_id to the OP and synchronously getting back the tokens. In this instance the RP can rely on the TLS connection to ensure that there is no tampering and that they are communicating directly with the OP.

    With regards to the http issuer, I suppose this is worth updating, what do you think @b_d_c ?

    @authlete-taka I would also like to know if you think its worth adding more text to explain why we need those values in the ID Token on the push callback?

  2. Takahiko Kawasaki reporter

    @dgtonge From an implementer's point of view, text to explain the reason is not necessary. I just worried about the possibility that lack of rt_hash and auth_req_id was unintentional. However, such explanation may be able to reduce the possibility that similar questions are posted and/or discussed again in the future. 😅

  3. Dave Tonge

    thanks @b_d_c @authlete-taka I think we probably do need some more text. And I think it should probably go in the security considerations section.

    I will propose some text.

  4. Brian Campbell

    The last sentence in that commit:

    However due to the different security properties of the Push Callback mode, implementers may want to consider the use of sender constrained tokens to further protect this mode.

    Which tokens and how would they be constrained (noting MTLS and TB are only defined to bind tokens issued from the token endpoint) and what protections does that give this mode specifically? That's meant to be kinda rhetorical.

    IMHO that last sentence should be removed. But otherwise it's quite good.

  5. Takahiko Kawasaki reporter

    I think it is well written. BTW,

    implementers may want to consider the use of sender constrained tokens to further protect this mode.

    This is interesting. In Poll and Ping modes, the client certificate used in the “token request” will be associated with the issued access token. But, in order to support certificate-bound access tokens in Push mode, the client certificate used in the “backchannel authentication request” is the only candidate for the binding.

  6. Takahiko Kawasaki reporter

    I'm wondering what CIBA-FAPI profile (?) which I imagine will be drafted after the CIBA Core spec is finalized will require for HoK.

  7. Dave Tonge

    @b_d_c thanks I'll resolve it.

    @authlete-taka we attempted to cover that in the current FAPI profile of CIBA. However I think we are now just going to take the easy route and restrict the use of Push mode for FAPI.

  8. Log in to comment