Distributed Identity Assurance

Full Title or Meme

Identity Proofing has often been viewed as a centralized function of a Credential Service Provider (CSP), but it can be more efficiently be realized using existing Identity Proofing in many real-world locations.

Context

• This concept of Distributed Identity Proofing is described here as a use case for attaining IAL2 identifier assurance in a Trustworthy Healthcare Ecosystem.
• This concept will be formalized in a "Distributed Identity Assurance Specification" in Kantara.
• Comments on this page or on the specification may be entered as issues on the GitHub page for Distributed Assurance.

Goal

• No person creates their identity in a single place. It's made in the places we work and play, learn and advocate. So it is unlikely that our identity can ever be completely encompassed in one single Credential Service Provider as the currently standardized implementations seem to suggest. What people need is a collection of Verified Claims that they can call upon as needed in their daily lives.
• To allow online patient's of one provider to leverage existing Identity Proofing with other providers.

Actors

1. Actor: Patient of one healthcare provider seeking services at another (refereed) provider.
2. Actor: Patient's Phone as Health Care Credential
3. Actor: Attestor of claim of high assurance with provided Identifier (aka CSP).
4. Actor: Existing provider of health care services. (Source of Identity Proof and later of patient's PHI.)
5. Actor: Referred provider of health care services. (Sink of Identity Proof and later of patient's PHI.)

Note that it is possible that the patient's Guardian (parent or other) is acting on the patient's behalf in this use case, but that should have no appreciable impact on the flow described here.

Preconditions

• The Patient has acquired a mobile phone for any major provider.
• The Patient has registered at a [primary] healthcare provider (PHP).
• The Patient has been (or will be) referred to another healthcare provider.

Scenarios

Primary Scenario:

1. Patient visits their PHP for an ordinary visit and receives a paper at the end of the visit with instructions for establishing a strong authentication credential on their mobile phone.
2. Patient uses their phone to acquire the native app specific to their device. (Today this would be the Apple or Android app store.)
3. Patient starts the app and picks a friendly name for a new medical identifier that will be assigned by the appropriate process.
4. Patient asks the app to "bind" the new identifier to the Identity Proofing claim that is also on the paper received from the PHP.
5. Typically the patient will use the phone's camera to "enter" the claim into the phone (keying in the claim is possible, but not enjoyable.)
6. Typically the CSP will download a certificate into the users phone

A different path using biometrics:

Failed Paths:

1. Patient has no tolerance for technology and ignores or misunderstands the instructions or the purpose of the exercise.

Results

Accepted Risks:

1. The patient loses the paper allowing some other person to attempt to steal their identity - mitigated by sign up process as described.
2. The patient's phone becomes their authentication method that can be stolen - mitigated by some authentication to enable the phone and some gesture to show presence and intent.

Post Condition:

1. If validation accepted by the CSP, the patient has a phone that can be used for sign in to any participating healthcare provider.

Examples:

Dependencies::

1. Web Sites must be trusted before any user information is released.
2. Trust federations can be used to help users make informed decisions.
3. User consent and trust must begin with no user information transferred.
4. Standards exist to collect needed attributes where-ever they may be.

Workflow

• When patient goes to their phone there are several messages that need to be created.
• Some conventions used here are:

1. Messages are formatted as JSON strings.
2. The Document Object identifiers (doi:) are formatted using Android app rules, ie us.trustregistry.{opaque URL safe ASCII strings} where the first part is the base (or authority) address of the organization that created the document. An alternate would be a url.
3. iat = time at which document was issued in Unix epoch format (a 64 bit number of seconds since 1970-01-01 00:00:00)

The Format of the Distributed Identity Proofing

The DIP will contain (typically on a single page of white paper):

1. The means to access the appropriate phone apps, including instructions.
2. The patient's semi-public record locator in DOI form (this MUST not be the patient's subject identifier internal to the practice).
3. The date that the DIP was issued in Linux Epoch form (seconds since 1970-01-01:00:00:00) as a unique identifier with the DOI
4. The page that contains this information in QR format MUST not have any other patient information than the DOI and date.
   1. The page may have have the PHP identifiers but not even the primary care physician name or number.

For example:
doi:com.regence.iosd79JyyHB98;iat:150938403
or if any weirdness exists in the record locator
doi:"com.regence.iosd79JyyHB98-o.dd";iat:150938403
where the doi: and iat: are optional for programmer's convenience during development.

Acquisition of the mobile App

The only interesting limitation on the mobile app is that it be certified as HIPAA compliant by a competent authority. The following features seem appropriate:

1. contains more than one identifier that can be used by the patient/guardian
2. accepts the validating information - something the patient knows - for example a birth date, other TBD
3. maintains one or more notification address as selected by the patient to receive alerts - for example email address or SMS capable phone number
4. supports the interchange standards as appropriate

Registering with the CSP

• The use enters the QR code and supporting information to the app and clicks "Create Binding".
• The app creates the following JSON object and sends to the CSP
• encrypted to the csp and anti-hammering

{
 doi:  -- from PCP
 iat:  -- from PCP
 sub:  -- subject id to use for our interactions (at least 128 bits of entropy)
 bdate:  -- part of patient proof of possession - may need more here - tbd
 ssa:    --  software statement from phone app
 jwks:  -- patient public key
 signature using patient private key  ( specification/negotiation of key type tbd )
}

CSP Validation of Record Locator DOI

• CSP creates a request to send the the EHR source to verify the birth date of other validation information from the patient.

{
 doi:
 iat:
 bdate:
 signature of CSP
 encrypted for PCP
}

Confirmation from the EHR about the DOI

{
 doi:
 iat:
 status:
 signed by the PCP
 encrypted for the PCP
}

Certificate returned by the CSP

• The CSP must validate all data in the request
• The request should not be valid long - perhaps on time, perhaps for an hour or a day from first use (for case where user has more than one phone)

{
 sub:
 jwks: public key of patient (by reference?)
 purpose: us.trustregistry.aal2  -- doi of the policy to be discovered for the appropriate for this ecosystem.
 identity: from pcp  tbd
 iat:  -- issue date for this cert
 exp:  -- expiry
 csp:  -- csp name as url or doi - must allow anyone to get public key of csp somehow
 signature of csp
}

Sign in process at another provider

This is described in other documentation.

References

• The Identity Proofing Use Case describes the existing, centralized Identity Proofing with a Registration Authority and Credential Service Provider.