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

[Vladimir Dzhuvinov]

Thank you Joseph, this actually helped a lot.

For the default / std behaviour I will note that 5.4 from OIDC Core 
applies, i.e. the consented claims appear at the UserInfo endpoint.

https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims

I wanted to know where the standards are on this. In the OIDC SDK and 
elsewhere we will try to accommodate scope-expanded claims appearing in 
the ID token as well.

Vladimir

Vladimir Dzhuvinov

On 21/03/2022 13:37, Joseph Heenan wrote:
> 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 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 ), 
> 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/b6127b00/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20220321/b6127b00/attachment-0001.p7s>