<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thank you Joseph, this actually helped a lot.</p>
<p>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.<br>
</p>
<p><a class="moz-txt-link-freetext" href="https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims">https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims</a></p>
<p>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.<br>
</p>
<p>Vladimir<br>
</p>
<pre class="moz-signature" cols="72">Vladimir Dzhuvinov</pre>
<div class="moz-cite-prefix">On 21/03/2022 13:37, Joseph Heenan
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:77CDBCC8-091C-4CA5-A960-39C538E8FB0E@authlete.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Hi Vladimir,
<div class=""><br class="">
</div>
<div class="">To add my 2 cents:</div>
<div class=""><br class="">
</div>
<div class="">There’s not current any conformance tests for
FAPI-CIBA that cover requesting claim with scopes. (Though it
may be worth adding one perhaps; <a
href="https://bitbucket.org/openid/fapi/issues/475/certification-fapi2-baseline-is-openid"
class="moz-txt-link-freetext" moz-do-not-send="true">https://bitbucket.org/openid/fapi/issues/475/certification-fapi2-baseline-is-openid</a> 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.)</div>
<div class=""><br class="">
</div>
<div class="">
<div>In terms of standards text, the relevant text in OIDC is:</div>
<div><br class="">
</div>
<div>"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."</div>
<div class=""><br class="">
</div>
</div>
<div class="">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).<br class="">
<div><br class="">
</div>
<div>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.</div>
</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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 <a
href="https://bitbucket.org/openid/connect/issues/1227/core-55-claims-parameter-requirements"
class="moz-txt-link-freetext" moz-do-not-send="true">https://bitbucket.org/openid/connect/issues/1227/core-55-claims-parameter-requirements</a> ),
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).
<div><br class="">
</div>
<div>(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.)</div>
<div><br class="">
</div>
<div>Joseph</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 21 Mar 2022, at 09:33, Vladimir Dzhuvinov
via Openid-specs-fapi <<a
href="mailto:openid-specs-fapi@lists.openid.net"
class="moz-txt-link-freetext" moz-do-not-send="true">openid-specs-fapi@lists.openid.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">What is the recommended practice for
delivering consented user profile claims with CIBA?<br
class="">
<br class="">
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?<br class="">
<br class="">
Thanks,<br class="">
<br class="">
Vladimir<br class="">
<br class="">
-- <br class="">
Vladimir Dzhuvinov<br class="">
<br class="">
_______________________________________________<br
class="">
Openid-specs-fapi mailing list<br class="">
<a href="mailto:Openid-specs-fapi@lists.openid.net"
class="moz-txt-link-freetext" moz-do-not-send="true">Openid-specs-fapi@lists.openid.net</a><br
class="">
<a class="moz-txt-link-freetext" href="https://lists.openid.net/mailman/listinfo/openid-specs-fapi">https://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
</body>
</html>