Use of eKYC-IDA spec with CIBA/FAPI-CIBA

[Joseph Heenan]

The CIBA spec & identity assurance specs don’t currently work together - the identity assurance defines extra members for the ‘claims’ request parameter defined in OpenID Connect Core, but CIBA doesn’t have the claims request parameter so there’s currently no way to request verified_claims using CIBA. There probably should be. [Technically requesting verified claims via scopes as per https://openid.bitbucket.io/ekyc/openid-connect-4-identity-assurance.html#section-6.6 still works, but you lose the full expressivity of the ida requests.]

Nat initially suggested to my colleagues that this could perhaps be solved somehow in the FAPI-CIBA spec, but when it was raised with the FAPI WG ( https://bitbucket.org/openid/fapi/issues/540/use-of-ekyc-ida-spec-with-ciba-fapi-ciba ) it was suggested it was looked at by the ekyc working group instead.

Note that the same problem likely affects using the “advanced syntax for claims” spec with CIBA too.

[Brian Campbell]

maybe the full expressiveness of ida requests isn’t necessary or even appropriate in CIBA

‌

[Takahiko Kawasaki]

A possible approach using RAR:

[
  {
    "type": "claims",
    "id_token": {
      "verified_claims": { }
    },
    "userinfo": {
      "verified_claims": { }
    },
    "transformed_claims": { }
  }
]

The structures of the id_token and userinfo in the example above are the same as those that may appear in the claims request parameter of OIDC Core, but they don’t necessarily have to provide the same full features as the claims request parameter provides. For example, we may define like “an only claim that is allowed to appear under id_token and userinfo is verified_claims“.

To use RAR, a concrete value for type must be defined. In the example above, claims is used as the value of type. But we may prefer a more collision-resilient value, like urn:ietf:params:oauth:authorization_details_type:claims.

[Takahiko Kawasaki]

A good point in using RAR is that the extension does not necessarily have to depend on CIBA or FAPI. The extension can be defined as a small profile (e.g. IDA-RAR profile) without invading other specifications.

Because the RAR specification is generic enough to allow the authorization_details parameter to appear at various places, the IDA-RAR profile also can be generic enough to allow various requests (not only the authorization request but also CIBA’s backchannel authentication request and Device Flow’s device authorization request) to include verified_claims.

[Mark Haine]

I have a feeling that this may be best dealt with by writing a small extension that is focussed on use of OIDC4IDA and RAR

It would be good to get @Torsten Lodderstedt to look at this though

[Torsten Lodderstedt]

I’m surprised. The CIBA spec to me is “just” another kind of grant type/ flow for OpenID Connect. I would like to understand why it does not support the “claims” parameter like any other OpenID Connect grant type/ flow. To me this seems like an oversight since all other authentication request parameters (except redirect_uri and nonce) have been mirrored in the CIBA spec.

[Takahiko Kawasaki]

@Torsten Lodderstedt I don’t remember the past discussion well, but @Brian Campbell told that there had been some reasons not to support the claims request parameter at the backchannel authentication endpoint. At first, I suggested adding the claims request parameter, but seeing Brian’s comment, now I’m suggesting a way that utilizes RAR.

[Mark Haine]

@Nat Sakimura suggested that @Bjorn Hjelm and @Dave Tonge have a look and comment on this issue.

2 questions

1. are there scenarios where the expressiveness of the claims request parametewr may be needed in the context of CIBA?
2. If previous answer is “yes” or “maybe” - which working group would be best to deal with this apparent gap?

‌

[Bjorn Hjelm]

Based on discussion at the last MODRNA WG call, it was agreed that (question 1) any scenarios where the expressiveness of the claims request parameter would (question 2) be best addressed in the MODRNA WG.

I hope this addresses the path forward for the eKYC-IDA WG. We will replicate this issue in the MODRNA WG as part of bringing this into the MODRNA WG.

[Bjorn Hjelm]

Per the discussion at the eKYC-IDA WG call, I’ve replicated the issue, #210, for the transition of the issue to the MODRNA WG.

[Mark Haine]

Transferred to MODRNA WG Issue #210