[OpenID-Specs-eKYC-IDA] json validation and PPID

Axel.Nennker at telekom.de Axel.Nennker at telekom.de
Wed Feb 10 16:30:14 UTC 2021


Hi Kai,



my code is now producing this json.



{

  "verified_claims": {

    "verification": {

      "trust_framework": "de_tkg111",

      "time": "2021-02-10T15:56:20.323Z",

      "verification_process": "<jwt-redacted>",

      "evidence": [

        {

          "type": "id_document",

          "method": "onsite",

          "verifier": {

            "organization": "Telekom Deutschland GmbH",

            "txn": "_71fdb2dd-5ff7-4585-a7d4-d034f9383de2"

          },

          "time": "2021-02-10T15:56:20.323Z",

          "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"

      }

    }

  }

}



restrictedId is in the claims. I guess this should be restricted_id or PPID?

Street_address is replaced by street_name and house_number (all the three backends I am sending data to need the house_number separately).

I redacted the verification_process because I chose to have an jwt access token in that field which is not public

The txn is the ID of the SAML assertion I get back from the Governikus eid-server.





Kind regards

Axel


<?xml version="1.0" encoding="UTF-8"?>
<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="redacted" ID="_68f9b0df-abe3-4934-974a-a0df1193ef1d" InResponseTo="_6452ce5c-7c0d-4571-8ab3-df7fe543823f" IssueInstant="2021-02-10T15:56:19.801Z" Version="2.0">
  <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">Governikus Autent</saml2:Issuer>
  <saml2p:Status>
    <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </saml2p:Status>
  <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="_71fdb2dd-5ff7-4585-a7d4-d034f9383de2" IssueInstant="2021-02-10T15:56:19.798Z" Version="2.0">
    <saml2:Issuer>Governikus Autent</saml2:Issuer>
    <saml2:Subject>
      <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" NameQualifier="Governikus Autent">ef542df5-965c-46bb-ac11-3e357c1d0ba7</saml2:NameID>
      <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml2:SubjectConfirmationData Address="87.159.179.136" InResponseTo="_6452ce5c-7c0d-4571-8ab3-df7fe543823f" NotOnOrAfter="2021-02-10T16:06:19.798Z" Recipient="redacted"/>
      </saml2:SubjectConfirmation>
    </saml2:Subject>
    <saml2:Conditions NotBefore="2021-02-10T15:56:19.798Z" NotOnOrAfter="2021-02-10T16:06:19.798Z">
      <saml2:AudienceRestriction>
        <saml2:Audience>redacted</saml2:Audience>
      </saml2:AudienceRestriction>
      <saml2:OneTimeUse/>
    </saml2:Conditions>
    <saml2:AuthnStatement AuthnInstant="2021-02-10T15:56:19.798Z">
      <saml2:AuthnContext>
        <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI</saml2:AuthnContextClassRef>
        <saml2:AuthnContextDeclRef>urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI</saml2:AuthnContextDeclRef>
      </saml2:AuthnContext>
    </saml2:AuthnStatement>
    <saml2:AttributeStatement>
      <saml2:Attribute Name="LevelOfAssurance">
        <saml2:AttributeValue xmlns:idp="http://bsi.bund.de/eID/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="idp:LevelOfAssuranceType">http://bsi.bund.de/eID/LoA/hoch</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="DateOfBirth">
        <saml2:AttributeValue xmlns:idp="http://bsi.bund.de/eID/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="idp:GeneralDateType">
          <idp:DateString>19640812</idp:DateString>
          <idp:DateValue>1964-08-12</idp:DateValue>
        </saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="RestrictedID">
        <saml2:AttributeValue xmlns:idp="http://bsi.bund.de/eID/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="idp:RestrictedIDType">
          <idp:ID>5A4A9F25A60A8F99064C4E0719A893198869FA06C10D22988C53575593DB2A8F</idp:ID>
        </saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="GivenNames">
        <saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">ERIKA</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="DocumentValidity">
        <saml2:AttributeValue xmlns="http://bsi.bund.de/eID/" xmlns:idp="http://bsi.bund.de/eID/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Version="1" xsi:type="idp:DocumentValidityResultType">
          <idp:ReferenceDate>2021-02-10</idp:ReferenceDate>
          <idp:Status>valid</idp:Status>
        </saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="DocumentType">
        <saml2:AttributeValue xmlns:idp="http://bsi.bund.de/eID/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="idp:DocumentType">ID</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="FamilyNames">
        <saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">MUSTERMANN</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="PlaceOfResidence">
        <saml2:AttributeValue xmlns:idp="http://bsi.bund.de/eID/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="idp:GeneralPlaceType">
          <idp:StructuredPlace>
            <idp:Country>D</idp:Country>
            <idp:City>FLOH-SELIGENTHAL OT STRUTH-HELMERSHOF</idp:City>
            <idp:ZipCode>98593</idp:ZipCode>
            <idp:Street>Hauptstraße 94</idp:Street>
          </idp:StructuredPlace>
        </saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="DateOfExpiry">
        <saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:date">2029-11-30</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="AcademicTitle">
        <saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string"/>
      </saml2:Attribute>
    </saml2:AttributeStatement>
  </saml2:Assertion>
</saml2p:Response>



-----Original Message-----
From: Kai Lehmann <kai.lehmann at 1und1.de>
Sent: Dienstag, 9. Februar 2021 10:05
To: OpenID eKYC Identity Assurance Working Group <openid-specs-ekyc-ida at lists.openid.net>; torsten at lodderstedt.net
Cc: Nennker, Axel <Axel.Nennker at telekom.de>
Subject: Re: [OpenID-Specs-eKYC-IDA] json validation and PPID



Hi Alex,



For De-Mail, we at 1&1 also use the restricted id provided by the eID service for identification/authentication. It seems restricted ids is not only used in German eID cards, but also in eHealth cards outside of Germany. Putting it inside of the claims section would be my preference as well. That said, I suggest to stick to the snake_case naming convention used everywhere. So if there is no objection, I can create a PR to add restricted_id to the list of new claims.



/Kai



On 08.02.21, 20:52, "Openid-specs-ekyc-ida on behalf of Axel.Nennker--- via Openid-specs-ekyc-ida" <openid-specs-ekyc-ida-bounces at lists.openid.net on behalf of openid-specs-ekyc-ida at lists.openid.net<mailto:openid-specs-ekyc-ida-bounces at lists.openid.net%20on%20behalf%20of%20openid-specs-ekyc-ida at lists.openid.net>> wrote:



    HI Torsten,



    thanks for the quick answer. I think I figured it out.

    My understanding of the validator was wrong. My bad.

    So, the json validates OK.

    I looked for version differences first, as well. Then, I took an example from the working group and is appeared to be invalid as well. Which seems unlikely. So, I looked for an error in my validation code and found it.



    Regarding the restrictedId, PPID, pcr, I think I will put it in the list of claims. Seems simplest and that way I don't have to change the schema.



    Although I might fiddle with a variant of the schema. I think if the trust_framework is de_tkg111 then some values are not optional anymore.

    Maybe I succeed to put that into the schema.



    I would be happy to chat with you and the group regarding which values to use for txn etc and describe DT's use case. Would be happy if other MNO chime in, too. So, we can standardize more.



    Thanks again

    Axel









    -----Original Message-----

    From: Torsten Lodderstedt <torsten at lodderstedt.net<mailto:torsten at lodderstedt.net>>

    Sent: Montag, 8. Februar 2021 18:53

    To: Nennker, Axel <Axel.Nennker at telekom.de<mailto:Axel.Nennker at telekom.de>>

    Cc: OpenID eKYC Identity Assurance Working Group <openid-specs-ekyc-ida at lists.openid.net<mailto:openid-specs-ekyc-ida at lists.openid.net>>

    Subject: Re: [OpenID-Specs-eKYC-IDA] json validation and PPID



    Hi Axel,



    I think this could be due to different interpretations of JSON schemas.



    I will get in contact with you directly.



    best regards,

    Torsten.



    > Am 08.02.2021 um 12:17 schrieb Axel.Nennker--- via Openid-specs-ekyc-ida <openid-specs-ekyc-ida at lists.openid.net<mailto:openid-specs-ekyc-ida at lists.openid.net>>:

    >

    > Hi,

    >

    > we, Deutsche Telekom, have a server that allows us to read German eIDs (id_card) and eATs (de_erp).

    >

    > I want to forward the information read from the card to some sales backend using the ekyc_ida format.

    >

    > Here is a json generated by a unit test – hence the dummy values.

    >

    >

    > {

    >   "verified_claims": {

    >     "verification": {

    >       "trust_framework": "de_tkg111",

    >       "time": "2021-02-07T10:53:18.557729Z",

    >       "verification_process": "verification_process_dummy",

    >       "evidence": [

    >         {

    >           "type": "id_document",

    >           "method": "onsite",

    >           "verifier": {

    >             "organization": "organization_dummy",

    >             "txn": "txn_dummy"

    >           },

    >           "time": "2021-02-07T10:53:18.558089Z",

    >           "document": {

    >             "type": "idcard",

    >             "restrictedId": "5a4a9f25a60a8f99064c4e0719a893198869fa06c10d22988c53575593db2a8f",

    >             "date_of_expiry": "2029-11-30"

    >           }

    >         }

    >       ]

    >     },

    >     "claims": {

    >       "given_name": "ERIKA",

    >       "family_name": "MUSTERMANN",

    >       "birthdate": "1964-08-12",

    >       "address": {

    >         "locality": "KÖLN",

    >         "postal_code": "51147",

    >         "street_address": "HEIDESTRASSE 17",

    >         "country": "DE"

    >       }

    >     }

    >   }

    > }

    >

    > What I added to the ekyc_ida format is “restrictedId”, which is an identifier depending on the server’s authorization certificate and the card’s id.

    > RestrictedID is something like a pseudonymous customer reference from Mobile Connect or Pairwise Pseudonymous Identifier from OpenID Connect Core Spec.

    > So I was not sure where to put “restrictedId” – it could be under verifier AND document with equal justification.

    >

    > Could you please help me on this? Is the json valid according the ekyc_ida schema?

    > https://bitbucket.org/openid/ekyc-ida/src/master/schema/verified_claims.json

    >

    > I checked using an online json schema validator which says it is valid. https://www.jsonschemavalidator.net/

    > But using a java schema validator in my unit tests it comes out as invalid.

    >         <dependency>

    >             <groupId>com.networknt</groupId>

    >             <artifactId>json-schema-validator</artifactId>

    >             <version>1.0.48</version>

    >             <scope>test</scope>

    >         </dependency>

    >

    > To summarize:

    >        • Is the json valid?

    >        • Where to put the restrictedId?

    >        • Add restrictedId to schema?

    >

    >

    > --

    > Openid-specs-ekyc-ida mailing list

    > Openid-specs-ekyc-ida at lists.openid.net<mailto:Openid-specs-ekyc-ida at lists.openid.net>

    > https://www.google.com/url?q=http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida&source=gmail-imap&ust=1613387847000000&usg=AOvVaw2NiPAlftR0mY30osU9AXOy



    --

    Openid-specs-ekyc-ida mailing list

    Openid-specs-ekyc-ida at lists.openid.net<mailto:Openid-specs-ekyc-ida at lists.openid.net>

    http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ekyc-ida/attachments/20210210/d732f326/attachment-0001.html>


More information about the Openid-specs-ekyc-ida mailing list