LastCheckResultV3

SourceV3

RegistrationDetailsV3

Address

The Address object is intended to serve as a container for address information for countries with a variety of different address schemes and formats.  The fields that are present or required will depend on the country that is specified.  Similarly, fields may have different validation rules depending on the country, for example, the field "postcode" must be a four digit string for an Australian address, but it must be a five digit string for a US address.  For requirements for individual countries, please refer to Address Handling or contact greenID.

Name

The Name complex type has the following structure: 

VerificationResultV3

CheckResultV3

Combination sources, as the name suggests, combine multiple things into a single source.  Combination sources are used when the greenID Mobile SDK captures an identity document for verification.  A combination source will always have the following three components present:

• document authenticity - this component represents the outcome of the automated authenticity and integrity checks that are performed on the image of the document to ensure it is an authentic document, and has not been subject to digital tampering.
• data extraction - this component represents the data that was automatically extracted from the card, and how it relates to the data that the person confirmed.
• document registration match - this component represents the comparison between the details that the person confirmed and the master record.

An example of an XML snippet for the document authenticity component is below, showing an Australian ACT driver's licence that was deemed authentic, indicated by the VERIFIED state:

<individualResult>
   <documentRegion>AU</documentRegion>
   <documentSubRegion>ACT</documentSubRegion>
   <documentType>DRIVERS_LICENCE</documentType>
   <method>interactive</method>
   <name>Document Authenticity</name>
   <state>VERIFIED</state>
</individualResult>

Components initially in a pending state have the option of being reviewed; during this process the administrator is required to give a comment on the review. These comments can be returned in the API if configured. The XML captures the comment, the date and time it was made, and the email address of the administrator making the change. An example of the XML that was verified by an administrator is seen below:

<individualResult>
    <dateVerified>2018-12-04T10:31:28.440+1000</dateVerified>
    <fieldResult>
        <data>Ive uploaded a picture of a big beer can</data>
        <extraData>
            <name>Date</name>
            <value>2018-12-04 10:31:28.44</value>
        </extraData>
        <extraData>
            <name>AdminEmail</name>
            <value>admin@edentiti.com</value>
        </extraData>
        <name>AdminComment</name>
    </fieldResult>
    <method>interactive</method>
    <name>Telephone Bill</name>
    <state>VERIFIED_ADMIN</state>
</individualResult>

When a document image is captured by the greenID Mobile SDK, the person has the chance to review the data that was automatically extracted from the image to correct any errors that the OCR process might have made.  The results of the OCR process and the so-called "confirmed data" are compared to see how well the OCR process performed, and how many changes the person had to make. If no changes were made, then the data extraction component will be in the VERIFIED state, as in the example below:

<individualResult>
   <fieldResult>
      <name>GovId</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>documentNumber</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>dob</name>
      <status>CONFIRMED</status>
      <value>1976-04-01</value>
   </fieldResult>
   <fieldResult>
      <name>surname</name>
      <status>CONFIRMED</status>
      <value>Smith</value>
   </fieldResult>
   <fieldResult>
      <name>givenName</name>
      <status>CONFIRMED</status>
      <value>John</value>
   </fieldResult>
   <method>interactive</method>
   <name>Data Extraction</name>
   <state>VERIFIED</state>
</individualResult>

The comparison between the data that was read during OCR and the confirmed data is subject to the greenID controlled changes process.  If the changed made by the person are automatically accepted by the controlled changes process, then the data extraction component can have the VERIFIED_WITH_CHANGES state.  If the changes are too large, then the data extraction component can be in the PENDING state, as in the example below where the person changed their surname:

<individualResult>
   <fieldResult>
      <name>GovId</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>documentNumber</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>dob</name>
      <status>CONFIRMED</status>
      <value>1976-04-01</value>
   </fieldResult>
   <fieldResult>
      <changedValue>Jones</changedValue>
      <extractedValue>Smith</extractedValue>
      <name>surname</name>
      <status>CHANGED</status>
   </fieldResult>
   <fieldResult>
      <name>givenName</name>
      <status>CONFIRMED</status>
      <value>John</value>
   </fieldResult>
   <method>interactive</method>
   <name>Data Extraction</name>
   <state>PENDING</state>
</individualResult>

