CIBA: rt_hash and auth_req_id in ID Token from Token Endpoint

[Takahiko Kawasaki]

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:

eyJhbGciOiJSUzI1NiIsImtpZCI6IjE2NzcyNiJ9.eyJpc3MiOiJ
odHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwic3ViIjoiMjQ4Mjg5NzYxMDAxIiw
iYXVkIjoiczZCaGRSa3F0MyIsImVtYWlsIjoiamFuZWRvZUBleGFtcGxlLmNvbSI
sImV4cCI6MTUzNzgxOTgwMywiaWF0IjoxNTM3ODE5NTAzfQ.LW5TN_gGHzRSNb4Y
8UIQCoXEwRVW-BYf60I0nVxKHWM968CKdCyK4DlSBS2Fw6wk92cbHCsL0hjAaLyy
xHcaPjAmKLkJV6gS9sgWye8Oo_f2EbacV7igICM_0nTNYq4OH0AHmgHWbF_abmjx
P2abYYXX-CKmx9S3CPvW65lakh2yFXNkB5_u-RYmJQFpY2MQpOG-2qu0SbzeRkxG
AYG2xOi2aVCSEztl5jD1N5OH9EKS8bl5Rsp3kdgpRiMADVYYLqDM7U1Y5ucpLyy6
tboJQNkEUPfjff1lxkrI1RRqjxDHR8yqIJ2ak8DClTvaKeC8faBRX-_QbSPFEEjH
ust2eQ

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

{
  "iss": "http://server.example.com",
  "sub": "248289761001",
  "aud": "s6BhdRkqt3",
  "email": "[e-mail]",
  "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:

iss

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.

[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?

[Takahiko Kawasaki]

@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. 😅

[Brian Campbell]

Agree that http issuer should be updated and I'll take care of it.

[Brian Campbell]

examples now use https for iss per b7eb8b2

[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.

[Dave Tonge]

@authlete-taka @b_d_c I've pushed this commit: https://bitbucket.org/openid/mobile/commits/f8a6db8222066acdc2e45658217c77dd437ab9ae

I'd be grateful for your review, but I felt that we do need to call out the different security properties of the Push mode.

[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.

[Dave Tonge]

Sure, I was struggling with it as well. I'll remove the last sentence.

[Brian Campbell]

and 7d859c0 looks good @dgtonge - thanks for that. I think this one can be resolved?

[Takahiko Kawasaki]

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.

[Takahiko Kawasaki]

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

[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.

[Brian Campbell]

+1 for easy route :)