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

Anthony Nadalin tonynad at microsoft.com
Tue Jun 4 21:40:11 UTC 2019


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<mailto: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/20190604/c66b9ac6/attachment-0001.html>


More information about the Openid-specs-ab mailing list