As with regular data sources in greenID, a comparison is made between the data used to check the data source and the master record.  Combination sources are the same in this regard.  When a person confirms the details extracted from their ID document, with or without changes, the "confirmed data" is compared to the master record, and the changes are subject to the greenID controlled changes process.  (The confirmed data may also be used with an external data source, depending on customer account configuration.)  The document registration match component reflects this comparison.  The XML snippet below shows a document registration match component where no data was changed by the person during the confirmation step:

<individualResult>
   <dateVerified>2017-01-19T11:37:11.796+0000</dateVerified>
   <fieldResult>
      <name>documentScan</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>face</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>dob</name>
      <status>CONFIRMED</status>
      <value>1976-04-01</value>
   </fieldResult>
   <fieldResult>
      <name>givenName</name>
      <status>CONFIRMED</status>
      <value>John</value>
   </fieldResult>
   <fieldResult>
      <name>surname</name>
      <status>CONFIRMED</status>
      <value>Smith</value>
   </fieldResult>
   <method>interactive</method>
   <name>Document Registration Match</name>
   <state>VERIFIED</state>
</individualResult>

Of course, the person may make changes during the confirmation step, and if these changes are too large, the document registration match component can be in the PENDING state, as in the example below where the person changed their surname:

<individualResult>
   <fieldResult>
      <name>documentScan</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>face</name>
      <status>CONFIRMED</status>
      <value/>
   </fieldResult>
   <fieldResult>
      <name>dob</name>
      <status>CONFIRMED</status>
      <value>1976-04-01</value>
   </fieldResult>
   <fieldResult>
      <name>givenName</name>
      <status>CONFIRMED</status>
      <value>John</value>
   </fieldResult>
   <fieldResult>
      <changedValue>Jones</changedValue>
      <masterRecordValue>Smith</masterRecordValue>
      <name>surname</name>
      <status>CHANGED</status>
   </fieldResult>
   <method>interactive</method>
   <name>Document Registration Match</name>
   <state>PENDING</state>
</individualResult>

There are two more components to a combination source that may appear, depending on customer account configuration:

• data source - an external data source that can verify the data read from the document, for example, the government department that issues passports.
• face comparison - a comparison between the image of a person extracted from an identity document, such as a passport, and a live selfie of the person captured by the greenID Mobile SDK.

If the data source element is present, then the name of the data source and state of the check will be present, for example, the snippet below shows the data source associated with Australian passports was checked and passed:

<individualResult>
   <method>interactive</method>
   <name>PassportDVS</name>
   <state>VERIFIED</state>
</individualResult>

The face comparison component will only be present if face comparisons are configured on the customer's account.  If present, the face match score and the state of the face comparison will be present, for example:

<individualResult>
   <faceMatchScore>55</faceMatchScore>
   <method>interactive</method>
   <name>Face Comparison</name>
   <state>VERIFIED</state>
</individualResult>

FieldResultV3

<fieldResult>
   <name>dob</name>
   <status>CONFIRMED</status>
   <value>1976-04-26</value>
</fieldResult>

<fieldResult>
   <changedValue>1976-04-01</changedValue>
   <masterRecordValue>1980-01-01</masterRecordValue>
   <name>dob</name>
   <status>CHANGED</status>
</fieldResult>

<fieldResult>
   <name>surname</name>
   <status>CONFIRMED</status>
   <value>Smith</value>
</fieldResult>

<fieldResult>
   <changedValue>Jones</changedValue>
   <extractedValue>Smith</extractedValue>
   <name>surname</name>
   <status>CHANGED</status>
</fieldResult>

 <fieldResult>
    <name>surname</name>
    <status>CONFIRMED</status>
    <value>Smith</value>
 </fieldResult>

 <fieldResult>
    <changedValue>Jones</changedValue>
    <masterRecordValue>Smith</masterRecordValue>
    <name>surname</name>
    <status>CHANGED</status>
 </fieldResult>

The PostOfficeDataV3 complex type and the following members are for the most part exact representations of the fields found in an Australia Post contract. The reader should be aware of the individual Australia Post contract they will be using to ensure that they can match up the fields. These fields are retrieved from a flat file and stored in Strings with no interpretation of the meanings of the fields. Not all implementations of an Australia Post contract will have all the fields detailed below.

The complex type DetailRecordHeader has the structure described below:  

DocumentRecord 

The DocumentRecord complex type has the structure described below:  

NameValuePair

The NameValuePair complex type has the following structure: