A public description of the "Identity Cooperative" concept. Feedback encouraged!
The "ID CoOp" was created to facilitate online access to people's own sensitive information such as healthcare and financial information. By providing a higher-level of "you are who you say you are", other systems who hold sensitive information (i.e. resource providers) can rely on the ID CoOp to assert a higher level of assurance of a person's identity.
When a person logs in or connects an application "ID CoOp", the application is informed about you and your identity assurance level. How sure ID CoOp is, that "you are who you say you are" is categorized as a "identity assurance level" of either a 1
, 2
, or 3
). These levels (1
,2
,3
) are based on NIST Digital Identity Guidelines SP 800-63-3. When a person logs in or connects to the ID CoOp from another application, these "claims" (including name, etc.) are passed to the application in in a digitally signed electronic credential known as an ID token (id_token
). See this faq form more information on how it works.
- The CoOp is collectivly funded by organizations who collectivly rely on its information. The "Relying Parties" fund the CoOp and typically have one or more applications connected to the CoCp. Organizations my use the ID CoOp as a single sign-on for the agents (e.g. employees or contractors), for their Member base, or both.
- Organizations agree to accept\rely on the identity assurance claims
ial
established by others outside their organization. - Organizations that function as relying parties may include; health care organizations, financial institutions, insurance companies, state governments, federal agencies, or community-based organizations.
- An Organization's membership in the CoOp is currently restricted to organizations based in the United States, but an international version may be established in the future.
- The CoOp is an open source project. Its code base is managed by TransparentHealth, a non-profit open source software foundation.
The "ID CoOp" will provide a single sign-on service similar to Google OpenID Connect. ID CoOp shall provide an electronic credential bearing an identity assurance claim. Third party applications will function as "relying parties" and rely on the identity electronic credential. Users who have been given the "ID referee badge" may verify the Identity of other users. Users can be "agents" of Organizations. This models employer to employee (or contractor, etc.) relationships. These relationships are included in the user's electronic credential (id_token
).
The ial
claim can be changed from the default of 1
(untrusted) to 2
by adding documentation of an identity proofing event. This can happen in multiple ways.
- Users in the "Tusted Referee" permission group can raise or lower other user's identity asurtance level. Adherence to our code of coduct is required.
- Trusted applications can raise or lower other user's identity asurtance level via a RESTFul API.
The ID CoOP is based on open source open id connect provider "Verify My Identity" https://github.com/TransparentHealth/vmi. Here is a partial list of some key features already available.
- Open ID Connect Core
- Open ID Connect Discovery
- NIST SP 800-63-3 IAL as
ial
claim inid_token
- NIST SP 800-63-3 AAL as
aal
claim inid_token
- SMS one-time-password multi-factor authentication.
aal
=2
inid_token
. - FIDO U2F/2 multi-factor authentication.
aal
=2
inid_token
. - Self-service user management interface including profile photo
- Identifiers can be added to user accounts. Can be anything such as an state or federal ID number, master patient index, etc./)
- Organization agent user interface
- Organization setup administrative user interface. (i.e. add/remove individual agents from and Organization.)
- Organization agent user interface with user search.
- Trusted referee user interface with user search.
- API trusted 3rd parties to provide identity assurance information. (effectively raise\lower a user’s
ial
)
The ID CoOP is based on open source open id connect provider "Verify My Identity" https://github.com/TransparentHealth/vmi.
(Yes you or your organization can commission the Transparent Health foundation to implement items on this list. )
- Remote ID proofing user interface
- OAuth 2.0 for Native Mobile Applications: https://tools.ietf.org/html/rfc8252 (Already done in BB 2.0 API. just move it over.)
- DOAuth 2.0 Dynamic Client Registration Protocol: https://tools.ietf.org/html/rfc7591)
- Application Proofing\Signing User Interface with tie to Dynamic Client Registration
- Support for Google Authenticator as a form of 2nd factor authentication.
- Support for push notifications as a form of 2nd factor authentication. (preferred over SMS).
These next 3 are related....
- Document Signing and Publication interface. Consent Receipt Specification: https://kantarainitiative.org/confluence/display/infosharing/Consent+Receipt+Specification
- Digital wallet public/private keypair for document signing and signature. A Mnemonic (list of words) will allow for a private key’s recovery.
- DNS for publication of public keys and signatures. DNS will provide both provenance and a distributed architecture (characteristics of a blockchain without a blockchain).
- You must first sign up as an organization and register your application just like any other OAuth2/OpenID Connect application. Pilot your application in our sandbox environment.
- If accessing sensitive information, such as protected personal health information (PHI), a client MUST rely on the identity claim in the OpenID Connect identity token (
id_token
). - Your app must not grant access to one's own health information unless and IAL of
2
is established. - You application must use https in production when calling any of our APIs.
- Your callback
redirect_uris
may not usehttp
in production.https
in production. - For production access your application must be vetted. We will give you a signed JWT (i.e JWS) as a badge that your application is approved. This is also your application's "ticket" to dynamic client registration. Pass it in the header with your request when using the DynReg endpoint.