[Openid-specs-fapi] CIBA and delivery of OIDC claims requested by scope shorthand

[Joseph Heenan]

Hi Vladimir,

To add my 2 cents:

There’s not current any conformance tests for FAPI-CIBA that cover requesting claim with scopes. (Though it may be worth adding one perhaps; https://bitbucket.org/openid/fapi/issues/475/certification-fapi2-baseline-is-openid <https://bitbucket.org/openid/fapi/issues/475/certification-fapi2-baseline-is-openid> sort of hints at this and, for various reasons, the FAPI2 tests may include an optional test for requesting OIDC claims with the claims parameter.)

In terms of standards text, the relevant text in OIDC is:

"The Claims requested by the profile, email, address, and phone scope values are returned from the UserInfo Endpoint, as described in Section 5.3.2, when a response_type value is used that results in an Access Token being issued. However, when no Access Token is issued (which is the case for the response_type value id_token), the resulting Claims are returned in the ID Token."

There are conformance tests in OIDCC for these scopes, but the tests are not too prescriptive and it’s fairly easy to meet the bar for certification - they require the authentication to be successful, but don’t require that the requested data is returned in the expected place (though they raise warnings if it’s not, but you can still certify with warnings).

As CIBA always issues an access token arguably the claims should be returned in user info - however there’s then the further complication that user info isn’t mandatory to implement.

In practice I believe several OIDC implementations return at least some of the claims requested via scopes in the id_token even when they’re issuing an access token and have a user info endpoint.

Even with the claims parameter, there’s no requirement that servers support returning claims in the requested place, and there’s no metadata to know if the server supports returning a particular claim only in the id_token or only in user info (see https://bitbucket.org/openid/connect/issues/1227/core-55-claims-parameter-requirements <https://bitbucket.org/openid/connect/issues/1227/core-55-claims-parameter-requirements> ), which makes it hard to be interoperable. I think the only way to try and be interoperable is for the RP to always request the claims for both user info and id_token, and to cope with retrieving the claim value from either location; even this approach is potentially problematic from a privacy/security point of view if there’s a front channel id_token (which at least isn’t the case for CIBA).

(I would guess you’re already aware of much of that and I'm not sure any of it really answers your question either, sorry.)

Joseph

> On 21 Mar 2022, at 09:33, Vladimir Dzhuvinov via Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
> 
> What is the recommended practice for delivering consented user profile claims with CIBA?
> 
> In OIDC Core, when claims are requested via a scope value, e.g. with "scope=email" or "scope=profile", the claims get delivered at the UserInfo endpoint (unless the response_type=id_token). In CIBA it isn't clear what the RP should expect in this situation. Should the claims get returned in the ID token or at the UserInfo endpoint? What are the considerations here?
> 
> Thanks,
> 
> Vladimir
> 
> -- 
> Vladimir Dzhuvinov
> 
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-fapi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20220321/9ae69cd1/attachment.html>