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

Torsten Lodderstedt torsten at lodderstedt.net
Thu Aug 1 13:38:47 UTC 2019


Hi Marcos, 

thanks again for your review. 

> On 31. Jul 2019, at 12:22, Marcos Sanz <sanz at denic.de> wrote:
> 
> Hi Torsten,
> 
>> a new revision of 
> https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html is 
> available. 
> 
> it's really getting closer :-)

good to hear :-) 

> 
> Typos:
> - There's still one instance of "verified_person_data" in section 5.1

thanks. It seems to be pretty persistent ;-).  

> - Section 4.1.1.3: s/eletronic signatue/electronic signature/

fixed.

> 
> Besides that, here at ID4me we were wondering how should we syntactically 
> express aggregated/distributed verified_claims answers when they stem 
> from/point at two or more different claims providers on the light of the 
> examples of sections 6.6 and 6.7. Should it be something like 
> 
> { 
>   "iss":"https://server.example.com", 
>   "sub":"248289761001",
>   "_claim_names":{ 
>       "verified_claims":{ 
>         "claims":{ 
>            "given_name":"src1",
>            "family_name":"src1",
>            "address":"src2"
>         }
>      }
>   },
>   "_claim_sources":{ 
>      "src1":{ 
>      "JWT":"..."
>      },
>     "src2":{ 
>      "JWT":"..."
>      }
>   }
> }
> 
> respectively
> 
> { 
>   "iss":"https://server.example.com", 
>   "sub":"248289761001",
>   "_claim_names":{ 
>       "verified_claims":{ 
>         "claims":{ 
>            "given_name":"src1",
>            "family_name":"src1",
>            "address":"src2"
>         }
>      }
>   },
>   "_claim_sources":{ 
>      "src1":{ 
>       "endpoint":"https://oneserver.oneop.com/claim_source",
>      },
>     "src2":{ 
>      "endpoint":"https://anotherserver.yetanotherop.com/",
>         "access_token":"ksj3n283dkeafb76cdef"
>      }
>   }
> }
> 
> I'd need some standards guidance on that.

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. 

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?  
 
best regards,
Torsten. 

> 
> Thanks and regards,
> Marcos

-------------- 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/20190801/bfba327e/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list