Difference between revisions of "Patient Credential"

Revision as of 14:00, 10 July 2019

Full Title

The format of the document sent from a Identity Proofing Credential Service Provider to the device where the credential is stored.

Context

• 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.
• 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 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": "https://pcp.com/credentials/3732",          // unique identifier for the token used to prevent reuse
  "iss": "did:example:abfe13f712120431c276e12ecab",   // pcp issues token (credential)
  "aud": :did:exmaple:wxyz89879872937498938749244",   // data controller (EHR) is audience for token
  "iat": "1541493724",                                // issued date
  "exp": "1573029723",                                // expiry date
  "nonce": "660!6345FSer",
  "vc": {
    "@context": [
      "https://trustregistry.us/2018/health/v1"
    ],
    "type": ["PatientCredential", "IAL2"],
    "credentialSubject": {
      "physician": {
        "type": "known_to_the_practice",
        "name": "<span lang='fr-CA'>connu de la pratique</span>"
      }
    }
  }
}

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