[Openid-specs-ab] New openid-connect-4-identity-assurance-1_0 draft -06

[Pawel Kowalik]

Hi Torsten,

Thanks for filing in the issue. Will continue to discuss in the ticket.

Kind Regards,
Pawel


-----Original Message-----
From: Torsten Lodderstedt [mailto:torsten at lodderstedt.net] 
Sent: 13 August 2019 09:23
To: Pawel Kowalik <pawel.kowalik at ionos.com>
Cc: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>; Marcos Sanz <sanz at denic.de>
Subject: Re: [Openid-specs-ab] New openid-connect-4-identity-assurance-1_0 draft -06

Hi Pawel, 

thanks for your proposal. 

It sounds reasonable to me but I we as as WG need to understand the consequences. Do you envision any changes to the request syntax or is the split among the array elements at the discretion of the OP? 

I created a ticket https://bitbucket.org/openid/connect/issues/1105/make-verified_claims-an-array . I would be great if we could continue the discussion of your proposal there.

best regards,
Torsten.   

> On 2. Aug 2019, at 09:21, Pawel Kowalik <pawel.kowalik at ionos.com> wrote:
> 
> Hi Thorsten,
> 
> As it's my first post on this list, let me introduce myself. I am working with Marcos in ID4me initiative and within technical group we are right now in the process to define the framework for federated and verified identities for ID4me ecosystem.
> 
>> Very interesting question. I had envisioned the external claim provider to provide the while “verified_claims” Claim at
>> once. As this is a top level claim, one can rely on the standard OIDC mechanisms. 
> 
> This is what I would also expect it to be, to bind "claims" and "verification" under the same object and signature.
> The problem we see is that "verified_claims" is a singular claim, so cannot be delegated to two or more entities, which may provide different subset of verified data requested by the RP.
> 
>> Now you are proposing to obtain the claims within the “verified_claims” Claim from external providers. Syntactically
>> we can make that work on one way or the other. 
> 
>> I would like to understand more about the context and use case. How does the IDP asserting the “verified_claims"
>> Claim to the RP ensure that the externally provided data comply with the data provided in the verification element?  
> 
> I think this is the issue with solution proposed by Marcos, that delegating claims on the second level it is not expected that aggregated/distrtibuted claim would contain whole "verified_claims" object including "verification".
> 
> A solution to that would be defining "verified_claims" as an array and using JSON references.
> 
> {
>   "iss":"https://server.example.com",
>   "sub":"248289761001",
>   "verified_claims":[
>      {
>         "claims":{
>            ...
>         },
>         "verification":{
>           ...
>         }
>      },
>      {
>         "$ref":"#/verified_claims_src1"
>      },
>      {
>         "$ref":"#/verified_claims_src2"
>      }
>   ],
>   "_claim_names":{
>      "verified_claims_src1":"src1",
>      "verified_claims_src2":"src2"
>   },
>   "_claim_sources":{
>      "src1":{
>         "JWT":"..."
>      },
>      "src2":{
>         "JWT":"..."
>      }
>   }
> }	
> 
> Kind Regards,
> Pawel
>