- edited description
Use of eKYC-IDA spec with CIBA/FAPI-CIBA
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.
Comments (11)
-
reporter -
maybe the full expressiveness of ida requests isn’t necessary or even appropriate in CIBA
-
A possible approach using RAR:
[ { "type": "claims", "id_token": { "verified_claims": { } }, "userinfo": { "verified_claims": { } }, "transformed_claims": { } } ]
The structures of the
id_token
anduserinfo
in the example above are the same as those that may appear in theclaims
request parameter of OIDC Core, but they don’t necessarily have to provide the same full features as theclaims
request parameter provides. For example, we may define like “an only claim that is allowed to appear underid_token
anduserinfo
isverified_claims
“.To use RAR, a concrete value for
type
must be defined. In the example above,claims
is used as the value oftype
. But we may prefer a more collision-resilient value, likeurn:ietf:params:oauth:authorization_details_type:claims
. -
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 includeverified_claims
. -
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
-
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.
-
@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 theclaims
request parameter, but seeing Brian’s comment, now I’m suggesting a way that utilizes RAR. -
@Nat Sakimura suggested that @Bjorn Hjelm and @Dave Tonge have a look and comment on this issue.
2 questions
- are there scenarios where the expressiveness of the claims request parametewr may be needed in the context of CIBA?
- If previous answer is “yes” or “maybe” - which working group would be best to deal with this apparent gap?
-
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.
-
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.
-
- changed status to resolved
Transferred to MODRNA WG Issue #210
- Log in to comment