[Openid-specs-ab] Aggregated and Distributed Claims

[Torsten Lodderstedt]

I just created an issue https://bitbucket.org/openid/connect/issues/1066/core-562-aggregated-and-distributed-claims

> Am 05.03.2019 um 20:39 schrieb George Fletcher <gffletch at aol.com>:
> 
> 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>:
>> 
>>> 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
>> 
>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> 
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3923 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190309/5b22731c/attachment.p7s>