Patient Credential

From MgmtWiki
Revision as of 13:06, 7 July 2019 by Tom (talk | contribs) (Context)

Jump to: navigation, search

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 Device to allow IAL2 level of assurance authentication to access their PHI at the EHR.
  • Note that the Identifier of the issuer will be the practice, 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 (nb should this be specified to be a TEE) in a manner which provides assurance that the patient (or guardian) is the one at the device was access is granted.

details TK

Format

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

{
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",   // patient
  "jti": "http://example.edu/credentials/3732",
  "iss": "did:example:abfe13f712120431c276e12ecab",   // pcp
  "aud": :did:exmaple:wxyz89879872937498938749244",   // data controller (EHR)
  "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