...
Name | Type | Description |
---|---|---|
|
| The type of HTML input that is required (at least strongly suggested) for collecting the data for this field from the person. For example, a value of “text” would indicate a simple HTML text input is appropriate. |
|
| The name of the HTML input that would collect data for this field from the person. The name also indicates what the data field is, for example, the value “aec_givenname” indicates the field holds the given name for the AEC data source. |
|
| This member contains any pre-existing value for the HTML field. For example, the |
label | String | This member contains label. Please refer to the section on Labels. |
selectItem | List<NameValuePair> | This member contains a list of item names and values for a select item FieldV3 . |
attribute | List<=NameValuePair> | This member contains a list of the names and values of any HTML attributes that this Field has. For example, the attribute class=”required” would be represented by a NameValuePair with name=”class” and value=”required” . |
InputFields
...
Name | Type | Description |
---|---|---|
|
| The day component of a date of birth. |
|
| The month component of a date of birth. |
|
| The full year component of a date of birth, for example 1975, i.e. not 75. |
RegistrationDetailsV3
Name | Type | Description | Contract |
---|---|---|---|
currentResidentialAddress | Address | The person's current residential address. | |
dateCreated | String | The timestamp of when this verification attempt was created. The string will be formatted in the ISO 8601 format. The pattern used to generate this string in Java is yyyy-MM-dd'T'HH:mm:ss.SSSZ . | |
dob | DateOfBirth | The person's date of birth. | |
email | String | The person's email address. | May be null. Must Must be a valid email address following the Standard Hibernate validation and checking Top Level Domain (TLD) is valid. See https://data.iana.org/TLD/tlds-alpha-by-domain.txt |
extraData | List<NameValuePair> | Any extra data elements that were supplied with the original registration. Identifier such as document numbers will not be present in the list, even if they were supplied at registration time. | Zero or more elements. |
homePhone | String | If present, must be 10 digits only. | |
mobilePhone | String | If present, must be 10 digits only. | |
name | Name | The person's name. | |
previousResidentialAddress | Address | The person's previous residential address. | |
workPhone | String | If present, must be 10 digits only. |
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 | Type | Description | Contract |
---|---|---|---|
alley | String | ||
amalgamatedMunicipality | String | ||
area | String | ||
avenue | String | ||
block | String | ||
canton | String | ||
chome | String | ||
city | String | ||
country | String | The country code. This must be the ISO 3166 country code. The country code can be given in either the alpha-2, alpha-3 or numeric format. | Please refer to https://www.iso.org/obp/ui/#search for a full (and up to date) list of ISO 3166 country codes. |
county | String | ||
deliveryNumber | String | ||
department | String | ||
direction | String | ||
dispatchingInformation | String | ||
district | String | ||
divisionFive | String | ||
divisionFour | String | ||
divisionOne | String | ||
divisionThree | String | ||
divisionTwo | String | ||
flatNumber | String | ||
level | String | ||
locality | String | ||
location | String | ||
mailCentre | String | ||
municipality | String | ||
neighbourhood | String | ||
organisation | String | ||
parish | String | ||
personName | String | ||
poBox | String | ||
postcode | String | ||
prefecture | String | ||
propertyName | String | ||
province | String | ||
quarter | String | ||
region | String | ||
ruralArea | String | ||
ruralLocality | String | ||
sector | String | ||
sectorNumber | String | ||
state | String | ||
streetName | String | ||
streetNumber | String | ||
streetType | String | ||
subdistrict | String | ||
subregion | String | ||
suburb | String | ||
town | String | ||
townCity | String | ||
township | String | ||
urbanLocality | String | ||
village | String |
Name
The Name
complex type has the following structure:
Member | Type | Required? | Description | Contract |
---|---|---|---|---|
|
| No | The honorific component of a person’s name, e.g., “Mr”, “Miss”, etc. | Max 255 characters. |
|
| Yes | A person’s given name. | Cannot be null. Cannot be the empty string. Max 255 characters. |
|
| No | A person’s middle names. Note that there can be multiple names. | Max 255 characters. |
|
| Yes | A person’s surname or last name. | Cannot be null. Cannot be the empty string. Max 255 characters. |
VerificationResultV3
...
Name | Type | Description | |||
---|---|---|---|---|---|
|
| The name of the check. For example, if a check against the Electoral Roll was attempted, then the name would be “AEC”. As each customer will accept a different set of checks, customers should refer to their individual rules document for the list of names that they can expect. Refer to Data Source Reference for a list of data source names. | |||
|
| The state of the individual check. For a list of possible states, please see the Reference Table of Individual Source States. | |||
|
| The method via which the check was carried out. This is an enumerated type, for a list of possible values, please see the Reference Table of Method Names. | |||
mode | String | The verification mode used for this specific check. This shows HOW the check was made. Please see the Reference Table of possible modes. This can be null which indicates that no mode was used. | |||
dateVerified | String | The date that this particular check became verified (or null if the check is not verified). The string will be formatted in the ISO 8601 format. The pattern used to generate this string in Java is yyyy-MM-dd'T'HH:mm:ss.SSSZ . | |||
fieldResult |
| Only the fields that were successfully checked, or were changed, are returned. Any field that was not checked is not returned. Note that this may mean the list is empty. | |||
postOfficeData | PostOfficeDataV3 | If and only if the name of the CheckResultV3 is “PostOffice” then this member will be present. Otherwise it will be null. This represents the raw data retrieved from Australia Post. | |||
extraData | List<NameValuePair> | Any extra data associated with this check. | individualResult | List<CheckResultV3> | A list of nested |
individualResult | List<CheckResultV3> | A list of nested
These elements are discussed in detail below. | |||
documentType | String | The category the document belongs to. Common values are:
Extra document types will be used as necessary, and if they apply to you, greenID will provide details about the appropriate values. | |||
documentRegion | String | The region or country the document is associated with. The ISO alpha2 country designation is used. | |||
documentSubRegion | String | Some document depend on the state or region within the country that issued them. For example, in Australia, each state issues their own driver's licences, so the state must be included to accurately identify the ID document. | |||
faceMatchScore | String | A string representation of a number that reflects the confidence score that the selfie matches the image extracted from the ID document. The range of valid numbers is 0 to 100. |
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:
Code Block |
---|
<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:
Code Block |
---|
<individualResult> <dateCreated>2018 <dateVerified>2018-0912-18T1504T10:3431:2428.431440+1000</dateCreated>dateVerified> <dateVerified>2018-09-18T15:40:53.774+1000</dateVerified> <fieldResult> <documentRegion>NZ</documentRegion> <data>Ive uploaded <documentType>DRIVERS_LICENCE</documentType>a picture of <fieldResult>a <data>Commentsbig onAuthenticitybeer ATTEMPT<can</data> <extraData> <extraData> <name>Date</name> <value>2018-0912-1804 1510:4031:5328.774<44</value> </extraData> <extraData> <extraData> <name>AdminEmail</name> <value>admin@edentiti.com</value> </extraData> <name>AdminComment</name> </fieldResult> <method>interactive</method> <name>Document <name>Telephone Authenticity<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:
Code Block |
---|
<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:
Code Block |
---|
<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:
Code Block |
---|
<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:
Code Block |
---|
<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:
Code Block |
---|
<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:
Code Block |
---|
<individualResult> <faceMatchScore>55</faceMatchScore> <method>interactive</method> <name>Face Comparison</name> <state>VERIFIED</state> </individualResult> |
FieldResultV3
...