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

Issue #540 resolved
Joseph Heenan created an issue

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.

(This perhaps isn’t entirely an obvious topic for the FAPI working group, though given CIBA is already final it’s also not obvious where it should be handled, apparently Nat suggested to my colleagues that FAPI-CIBA could be an appropriate place.)

Comments (4)

  1. Brian Campbell

    A few thoughts:

    The omission of the claims request parameter in CIBA core was very much intentional. For lots of reasons.

    https://openid.bitbucket.io/ekyc/openid-connect-4-identity-assurance.html#name-requesting-sets-of-claims-b could certainly be used to make the two work together.

    There’s also RAR, which defines itself as usable w/ CIBA https://www.ietf.org/archive/id/draft-ietf-oauth-rar-12.html#name-authorization-request

    If using the claims request parameter in CIBA is really something ekyc-ida needs, I’d suggest that that WG is where that would be the appropriate place it should be handled.

  2. Takahiko Kawasaki

    Something that can do equivalent of the following is needed.

    {
      "id_token": {
        "verified_claims": { }
      },
      "userinfo": {
        "verified_claims": { }
      },
      "transformed_claims": { }
    }
    

    A simple mapping using RAR would become like below, for example.

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

    “Signed Authentication Request” of backchannel authentication request (CIBA) may be usable.

    {
      "claims": {
        "id_token": {
          "verified_claims": { }
        },
        "userinfo": {
          "verified_claims": { }
        },
        "transformed_claims": { }
      }
    }
    

    However, these approaches may conflict with the intention of the omission of the claims request parameter, which I don’t remeber (^_^;

  3. Log in to comment