[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.html>
More information about the Openid-specs-ab
mailing list