High Assurance AZ Token

Full Title

Ensure the security of a stand-alone Token to provide high assurance of (1) Identity, (2) Authentication and (3) Federation in high volume, universally accessed web services.

Nomenclature

What’s in a name? That which we call a rose, by any other name would smell as sweet. (Shakespeare) A lot of discussion has been focused on the adjective to use the Authorization Tokens, when the problem is that these tokens provide information, not authorization.

• This token is named an Authorization token in conformance the OAuth 2.0 usage not because it actually authorizes any action. It should, however, carry all of the Authorization information needed by the Resource Server to grant access to the protected resource.
• JSON Web Signature (JWS) as defined in RFC 7515 (JWS) represents content secured with digital signatures using JSON-based data token (JWT). In this document JWS refers to token signed by an entity that can validate the token.
• Verifiable Credentials are not credentials as known in computer science before 2020, but rather digital certificates that bind an id to a set of attributes. Since this doc does not define the structures of the JWS tokens used, it is not clear, but presumed,that all of the JWS references below could be structured to be verifiable credentials as defined by W3C.
• TXAuth is an ongoing effort to create a new version to replace OAuth 2.0. As of this writing there is no agreed description of what it represents. Since it is currently focused on legacy IdPs based on social media sign-ins, it could wind up defining Troglodyte Transaction Authorization.
• The current effort (2020-05-08 Transactional Authorization and Delegation (txauth)) to create a new AZ Token is having trouble find a name for this creature as OAuth no longer seems to fit the current needs. The best ideas contain the word Intent, as in the resource owner's intent to enable access to the resource.
• IXAuth might be a stand-in name for what the token described here supports; meaning Individual Transaction for Authorization.

Context

• The page is directed to the problem of providing high assurance authorization tokens that can be used for high volume use cases, such as health services.
• Existing standards for identifier or authorization tokens are based on the assurance of the trust of the Relying Party (aka client) in the tokens produced by the Authorization Server which is often an endpoint of the Identifier provider, typically on one of the well-known social sites.
• To get high assurance identifiers, the web site that wants the higher level of assurance (whether RP or IDP) will perform additional validation of the user with protocols like FIDO Universal 2nd Factor (U2F) 1.x or Web Authentication (aka Fido 2.0).
• Pew charitable trust and MITRE have recommended the use of the Smart Phone as a source of patient identifiers in healthcare. (reference below).
• Self-issued Identifiers have been proposed by the Open ID foundation and the Decentralized Identity Foundation but have yet to penetrate any large-scale deployments.
• Existing standards are for Open ID Connect and OpenID Connect for Identity Assurance 1.0 describe the id token and the txxn for audit rtail and verified claims elements.

Example of an ID Token from the OpenID Connect spec.

 {
   "iss": "https://server.example.com",
   "sub": "24400320",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "auth_time": 1311280969,
   "acr": "urn:mace:incommon:iap:silver"
 }

Two specific fields that can serve as the basis for assurance statements.

• acr - for AAL2+

  OPTIONAL. Authentication Context Class Reference. String specifying an Authentication Context Class Reference value that identifies the Authentication Context Class that the authentication performed satisfied. The value "0" indicates the End-User authentication did not meet the requirements of ISO/IEC 29115 [ISO29115] level 1. Authentication using a long-lived browser cookie, for instance, is one example where the use of "level 0" is appropriate. Authentications with level 0 SHOULD NOT be used to authorize access to any resource of any monetary value. (This corresponds to the OpenID 2.0 PAPE [OpenID.PAPE] nist_auth_level 0.) An absolute URI or an RFC 6711 [RFC6711] registered name SHOULD be used as the acr value; registered names MUST NOT be used with a different meaning than that which is registered. Parties using this claim will need to agree upon the meanings of the values used, which may be context-specific. The acr value is a case sensitive string.

• amr - for IAL2+

  OPTIONAL. Authentication Methods References. JSON array of strings that are identifiers for authentication methods used in the authentication. For instance, values might indicate that both password and OTP authentication methods were used. The definition of particular values to be used in the amr Claim is beyond the scope of this specification. Parties using this claim will need to agree upon the meanings of the values used, which may be context-specific. The amr value is an array of case sensitive strings.

Problems

• The IdP needs to be trusted by the RP. That can be difficult to achieve when the RP has the high value resource that the user wants to access.
• The IdP is not the intended target of FIDO or Web Authentication, but raht the RP is the expected place where assurance is needed and acquired.
• The users are accustomed to using the "free" social media sites as an IDP that will be trusted by the RP.
• The liability associated with high assurance IDPs is not likely to be available on "free" social media sites.
• The assurance associated with out-of-band assurance, like web authentication has not been successful with the large number people that are expected to be using high assurance sites, like health services.
• While standards exist for cryptographic operations in software (FIPS 140 and common criteria) there is not similar controls on assuring the identity of users of software, especially on apps running on smart phones.

Problems with existing second factors

• Solutions like that from FIDO and its follow-on Web Authentication are completely independent of other actions on the link between a user and a website. So the user experience is split between two diffferent and unrelated authentication steps.

Preconditions

Before a solution to the ID Token is addressed, the following conditions must be met.

1. The web site (relying party) that is to receive any PHI has previously provided the user with hard evidence that it is a compliant HIPAA covered entity. (possible with an entity statement.)
2. The user has established a connection with the web site which includes the provisioning of a back channel from the web site to the user to permit the web site to notify the user of any event that requires notification.
3. The user has established an IAL2 proofed identifier at some other HIPAA covered entity and has proof of that fact.
4. The user has acquired and registered a device and an app to protect their AAL2 connection.

Proposed Solution

This definitions is for the token created by an individual on a portable computer that can perform its own authentication of the user. It can be viewed as a collection of verifiable credentials bound up with some metadata.

