Overview

This document will serve as a product facing overview of two of GlobaliDs products GlobaliD Connect and LocaliD.

GlobaliD Connect

GlobaliD Connect is an OAuth2 protocol implementation for the GlobaliD ecosystem with openId Connect support coming in the near future.

GlobaliD Connect allows users to grant third party applications limited access to the users identity and its capabilities within the GlobaliD ecosystem

Demo

Api docs

GlobaliD Connect - Documentation

LocaliD

LocaliD provides a web alternative to the GlobaliD mobile app, allowing users to create and manage their identity through a secure web portal. It’s an extended version of globaliDConnect allowing users to signup for an account as well as log in.

ocaliD accounts are limited in what they can do as not all attestations and other functionalities are available to these users on the web. Most secure operations are only available in the mobile app so users should be encouraged to upgrade their account and download the globaliD app.

This product is still in development but a demo on our staging server is available.

LocaliD - Documentation

User verification

Both globaliDConnect login and localiD support user verification. If your application wants to limit it’s access to users that have attested specific information you can do so by creating an attestation claims requirements configuration.

The list of attestation types that can be requested from users can be found here

You are able to define your conditions by specifying which attestations the user needs, which attestations are optional (it’s ok if the user doesn’t have them but if they do they should match specified conditions ) and one of condition that requires the user has one of the attestation types.

Currently requirements need to be requested via email to

Example

An online exchange requires their users to have an attested first name, last name and address on file and that the information had to have come from an identity card or a passport.

They have researched the attestation agencies in our system and like the process of Au10tix and Onfido, so they want the data to come from them.

It’s also critical to them that the data was attested to recently so the attestations must not be older then 1 week.

The second requirement is that they have an email on file with globaliD so that in the future they can use the globaliD notification system to reach out to the user via email. They will use the mandril attestation agency for this.

This translates to a very simple DSL object:

requirements:
  requirement1:
    agency_app_uuid: ["83d06855-037e-4b94-9909-ed2a1136d63d", "0b66efb6-7ca2-4c0f-8554-c0c127f303c2"] // UUIDs of agencies you approved
    created_at_lte: 604800 // Seconds in a week
    allOf: ["legal_first_name", "legal_last_name", "address"]
    oneOf: ["identity_card_number", "passport_number"]`

  requirement2:
    agency_app_uuid: ["c4ecd19d-a6c5-488c-904b-0e508ab221ec"] // UUID of mandril
    allOf: ["email"]

User logging in with required attestations

When a user has all the required attestations they simply confirm the login
in their mobile app or approve the login as they would on any other oauth2 flow.

None of the data is shared with the third party application, it is only checked that it validates the requirements.

User loging in without required attestatiosn

When a user is missing attestations that fit your conditions they are presented with our Missing Attestations Flow which guides the user through
the process of getting attested.

Once attested they can login to your application