document type nowhere defined

[Axel Nennker]

I was looking for the place where values for document.type are defined, but I did not find no place that defines e.g. idcard as a possible value. The only mention of idcard is in the example in openid-connect-authority.md and in openid-connect-4-identity-assurance.md and in files in the example directory.

Although document types vary between validation schemes but some seem to be quite ubiquous like idcard, residentpermit, or passport.

If these are not defined somewhere, I suggest to add them.

In case I am blind and missed something, please enlighten me where idcard and resident permit are defined.

‌

axelnennker$ find . -type f -exec fgrep idcard {} \; -print
       "idcard",
./openid-connect-authority.md
            "type": "idcard",
./examples/response/userinfo.id_token.json
              "type": "idcard"
./examples/response/multiple_verified_claims.json
            "type": "idcard",
./examples/response/document_verifier.json
              "type": "de_erp_replacement_idcard",
./examples/response/derived_claims_1.json
            "type": "idcard",
./examples/response/id_document_id_document.json
            "type": "de_erp_replacement_idcard",
./examples/response/document_and_utility_statement.json
            "type": "idcard",
./examples/response/external_attachments.json
            "type": "idcard",
./examples/response/document_with_attachments.json
                  "idcard",
./examples/request/verification_aml_with_attachments.json
                  "idcard",
./examples/request/verification_aml.json
The following example shows that the RP wants to obtain an attestation based on the German Anti Money Laundering Law (trust framework `de_aml`) and limited to End-Users who were identified in a bank branch in person (physical in person proofing - method `pipp`) using either an `idcard` or a `passport`.
       "idcard",
./openid-connect-4-identity-assurance.md

‌

[Mark Haine]

Hi Axel, for now we have a wiki page at https://bitbucket.org/openid/ekyc-ida/wiki/identifiers however I am not really satisfied with that as it is not terribly well governed or managed. There is an intent and corresponding issue #1339 raised to define profiles for a range of elements of the spec that are specific to particular implementations and my own view is that a register of evidence types (including types of document) is needed and a register of standardised verification and validation processes (and their corresponding representation) will be needed. We have not had implementers participte in teh working group ask us to do that for specific types yet but I anticipate that happening fairly soon for ecosystems in Australia, UK, and US. If we don’t do this then there will be an interoperability issue and I think that is the root of your concern.

If you wish to contribute to that effort from a European perspective that would be fabulous.

[Axel Nennker]

I assume @selfissued has an opinion on IANA registries…

I suggest publishing the identifiers IANA-style on the public ekyc-spec page https://openid.net/wg/ekyc-ida/specifications/ not or additionally to the wiki

[Mark Haine]

A number of people have a view on IANA registries. I don’t think that @selfissued works on Bitbucket but hopefully @MikeJones does.

I agree that some sort of discussion about registries is needed. The OIDF does not really have the procedures in place for ongoing management of such things IMHO so I am not hugely comfortable with extending into that domain without some additional supporting infrastructure. However, I am well aware that there are some challenges with other registries that exist.

Can I take from yor reply that you have an interest in this topic that is driven by real implementation need? I woudl be super keen to hear about that if you are.

[Axel Nennker]

The eKYC-IDA format is in production for three years. If a congstar or DT customer wants to activate their pre-paid-SIM-card we are required to collect their data. TKG§172
In the DT shop the shop agent is electronically reading the German idcard or resident permit and the data is sent to the congstar or DT backend, which activates the SIM-card.

We are now adding a new use case and a new backend, which requires me to check the documentation. When I looked here I could not find the document types etc anymore.

Below is an old example we are using. The build system has a json schema validator. Torsten provided me with a schema but I did not test whether this works with current schema.

//Axel

‌

I redacted the jwt which is an access token where the jti is an internal process id

{
"verified_claims": {
"verification": {
"trust_framework": "de_tkg111",
"time": "2021-02-11T19:04:42.471Z",
"verification_process": <JWT>,
"evidence": [
{
"type": "id_document",
"method": "onsite",
"verifier": {
"organization": "Telekom Deutschland GmbH",
"txn": "_54b2015a-3fb8-48af-a6d1-2446d58e3867"
},
"time": "2021-02-11T19:04:42.471Z",
"document": {
"type": "idcard",
"date_of_expiry": "2029-11-30"
}
}
]
},
"claims": {
"restrictedId": "5a4a9f25a60a8f99064c4e0719a893198869fa06c10d22988c53575593db2a8f",
"given_name": "ERIKA",
"family_name": "MUSTERMANN",
"birthdate": "1964-08-12",
"address": {
"locality": "FLOH-SELIGENTHAL OT STRUTH-HELMERSHOF",
"postal_code": "98593",
"street_name": "Hauptstraße",
"house_number": "94",
"country": "DE"
}
}
}
}

‌

[Mark Haine]

So the update is thus: The OpenID Foundation has discussed the topic of acting as a registry provider in the past and this is not something the OIDF would like to do. The guidance I have is that IANA can support registries for non-iana originated things. I will follow up with MikeJ and JohnB report back