High Assurance AZ Token

From IDESG Wiki
Jump to navigation Jump to search

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.

Context

  • The page is directed to the problem of providing high assurance identifier tokens that can be used for high volume use cases, such as health services.
  • Existing standards for identifier tokens are based on the assurance of the trust of the Relying Party (aka client) in the tokens produced by the Identifier provider, typically on 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

Proposed Solution

  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).
  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.
  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 a trust authority
    2. must have an authentication assurance from a trust authority
    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

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

  • 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 ID 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.
  • amr = Authentication Methods References a case sensitive string. ONC Identifier level with specifics as to how that level was achieved.
  • identity = identity proofing document.
  • uniqueID = message identifier for this issuer (or GUID) used in place of nonce - or we could just redefine nonce to our purposes.

Software Implementation Registration

  • Based on the requirement of TEFCA and HL7-FHIR there seems to be not reason to allow dynamic client registration of web sites.
  • 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:

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.
Retrieved from "https://wiki.idesg.org/index.php?title=High_Assurance_AZ_Token&oldid=14111"