[Openid-specs-ab] Aggregated and Distributed Claims

[George Fletcher]

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.

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.

Thanks,
George

On 3/5/19 1:35 PM, Torsten Lodderstedt via Openid-specs-ab wrote:
> 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,
> Torsten.
>
> Am 05.03.2019 um 14:07 schrieb Nat Sakimura via Openid-specs-ab 
> <openid-specs-ab at lists.openid.net 
> <mailto: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 
>> <mailto: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
>>     <mailto: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 
>> <mailto:Openid-specs-ab at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
> _______________________________________________
> 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/b9fb0170/attachment.html>