[Openid-specs-mobile-profile] Issue #127: CIBA: rt_hash and auth_req_id in ID Token from Token Endpoint (openid/mobile)

[Takahiko Kawasaki]

New issue 127: CIBA: rt_hash and auth_req_id in ID Token from Token Endpoint
https://bitbucket.org/openid/mobile/issues/127/ciba-rt_hash-and-auth_req_id-in-id-token

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:


```
#!json

{
  "iss": "http://server.example.com",
  "sub": "248289761001",
  "aud": "s6BhdRkqt3",
  "email": "janedoe at example.com",
  "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](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) 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.