Difference between revisions of "Patient Credential"

From MgmtWiki
Jump to: navigation, search
Line 23: Line 23:
   "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",  // patient id as selected by the patient
   "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
   "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
   "code": "kjdslk:ekke:aksfd23inn98",                // the QR code
   "iat": 1541493724,                                  // issued date
   "iat": 1541493724,                                  // issued date

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.


  • 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.

details TK


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": [
    "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.

     "kid":"Public key used in JWS spec Appendix A.3 example"