[Openid-specs-ab] Opened-connect-4-identity-assurance-02

Torsten Lodderstedt torsten at lodderstedt.net
Thu Jun 20 17:21:44 UTC 2019


thanks for your hint, will take a look.

> Am 04.06.2019 um 23:40 schrieb Anthony Nadalin <tonynad at microsoft.com>:
> 
> Torsten you should really look at ISO 29003 as many national bodies have contributed to the jurisdictional evidence of Identity table and you can see here what is acceptable and what is not, I don’t think what you have so far would work in most jurisdictions.
>  
>  
>  
> Annex AEvidence of identity and binding examples for some national jurisdictions
> 
> A.1   Evidence of identity examples for some national jurisdictions
> 
> Table A.1 provides examples of national authoritative and corroborative evidence for commonly used identifying attributes as determined by each jurisdiction. It does not include additional commercial corroborative evidence that exist to support digital economies in many developed nations.
> 
> Table A.1 — Examples of evidence of identity
> 
> 
> Identifying attribute
> Jurisdiction
> Authoritative evidence or party examples
> Corroborative evidence examples
> Name at birth
> CN
> Birth Certificate, Identity Card, Social Security Card, Driving License, Passport
>  
> ES
> Local/central Civil Register
> Passport, driving licence, eID
> GB
> HM Passport Office - General Records Office - Retained register of birth certificate(s) and Passport database
> ICAO biometric passport, EU EC2252/2004 identity card, UK biometric residency permit
> IR
> General Register Office
> Public Services Card, Social Services Card, Medical Card, Drug Payment Scheme (DPS) Card, European Health Insurance Card
> IT
> National identity register
> Passport, driving licence, nautical licence, pension book, firearms licence, national identity card, national eID
> KR
> ID database operated by Ministry of the Interior, driving license database, passport database
> Resident Registration ID Card, Certificate for family relation, KR passport, Driver License
> MY
> MyKAD, National Registration Department (NRD)
> Passport, Driving License
> NL
> Basic Registry of People (BRP)
> Birth certificate, passport, NL driving licence, IdentityCard
> NZ
> Birth register
> NZ Passport, Birth certificate, Driver Licence
> US
> Birth Certificate, Social Security Registry, Passport †, driving license †, I-90 (‘green card’)
> Financial or utility account, credit bureaux
> Date of birth
> CN
> Birth Certificate, Identity Card, Social Security Card, Driving License, Passport
>  
> ES
> Local/central Civil Register
> Passport, driving licence, eID
> GB
> HM Passport Office - General Records Office - Retained register of birth certificate(s) and Passport database
> ICAO biometric passport, EU EC2252/2004 identity card, UK biometric residency permit
> IT
> National identity register
> Passport, driving licence, nautical licence, pension book, firearms licence, national identity card, national eID
> IR
> General Register Office
> Public Services Card, Social Services Card, Medical Card, Drug Payment Scheme (DPS) Card, European Health Insurance Card
> KR
> ID database operated by Ministry of the Interior, driving license database, passport database
> Resident Registration ID Card, Certificate for family relation, KR passport, Driver License
> MY
> MyKAD, National Registration Department (NRD)
> Passport, Driving License
> NL
> Basic Registry of People (BRP)
> Birth certificate, passport, NL driving licence, IdentityCard
> NZ
> Birth register, NZ Passport database
> NZ Passport, Birth certificate, NZ Electronic Identity Credential, Driver Licence, 18+card
> US
> Birth Certificate, Social Security Registry, Passport †, I-90
> Financial or utility account, credit bureaux
> Place of birth
> CN
> Birth Certificate, Social Security Card Database, Identity Card Database
>  
> ES
> Local/central Civil Register
> Passport, driving licence, eID
> GB
> HM Passport Office - General Records Office - Retained register of birth certificate(s) and Passport database
> ICAO biometric passport, EU EC2252/2004 identity card, UK biometric residency permit
> IT
> National identity register
> Passport, driving licence, nautical licence, pension book, firearms licence, national identity card, national eID
> IR
> General Register Office
>  
> KR
> ID database operated by Ministry of the Interior
> Resident Registration ID Card, Certificate for family relation’, KR passport, Driver License
> MY
> National Registration Department (NRD)
> Passport
> NL
> Basic Registry of People (BRP)
> Birth certificate, passport, NL driving licence, IdentityCard
> NZ
> Birth register, NZ Passport database
> NZ Passport, Birth certificate, NZ Electronic Identity Credential
> US
> Birth Certificate, Social Security Registry, Passport †, I-90 (Country only)
> Financial or utility account, credit bureaux
> Other official name/s
> CN
> Birth Certificate, Identity Card, Social Security Card, Driving License, Passport
>  
> ES
> Local/central Civil Register
> Passport, driving licence, eID
> IR
> General Register Office
>  
> IT
> National identity register
>  
> MY
> National Registration Department (NRD)
> Passport
> NL
> Basic Registry of People (BRP)
> Passport, NL driving licence, IdentityCard
> NZ
> Birth register, NZ Passport database
> NZ Passport, Birth certificate, NZ Electronic Identity Credential, Driver Licence, 18+card
> US
> Social Security Registry, Passport †, driving license †, I-90
> Financial or utility account, credit bureaux
> Address
> CN
> Identity Card, Driving License
>  
> IR
> General Register Office
> Utility bill, Active insurance policy (health/life/ house/car), Bank statement,
> Letter from Department of Social Protection/ Revenue
> IT
> National identity register
> Passport, driving licence, nautical licence, pension book, firearms licence, national identity card, national eID
> KR
> ID database operated by Ministry of the Interior, driving license database, passport database
> Resident Registration ID Card, Certificate for family relation, Driver License
> MY
> MyKAD, National Registration Department (NRD)
> Utility bills, driving license
> NL
> Basic Registry of People (BRP)
>  
> NZ
> None
> Driver Licence, Address Verification Service, Bank statement, Utility account
> US
> US Postal Service, Social Security Registry, driving license †
> Financial or utility account, credit bureaux
> Phone number
> CN
> Telecommunication provider database
>  
> KR
> Telecommunication provider database
>  
> MY
> Telco providers
>  
> NZ
> Telecommunication provider database
> Telco. utility account
> US
> Telecommunication provider database
>  
> Email address
>  
>  
>  
> US
>  
> Financial or utility account, credit bureaux
> Facial image
> CN
> Identity Card Database, Social Security Card Database, Driving License Database, Passport Database
>  
> ES
> Passport database, driving licence database, eID database (different images)
> Passport, driving licence, eID
> GB
> HMPO passport database/passport, UK biometric residence permit, EEA/EU Government issued identity cards that comply with Council Regulation (EC) No 2252/2004
> EEA/EU full driving licences that comply with European Directive 2006/126/EC
> IR
> General Register Office
> Irish Passport, Driving Licence, or Learner Permit, Irish Public Services Card, Irish Certificate of Naturalisation
> Passport for all non-Irish citizens, EU ID card, UK driving licence
> IT
> National identity register
> Passport, driving licence, nautical licence, pension book, firearms licence, national identity card, national eID
> KR
> ID database operated by Ministry of the Interior, driving license database, passport database
> Resident Registration ID Card, KR passport, Driver License
> MY
> MyKAD, Passport, National Registration Department (NRD)
> Driving License
> NL
> Basic Registry of People (BRP)
> Passport, NL driving licence, IdentityCard
> NZ
> The person who is the subject of the facial image
> NZ Passport, Driver Licence, 18+card
> US
> Passport database, driving licence database
>  
> Finger print
> CN
> Identity Card Database, Passport Database
>  
> KR
> ID database operated by Ministry of the Interior, passport database
> Resident Registration ID Card,
> MY
> MyKAD, Passport, National Registration Department (NRD)
>  
> NZ
> The person who is the subject of the finger print
>  
> Resident Registration Number (National Identifier)
> CN
> Identity Card Number
>  
> KR
> ID database operated by Ministry of the Interior, driving license database, passport database
> Resident Registration ID Card, Certificate for family relation, KR passport, Driver License
> MY
> MyKAD, National Registration Department (NRD)
> Passport, Driving License
> US
> Social Security Registry, I-90 (‘Green Card’)
>  
> † cited in NIST/SP 800-63-2, Table 3, as an example of a ‘primary government id’, therefore implicitly authoritative.
> UUUUUUUUU.1        Binding examples for some national jurisdictions
> 
> Table A.2 provides examples of different mechanisms which can be used to establish binding at the stated LoIP(s) as determined by each jurisdiction.
> 
> Table A.2 — Examples of binding processes
> 
> Jurisdiction
> Mechanism
> LoIP
> CN
> In-person comparison of the face of a person with a photo of Identity Card /Social Security Card/Passport
> 2, 3
> GB
> In-person comparison of the face of a person with a photo identification document held in Authoritative or Corroborative Evidence
> 3
> GB
> On-line comparison of the face of the person with
> a digital image in Authoritative or Corroborative Evidence
> 2
> GB
> Knowledge based questions that only the person who owns the identity would be expected to know.
> 2
> KR
> In-person comparison of the face of a person with a photo identification of an official ID (e.g. Resident registration ID, Passport, Driver license)
> 2
> KR
> Verification against identity data from prior identity verification processes of e.g. LoIP3 (e.g. SMS authentication, Internet personal identification number, Licensed public key certificate)
> 3
> KR
> Verification against finger print image prior identity verification processes of e.g. LoIP3 (e.g. Resident Registration ID card)
> 3
> MY
> Verification against finger print template and identity attributes (e.g. name, photo, date of birth, ID number) in National Registration Identity Card (MyKad) issued by National Registration Department (NRD)
> 3
> MY
> Verification against identity attribute in National Registration Identity Card (MyKad) issued by National Registration Department (NRD)
> 2
> NZ
> In-person comparison of the face of a person with a photo identification document held in Authoritative or Corroborative Evidence
> 2
> US
> In-person comparison of the face of a person with a photo identification document
> 1, 2, 3
> US
> CIP requirements of USA PATRIOT Act and other such instruments (in-person)
> 1, 2,3
>  
>  
> -----Original Message-----
> From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Marcos Sanz via Openid-specs-ab
> Sent: Tuesday, June 4, 2019 4:19 AM
> To: Torsten Lodderstedt <torsten at lodderstedt.net>
> Cc: Marcos Sanz <sanz at denic.de>; Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
> Subject: Re: [Openid-specs-ab] Opened-connect-4-identity-assurance-02
>  
> Hi Torsten,
>  
> (despite subject I am now refering to the latest version -04)
>  
> > > - Section 3.1: Re "nationality" it looks like only one country code
> > > is
>  
> > > allowed. Is it in scope to deal with multiple nationalities?
> >
> > Good question! I will created a corresponding ticket (
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%2F1092%2Fsupport-multiple-nationalities&data=02%7C01%7Ctonynad%40microsoft.com%7C1d43ba53a7fc43b7f81208d6e8de795f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636952439578219153&sdata=MX96BYUCvFvMcUxMcAjkmBIgRmgKCDRK0PXwcE2iPf4%3D&reserved=0
> ).
> >
> > There are indeed people having more than a single nationality.
> > The question is whether the IDP will verify those and will be able to
> attest them.
> >
> > In our original setting (German AML), the bank will verify _a_
> nationality but not
> > necessarily all of them.
> >
> > There is also a structural challenge. If we modify the syntax to allow
> for multiple nationalities, is there a need to link every
> > entry in the array to a certain evidence?
>  
> At the moment the spec does not link verified data to its respective evidence at all, even when there are multiple evidences (s. for instance the example in section 6.2 with ID document AND utility bill), so I don't think we would (or actually do) need that capability. On the other hand, you might be right with regard to an entity verifying one nationality and not all of them. So I don't really need the multiple nationalities feature.
>  
> What I just came up with and actually think to be more important than multiple nationalities (warning: I am not an expert in this topic!) is the fact that the ICAO Machine Readable Passports specification asserts nationality by means of their ICAO codes ( https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icao.int%2Fpublications%2FDocuments%2F9303_p3_cons_en.pdf&data=02%7C01%7Ctonynad%40microsoft.com%7C1d43ba53a7fc43b7f81208d6e8de795f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636952439578219153&sdata=yBtT6Ny6ZZyZ0BAD5Q0EYfeZO1VKauS%2FVavcoEZv84I%3D&reserved=0), which expand ISO 3166 because they also have to deal with UN travel documents and other various issuing authorities. ICAO even reserve nationality codes for stateless people.  For a good summary read
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iso.org%2Fnews%2F2011%2F04%2FRef1604.html&data=02%7C01%7Ctonynad%40microsoft.com%7C1d43ba53a7fc43b7f81208d6e8de795f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636952439578219153&sdata=WQoIYpNayLTS6Mx1Q8%2BDGBdyOnqOTqPj3dYYyXDLeiM%3D&reserved=0 rather than the ICAO PDF.
>  
> So while ISO3166 initially seemed to us initially like the natural fit to describe "issuer country" and "nationality", we might be excluding
> (discriminating?) identities from being describable with our spec.
>  
> Are ICAO codes maybe the better way to go?
>  
> > > - Section 4.1: If we agree that we should be extensible wrt Trust
> > > Frameworks, a sentence should be included here (or somewhere else)
> that a)
> > > the list in section 12.1 is only the initial list b) that Trust
> Frameworks
> > > that are not understood in answers should be ignored and c) that
> querying
> > > for unknown (i.e. not announced in trust_frameworks_supported) Trust
> > > Frameworks should maybe deliver a dedicated, still to be defined
> > > error
>  
> > > (e.g. trust framework not supported)
> >
> > Enhanced text a bit. The challenge I see is to really establish the
> required extension mechanism.
>  
> Absolutely.
> > Created a corresponding ticket:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%2F1093%2Fextensibility-how-do-we-support&data=02%7C01%7Ctonynad%40microsoft.com%7C1d43ba53a7fc43b7f81208d6e8de795f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636952439578219153&sdata=uV2zcN1VdT79QHQB9r8sFZMj%2BOgv1iyKnPfNZnSS5w4%3D&reserved=0
> [...]
> > Created another ticket to bring this question to the WG’s attention:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%2F1094%2Fhow-to-&data=02%7C01%7Ctonynad%40microsoft.com%7C1d43ba53a7fc43b7f81208d6e8de795f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636952439578219153&sdata=rcw4My3Br6mTH6vq%2BSXUphxQv3Zko3O8XcGlDXE2PLg%3D&reserved=0
> > treat-unknown-identifiers-in-claims
>  
> Ok, let's track discussion there.
>  
> > > - Section 8: This is a cool feature, which indeed we use in our
> deployment
> > > (we call it "reason" instead of "purpose", but the same semantics). As
> a
> > > matter of fact, we allow to specify a per-claim "reason" (which is
> > > specially useful to differentiate among why some claims requested are
> > > mandatory and some optional). We query like this (in order to be OIDC
> core
> > > compliant):
> > > "userinfo": { "given_name": {"essential": true, "reason": "In order to
>  
> > > create an account"}}
> > > Do you think we could enrich "purpose" in this direction? And in any
> case,
> > > a usage example in section 8 would be helpful.
> >
> > Sure. Can you please suggest text?
>  
> Actually I think now that the text, which is all about requesting user
> claims, better belongs to section 5.1, right before the first note (and
> there's no need at all for a section 8):
>  
> "
> This specification introduces the request parameter purpose to allow a RP
> to state the purpose for the transfer of the user data it is asking for.
> The parameter purpose can be a member value of each individually requested
> claim, but a claim cannot have more than one associated purpose.
> purpose OPTIONAL. String describing the purpose for obtaining certain user
> data from the OP. The purpose MUST NOT be shorter than 3 characters or
> longer than 300 characters. If this rule is violated, the authentication
> request MUST fail and the OP returns an error invalid_request to the RP.
> The OP MUST display this purpose in the respective user consent screen(s)
> in order to inform the user about the designated use of the data to be
> transferred or the authorization to be approved. Purposes are free text
> and, as such, it is up to the RP to perform localization of the message
> (incl. choosing the appropriate language) according to user
> context/preferences before issuing the request. If the parameter purpose
> is not present in the request, the OP MAY display a generic purpose or a
> value that was pre-configured for the respective RP.
> Example:
> {
>    "userinfo":{
>       "verified_person_data":{
>          "claims":{
>             "given_name":{"essential": true, "purpose": "To make
> communication look more personal"},
>             "family_name":{"essential": true},
>             "birthdate":{"purpose": "To send you best wishes on your
> birthday"}
>          }
>       }
>    }
> }
> "
>  
>  
> > > - Section 8: What about moving the final Note on XSS and the like to
> the
> > > (still empty) Security Considerations?
> >
> > Well, you are not the first reviewer to raise this. I would like to
> leave it in section 8 for now because moving it into the
> > security considerations section would require to first establish the
> context, … this is about the purpose …
> >
> > I personally prefer to give security considerations with the feature
> description since it is the right context and is directly
> > actionable. If we in the end come to the conclusion the security
> considerations section is the better place (== better for
> > implementers to understand) I will happily move it there. Ok?
>  
> Fine by me.
>  
> One more thing: I noticed that section 7 introduces a new boolean element
> (verified_person_data_supported) with exactly the same name as the
> existing JSON array containing all claims supported and defined in the
> very same section. That's a recipe for disaster ;->
>  
> Best regards,
> Marcos
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=02%7C01%7Ctonynad%40microsoft.com%7C1d43ba53a7fc43b7f81208d6e8de795f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636952439578219153&sdata=Yh8JwcBD1baLfnvOyZHTVbuS%2B90T2QZsB0JID%2B%2BsmOc%3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190620/c5bcd951/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3728 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190620/c5bcd951/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list