Identity Protection

Federally Managed Identity Authentication Registry

Brandon Gillespie

• 3 min read
Federally Managed Identity Authentication Registry

In the proposal Why Equifax Happened: The Missing Link: Authentication, it is suggested the government manage a registry; but the details are light. Here is a more detailed proposal.

Challenges:

  • There needs to be one source of authority defining how a person wishes to be authenticated.
  • Having the government "own" the authentication itself is frightening; but having them be a custodian of key public information is about perfect for their role.
  • Use existing technologies where possible, but keep it simple. Please suggest alternatives where possible, which are public domain and not beholden to a single intellectual property owner.

The flow:

  • Focus on the use of PII for any binding purpose - credit reports, lending authorization, etc.
  • Use PKI keys to create digital authorization signatures for each binding purpose. This can work like PGP/GPG. The Registry keeps a history of all public keys you have ever used (so the authorization signatures can be verified) and your current authentication service.
  • Lenders and others desiring to use your credit are required to check the registry and authenticate against it if you are registered. Failing to do so leaves them liable for the debt, not you. Repudiation is simply done by verifying the authorization signature against your public keys. This technology works.
  • You are in control - you can change your authentication service at any time. If you want to lock your credit, you do it in one place, with your authentication service. All companies must go to this one location.
  • Use of this registry is not mandatory for people but is for lenders and service providers.
  • Legislation should include that any indirect information which may be gleaned from behavioral patterns off the registry is prohibited for any other purpose than monitoring and operating of the service. No other government or private agency may access this data.
  • Authentication services should follow a published protocol, but anybody can do it, no prior vetting required. Let the free market reign. I expect Google, Facebook and the likes will all jump in, but so will others.

The Use Cases:

  • First Time Authentication to Registry - As a citizen, I go to the registry and set up my authentication for the first time. This is the biggest challenge. I'd love feedback. Simply providing my identification alone is not sufficient, especially after #equifax.

  • Returning Authentication to Registry – This should include TOTP MFA (virtual TOTP okay, like google authenticator).

  • Service Providers Authentication - Service Providers are the lenders and others wanting to authenticate private data - I.e. the Equifaxes of the world. They must maintain an authenticated session to this registry (stronger than a never expiring API key).

  • Register new Public Key – After registry authentication, an easy way to update a new key. Available via API so agents can do this on your behalf, with authorization (perhaps OAuth).

  • Disable a Public Key – Flag a key as being disabled (but not deleted). Only zero or one keys may be active at a time, but a historical record of all keys should always exist. Available via API so agents can do this on your behalf, with authorization (perhaps OAuth).

  • Register a new Authentication Agent – add a new agent for your authentication of identity use.

  • Request Identity Authentication – When a lender wishes to use your identity in a binding manner, the flow:

    1. first query the registry and lookup a user (lenders too must be authenticated - this is not a public / open interface). determine a way of looking up user - PII tokens or generate a new token?
    2. locate the user's authentication service, make a query to this service (HTTP POST perhaps to an endpoint as described in the registry, i.e. https://example.com/startauth. The result of this query is an auth request token, which can be polled for a final status. The post body can also include a callback URL for where to send the final status.
    3. User authentication is out of band and up to the user's desires and the service they selected as to how this works. It may be MFA on a smartphone, or use a physical device, or be simple passwords. The options are wide open.
    4. When authentication is completed, the authorizing service generates a digital signing signature using the user's private key and sends this back to the requesting service provider. One unique signature for each request.
    5. The authentication signature is provided back to the service provider as a JSON object (figure out standardized format). It is verified as legitimate against the user's currently registered public key.
    6. Failure to authenticate within a time frame is implicit rejection (perhaps 30 minutes).

Other concerns/thoughts:

  • Authentication services should store private keys very carefully. It could even be setup such that the authentication service never even touches the private keys--they are maintained entirely by the user.
  • Use a blockchain where it makes sense. Key is to maintain the ability to revoke and change private keys.
  • Consider options for a distributed blockchain like database. If it is an open blockchain, the problem arises in how to start it.

There are many more details to flesh out, and this is just a first pass, for those technical people who were wondering what I was thinking.