<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Helvetica, Arial, sans-serif">Given that claims and
values for aggregated claims are defined by the remote attribute
provider and therefore the ability of a receiver of the JWT to be
able to validate the JWT is also the responsibility of the remote
attribute provider. So from a spec perspective it's "OK" for the
validation mechanisms to be different.<br>
<br>
That said, I agree that the remote attribute provider SHOULD
include the "iss" claim as that makes validating the JWT much
simpler. The question is whether we should mandate that model or
allow some flexibility.<br>
<br>
Thanks,<br>
George<br>
</font><br>
<div class="moz-cite-prefix">On 3/5/19 1:35 PM, Torsten Lodderstedt
via Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite"
cite="mid:E611D7FA-0848-4457-8B64-0DFFA17B7FA0@lodderstedt.net">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hi Nat,</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">I don’t see a „home calling“ problem for aggregated
claims. All the RP needs is obtain the public key from the
claims provider‘s jwks_uri. The server hosting the jwks file
cannot collate the request with a certain claim or user.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">kind regards,</div>
<div dir="ltr">Torsten.</div>
<div dir="ltr"><br>
Am 05.03.2019 um 14:07 schrieb Nat Sakimura via Openid-specs-ab
<<a href="mailto:openid-specs-ab@lists.openid.net"
moz-do-not-send="true">openid-specs-ab@lists.openid.net</a>>:<br>
<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">Openid-specs-ab@lists.openid.net</a><br>
<a
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
rel="noreferrer" target="_blank" moz-do-not-send="true">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"
moz-do-not-send="true">http://nat.sakimura.org/</a><br>
@_nat_en</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div dir="ltr"><span>_______________________________________________</span><br>
<span>Openid-specs-ab mailing list</span><br>
<span><a href="mailto:Openid-specs-ab@lists.openid.net"
moz-do-not-send="true">Openid-specs-ab@lists.openid.net</a></span><br>
<span><a
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
moz-do-not-send="true">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br>
</div>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</body>
</html>