[OpenID-Specs-eKYC-IDA] Aggregated verified claims

Torsten Lodderstedt torsten at lodderstedt.net
Sat Mar 14 10:38:58 UTC 2020


Why doesn’t the OP just include those claims into the primary assertions this case?

> Am 14.03.2020 um 11:14 schrieb nat--- via Openid-specs-ekyc-ida <openid-specs-ekyc-ida at lists.openid.net>:
> 
> 
> Do we consider the cases where the sources are not authoritative but only corroborative so that the claims has to come from multiple sources? 
> 
> 2020/03/13 17:04 Achim Schlosser via Openid-specs-ekyc-ida <openid-specs-ekyc-ida at lists.openid.net>:
> I think not too much other than eKYC specifics if used in conjunction with claims being returned via the  ID Token.
> 
> The difference in OIDC would be that you can use aggregated claims with claims being returned via UserInfo, which would not yield a nested JWT.
> 
> 
> Best
> 
> Achim 
> 
> On 13.03.20, 08:36, "Openid-specs-ekyc-ida on behalf of Torsten Lodderstedt via Openid-specs-ekyc-ida" <openid-specs-ekyc-ida-bounces at lists.openid.net on behalf of openid-specs-ekyc-ida at lists.openid.net> wrote:
> 
>     What’s the difference?
>     
>     > Am 13.03.2020 um 02:13 schrieb Anthony Nadalin via Openid-specs-ekyc-ida <openid-specs-ekyc-ida at lists.openid.net>:
>     > 
>     > Why not just support nested JWTs.
>     > 
>     > -----Original Message-----
>     > From: Openid-specs-ekyc-ida <openid-specs-ekyc-ida-bounces at lists.openid.net> On Behalf Of Achim Schlosser via Openid-specs-ekyc-ida
>     > Sent: Thursday, March 12, 2020 5:04 PM
>     > To: Openid-specs-ekyc-ida at lists.openid.net
>     > Cc: Achim Schlosser <achim.schlosser at enid.eu>
>     > Subject: [EXTERNAL] Re: [OpenID-Specs-eKYC-IDA] Aggregated verified claims
>     > 
>     > Hi Torsten,
>     > 
>     > 
>     > Ok that makes sense.
>     > 
>     > Aggregated claims look really appealing in a eKYC scenario, given the possibility to have sign/encrypted JWTs from the different claim providers depending on which one was used. 
>     > 
>     > 
>     > Best
>     > 
>     > 
>     > Achim Schlosser
>     > 
>     > Sent from my IPhone
>     > 
>     > 
>     >> Am 12.03.2020 um 19:57 schrieb Achim Schlosser <achim.schlosser at enid.eu>:
>     >> 
>     >> Hi,
>     >> 
>     >> 
>     >> I’ve been reading through v09 and came across the aggregated claims examples (which I'm specifically interested in also in terms of implementation) and wanted to align on this. The example is he following: 
>     >> 
>     >> {
>     >>  "iss": "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver.example.com&data=02%7C01%7Ctonynad%40microsoft.com%7C61b0d02530c9437de3ad08d7c6e2027f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637196546313672090&sdata=mOaW6CgJDGhZmpbKhRCBedjGK72vNxExHXadFP1P%2Bk0%3D&reserved=0",
>     >>  "sub": "248289761001",
>     >>  "email": "mailto:janedoe at example.com",
>     >>  "email_verified": true,
>     >>  "_claim_names": {
>     >>    "verified_claims": "src1"
>     >>  },
>     >>  "_claim_sources": {
>     >>    "src1": {
>     >>      "JWT": "......"
>     >>    }
>     >>  }
>     >> }
>     >> 
>     >> This notation means that all verified_claims that are available / the user is willing to share are available in SRC1s JWT.
>     >> 
>     >> I would assume that the following is also possible, which basically uses the verified_claims object in details here:
>     >> 
>     >> {
>     >>  "iss": "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserver.example.com&data=02%7C01%7Ctonynad%40microsoft.com%7C61b0d02530c9437de3ad08d7c6e2027f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637196546313672090&sdata=mOaW6CgJDGhZmpbKhRCBedjGK72vNxExHXadFP1P%2Bk0%3D&reserved=0",
>     >>  "sub": "248289761001",
>     >>  "email": "mailto:janedoe at example.com",
>     >>  "email_verified": true,
>     >>  "_claim_names": {
>     >>    "verified_claims": {
>     >>      "claims": {
>     >>        "given_name": "src1",
>     >>        "family_name": "src1",
>     >>        "birthdate": "src1"
>     >>      }
>     >>    }
>     >>  },
>     >>  "_claim_sources": {
>     >>    "src1": {
>     >>      "JWT": "......"
>     >>    }
>     >>  }
>     >> }
>     >> 
>     >> This would allow for explicitly listing the claims present as it is done for classical claims in line with the core specification. This would also support multiple aggregated claim sources with verified claims. 
>     >> 
>     >> Best
>     >> 
>     >> Achim
>     >> 
>     >> 
>     > -- 
>     > Openid-specs-ekyc-ida mailing list
>     > Openid-specs-ekyc-ida at lists.openid.net
>     > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ekyc-ida&data=02%7C01%7Ctonynad%40microsoft.com%7C61b0d02530c9437de3ad08d7c6e2027f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637196546313672090&sdata=dlR54JgjLMvuLWnRj3MpnfHM%2BTJgY0WXd4WRCkkXLvE%3D&reserved=0
>     > -- 
>     > Openid-specs-ekyc-ida mailing list
>     > Openid-specs-ekyc-ida at lists.openid.net
>     > http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida
>     
> 
> -- 
> Openid-specs-ekyc-ida mailing list
> Openid-specs-ekyc-ida at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida
> 
> 
> -- 
> Openid-specs-ekyc-ida mailing list
> Openid-specs-ekyc-ida at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ekyc-ida/attachments/20200314/e2321b6a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2275 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ekyc-ida/attachments/20200314/e2321b6a/attachment-0001.p7s>


More information about the Openid-specs-ekyc-ida mailing list