1. Create a structure of a json identifier token that is:
   1. not dependant on the underlying transport media for any integrity.
   2. able to contain parts that come from different attestation authorities (i.e. that are signed by different keys).
   3. transmittend as a MIME-type "application-jose" with an overall signature of the issuer.
2. Enable users to create their own high assurance identifier tokens. (aka self-issued, or self-sovereign identifiers.)
3. Enable federations to create their own specific measures of what factors are needed to meet their environment. They may choose whether to implement centralized, decentralized or distributed means for attesting to the assurance levels that they have specified. This is indicated by the "trust_federation" element.
4. Create an infrastructure that can be implemented by federation authorities to certify that users have the ability to meet the high assurance requirements of NIST 800-63-3,
5. ID tokens need to carry more types of assurances than the single level issuser that is the current implementations support. For example these requirements are all to be addressed by the proposed changes:
   1. must have an identity assurance from some trust authority which is recognized by the "trust_federation".
   2. must have an authentication assurance from some trust authority which is recognized by the "trust_federation".
   3. must enforce that any id-token comes with (or after) a user consent to share data
   4. must allow all users to create self-issued identifiers and can be attested to above criteria.
   5. recommend that future changes can support federation assurance level 2

AZ Token

Starting with the definition from OpenID Connect and add or limit json elements as needed for US Healthcare. This MUST be presented as a JWS signed by the issuer. The discovery of the issuer JWK must be clear. There appear to e at least two cases where an ID Token would be presented which may well require different levels of detail. (1) initial account registration where the subject needs to provide contact information. (2) subsequent data provisioning which could relying on an existing state between the EHR website and the user.

• iss = issuer unchanged for standard IdP, try to find the right way to identify a self-issued user.
• sub = Subject Identifier a case sensitive string. unchanged. A locally unique and never reassigned identifier within the Issuer for the End-User, It MUST NOT exceed 255 ASCII characters in length (review limitation wrt a did)
• jwk(s) = subject public key by inclusion or by reference, unless that information is included by reference from the sub
• aud = Audience ID(s) REQUIRED. in OIDC. Discuss, perhaps we can require the ID Token to be encrypted instead?
• exp = Expiration time on or after which the AZ Token MUST NOT be accepted for processing. UTC unix epoch time.
• iat = Time at which the JWT was issued. Its value is a JSON number. UTC unix epoch time.
• auth_time = Time when the End-User authentication occurred. UTC unix epoch time.
• acr = Authentication Context Class Reference a case sensitive string. ONC Authentication level with specifics as to how that level was achieved.
• software = identifier for software that created the acr statement. This MUST be a JWS (or a JWE).
• instance = proof of presence or similar statements MADE BY THE SOFTWARE described and signed by the above statement. This would include a date-time for freshness checking. This should be a JWS.
• amr = Authentication Methods References a case sensitive string. ONC Identifier level with specifics as to how that level was achieved.
• identity = identity proofing document. This could be a JWS.
• consent = user stipulations on the use of the data or permissions to acquire additional data. (potentially an UMA lite) This could be a JWS.
• uniqueID = message identifier for this issuer (or GUID) used in place of nonce - or we could just redefine nonce to our purposes.
• trust_framework = contains a specific string e.g. "US Healthcare Assurance Framework"

n.b. The abbreviation "JWS" above means a 3 part JWT token in jose format with a JWS signature. The claims are listed as containing a jws which is represented in the OIDC spec section 5.6.2 as "jwt": "jwt_header.jwt_body.jws". It is an open question which representation in the IAZ Token is better for the purposes of HEART, but work can continue to define the required components of the AZ Token without addressing that formating question. The current formatting is more clear and will serve us better until the question is addressed.

Software Implementation Registration

• Based on the requirement of TEFCA and HL7-FHIR there seems to be no reason to allow dynamic client registration of web sites. I.E. All sites must be statically registered before they can contain patient healthcare information (PHI),
• Depending on the actual data flows, there are good reason to expect that user device native apps will need to be strongly regulated whether they act as clients or as IdPs.

Some reference material:

• FHIR capability statement
• OpenBanking OpenID Dynamic Client Registration Specification - v1.0.0-rc2
• OpenID Connect Federation 1.0 - draft 10

References

• TEFCA the Trusted Exchange Framework and Common Agreement defines the requirements for IAL2 and AAL2 with FAL2 as needed in US Healthcare federations.
• Matching patient health care records and interoperability among Electronic Health Records (EHR) have been hard problems to address. Much of the focus has been on the health care providers rather than the patient. But now the patient has guaranteed access to their medical records, they might be able to overcome some of the resistance to sharing seen today. Patient control of the distribution of medical records would give patients both the appearance and the reality of limited access to private health care information. This example of a patient-oriented Native App for them to host on their personal Smart Phone is designed to show how patients might be the best answer to health care sharing in any case.
• The Pew Charitable Trust, Enhanced Patient Matching Is Critical to Achieving Full Promise of Digital Health Records. sponsored a collaboration with the Rand corporation and reported this conclusion about an opportunity for a Patient-empowered solution:

  In a report released in August 2018, RAND recommended a patient-empowered approach for matching involving two main components: validating patient information and a smartphone application, which would then be used together once developed.

• MetaData or capabilities from FHIR - might not survive till next versions.
• The H-ISAC Healthcare Information Sharing and Analysis Center provides a forum for coordinating, collaborating and sharing vital Physical and Cyber Threat Intelligence and best practices with each other.
• Authenticate Node section 19 of (2018-07-24) IHE IT Infrastructure Technical Framework primarily relies on mutual authentication with no specific trust anchor other than X.509 certificate chains.
• IDEF health wiki pages.