Add verified `person_numbers` to Additional Claims about End-Users

[Mark Haine]

add person_numbers to the table in section 4.1

[Nick Mothershaw]

You should assess ISO24366 on Natural Person Identifier. “Already existing national NPIs might not be applicable in cross-border transactions. The NPI defined in this document intends to close this gap, allowing a co-existence of national identifiers and the international NPI.” Interestingly also contains definition for a NPI record: names, address, DoB, Country etc.

[Mark Haine]

Consider including ISO24366 - “Natural Person Identifier”

[Mark Haine]

We might want to consider adding a structured identifier object to the draft that allows specificatoin of type and definition of an array of identifiers.

e.g. :

`

"personal_identifiers": [
    {
        "identifier": "11234",
        "type": "UK NINO",
        "issuer": "UK Home office"
    },
    {
        "identifier": "KF55673",
        "type": "UK NINO",
        "issuer": "UK Home office"
    },
    {
        "identifier": "234 741 9834",
        "type": "Health service",
        "issuer": "UK NHS"
    },
    {
        "identifier": "123456789",
        "type": "Passport",
        "issuer": "UK HMPO"
    },
    {
        "identifier": "HAY50312JJ9VC",
        "type": "UK Driving License",
        "issuer": "UK DVLA"
    },
    {
        "identifier": "123123412",
        "type": "CHI number",
        "issuer": "NHS Scotland"
    }
]

`

Note: I changed it to personal_identifiers to avoid the implied restriction to numeric only

[Mark Haine]

ISO24366 seems to be trying to address the whole set of attributes of an individual rather than just “identifiers”. It appears to include things like…

• nationality
• address
• e-mail
• phone numbers
• date of birth
• ID jurisdiction
• gender
• biometrics

‌

‌

[Takahiko Kawasaki]

It is too big a task to define the personal_identifiers claim. Discussions similar to ones for personal_number in evidence will be needed and the structure of each element in the personal_identifiers array will grow fat as a result of the discussions sooner or later. (e.g. Isn’t it necessary to change the type of issuer to JSON object? Isn’t it necessary to pre-define allowed values for type? When was the value of identifier assigned? Until when will the identifier be valid?, …)

Unless there are clear benefits of having personal_identifiers in addition to identifiers in evidence, it is better to avoid introducing such a big claim at this late stage.

[Torsten Lodderstedt]

I think this issue can and should be solved outside of the OIDC4IDA spec.

[Mark Haine]

I am working on something that quite probably needs an array of this nature.

Where were you thinking this might be solved @Torsten Lodderstedt ?

[Torsten Lodderstedt]

I think this could be done in any spec that can register new JWT claims. Could also be a person identifier spec in the eKYC WG.

[Mark Haine]

I spoke with Mike Jones and he suggested that this requirement may be best delivered as an RFC that creates a registry of types.

[Mark Haine]

Nat suggests URIs for both the type and issuer elements

‌

[Mark Haine]

when we dive into the detail of each type of identifier we need to be really clear that this is identifiers of people and NOT document identifiers

‌

[Joseph Heenan]

and in particular, at least the ‘passport’ entry in the example is a document identifier (it changes each time a passport is renewed/reissued/etc), so shouldn’t be in this list.