Difference between revisions of "Patient Credential"

Revision as of 16:40, 31 July 2019

Full Title

The format of the document sent from a Identity Proofing provider to the device where it is combined with some private key of the patient to create the Credential.

Context

• Strictly speaking this format is for a document that can be used to create the working Credential in a device controlled by the patient.
• When a patient has gone through Identity Proofing and is "known to the practice", the Patient Credential can be installed on the patient's User Device to allow IAL2 level of assurance authentication to access their PHI at the EHR.
• It is the job of the Credential Service Provider to assure that the process of installing the Patient Credential results in a working Credential can will provide IAL2 level of assurance.
• Before the patient can enable a User Device, a trusted User Agent must be installed and at least one patient Identifier created to use with the device.
• Note that the Identifier of the issuer will be the practice (PCP), but the Identifier of the Data Controller of the EHR may be different. It is required that the two Identifiers are both part of the same Trust Anchor so that the patient (or guardian) will trust one because of the trust of the other.

Installation of the Credential

The primary purpose of the installation process, which is mediated by the Credential Service Provider it is assure that the patient's authentication key is installed on the User Device in a manner which provides assurance that the patient (or guardian) is the one at the device was access is granted.

• All modern Smart Phones and other portable User Devices have a built-in Trusted Execution Environment (TEE) which can store secrets, like private keys, where they cannot be directly read out by any application. It is the job of the Credential Service Provider to assure that the Native App handling the Patient Credential gets the private key safely to this space.

details TK

Format

Example of a JWT payload of a JWT-based verifiable Patient Credential using JWS as a proof

• The User Agent must request the Patient Credential from the CSP using an Authorization Code supplied during the Identity Proofing process. This will be signed by the private key as a JWS. The private key will be available from the did, accessed by a JWKS, or in the JSON packet.

{
  "grant_type": "authorization_code",                 // say what is happening
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",   // patient id as selected by the patient
  "client_id": "User Agent Ver 1.0",                  // identity of native app asking for the credential
  "key_protection": "RSA1024 with TPM,                // describes the type of key and where it is stored
  "code": "kjdslk:ekke:aksfd23inn98",                 // the QR code
  "iat": 1541493724,                                  // issued date
  "exp": 1573029723,                                  // expiry date
  "jti": "660!6345FSer",                              // unique request ID - should also serve a nonce to prevent replay
  "jwk": json key object                              // of the subject
}

• The patient (Subject) public key is made available so that any relying party can determine if a message is really from the patient.

{
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",   // patient
  "jti": "660!6345FSer",                              // unique identifier generated by the user to prevent spoofing
  "iss": "did:example:abfe13f712120431c276e12ecab",   // some covered entity must attest that they performed identity proofing
  "aud": :did:exmaple:wxyz89879872937498938749244",   // data controller (EHR) is audience for token
  "iat": 1541493724,                                  // issued date
  "exp": 1573029723,                                  // expiry date
  "vc": {
    "@context": [
      "https://trustregistry.us/2018/health/v1"
    ],
    "type": ["PatientCredential", "IAL2"],
    "credentialSubject": {
      "physician": {                                   // i.e. relationship to patient - could also be practice
        "type": one-of ["primary", {any specialty}, ...]
        "name": "<span lang='fr-CA'>Philip Smith</span>"
        "address": {anything that allows a Responder to reach the contact}
      }
    }
  }
}

Note that the above example uses a did as a sub, which can be resolved to include a public key of the subject. It is likewise possible for the key of any subject that can resolve as a URL on the Web to register their public encryption keys using the jwks_uri or jwks metadata parameters.

The following is an example of a JWK that can be included when the "sub" does not resolve into a public key. The following example JWK declares that the key is an Elliptic Curve [DSS] key, it is used with the P-256 Elliptic Curve, and its x and y coordinates are the base64url-encoded values shown. A key identifier is also provided for the key. The entire purpose of this key is to allow the Web Site to assure that the public key of the patient is available to the User Agent at the time of authentication. That is accomplished by signing and returning a nonce.

  sub_jwk
    {"kty":"EC",
     "crv":"P-256",
     "x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
     "y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
     "kid":"Public key used in JWS spec Appendix A.3 example"
    }

References

• Decentralized ID which can be resolved to determine, inter alia, the public key of the subject.
• JSON Web Token - JWT
• JSON Web Key - JWK