<div dir="ltr">This is one of the things that is not documented at all in OIDC Core. <div>We need to do it now. </div><div><br></div><div>The assumption was that claims providers use different keys obviously, as they are different entities. </div><div>To avoid the "calling home" problem, the public keys have to be obtainable from a trusted source, which is not the issuer. </div><div>It has to have some "anonymizing" capability and this is where I think something like blockchain may help. </div><div>Another obvious candidate, of course, is the trusted repository, e.g., Open Banking Directory. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 5, 2019 at 4:44 AM Marcos Sanz via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Torsten,<br>
<br>
> As far as I understand, you discussed distributed claims only and <br>
suggested to do discovery on the endpoint and/or use the claim <br>
> provider’s TLS cert to conduct the check.<br>
<br>
originally, the certification software expected the (distributed) claims <br>
delivered by the claims provider to be signed with the same key of the <br>
original IdP. That was not doable, so that's why I suggested to discover <br>
the Claims Provider Userinfo Endpoint together with its JWKS URI and <br>
expect their own claims to be a JWS signed by the latter<br>
<br>
AFAIK that's what the certification software does now and using the claim <br>
provider's TLS cert to conduct the check was just an idea, it didn't get <br>
implemented.<br>
<br>
> That does not work for aggregated claims. <br>
<br>
I don't fully understand this statement. The challenge remains, as before, <br>
to discover the location of the claims providers, and that's a task that <br>
the IdP has to solve, not the RP. If the IdP is capable to return pointers <br>
to the claims providers for the RPs to dig the claims from there <br>
(distributed case), the IdP can certainly also do that work themselves, <br>
put their own signature on it, and deliver it as a whole (aggregated <br>
case).<br>
<br>
> I think requiring an iss claim in the JWT is the obvious solution as the <br>
RP can perform signature validation as normal in OIDC. <br>
> BTW: I would suggest the same for distributed claims :-)<br>
<br>
How would that exactly look in a distributed claims answer from the IdP <br>
UserInfo Endpoint?<br>
<br>
Best,<br>
Marcos<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div></div>