[Openid-specs-ab] Aggregated and Distributed Claims

Torsten Lodderstedt torsten at lodderstedt.net
Tue Mar 5 18:35:21 UTC 2019

Hi Nat,

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.

kind regards,

> Am 05.03.2019 um 14:07 schrieb Nat Sakimura via Openid-specs-ab <openid-specs-ab at lists.openid.net>:
> This is one of the things that is not documented at all in OIDC Core. 
> We need to do it now. 
> The assumption was that claims providers use different keys obviously, as they are different entities. 
> To avoid the "calling home" problem, the public keys have to be obtainable from a trusted source, which is not the issuer. 
> It has to have some "anonymizing" capability and this is where I think something like blockchain may help. 
> Another obvious candidate, of course, is the trusted repository, e.g., Open Banking Directory. 
>> On Tue, Mar 5, 2019 at 4:44 AM Marcos Sanz via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
>> Hi Torsten,
>> > As far as I understand, you discussed distributed claims only and 
>> suggested to do discovery on the endpoint and/or use the claim 
>> > provider’s TLS cert to conduct the check.
>> originally, the certification software expected the (distributed) claims 
>> delivered by the claims provider to be signed with the same key of the 
>> original IdP. That was not doable, so that's why I suggested to discover 
>> the Claims Provider Userinfo Endpoint together with its JWKS URI and 
>> expect their own claims to be a JWS signed by the latter
>> AFAIK that's what the certification software does now and using the claim 
>> provider's TLS cert to conduct the check was just an idea, it didn't get 
>> implemented.
>> > That does not work for aggregated claims. 
>> I don't fully understand this statement. The challenge remains, as before, 
>> to discover the location of the claims providers, and that's a task that 
>> the IdP has to solve, not the RP. If the IdP is capable to return pointers 
>> to the claims providers for the RPs to dig the claims from there 
>> (distributed case), the IdP can certainly also do that work themselves, 
>> put their own signature on it, and deliver it as a whole (aggregated 
>> case).
>> > I think requiring an iss claim in the JWT is the obvious solution as the 
>> RP can perform signature validation as normal in OIDC. 
>> > BTW: I would suggest the same for distributed claims :-)
>> How would that exactly look in a distributed claims answer from the IdP 
>> UserInfo Endpoint?
>> Best,
>> Marcos
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190305/df93b042/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3728 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190305/df93b042/attachment-0001.p7s>

More information about the Openid-specs-ab mailing list