Authentication Step-Up Protocol and Metadata Version 1.0

Authentication Step-Up Protocol and Metadata Version 1.0

Committee Specification Draft 02 /
Public Review Draft 02

22 October 2016

Specification URIs

This version:

(Authoritative)

Previous version:

(Authoritative)

Latest version:

(Authoritative)

Technical Committee:

OASIS Electronic Identity Credential Trust Elevation Methods (Trust Elevation) TC

Chairs:

Abbie Barbir (), Aetna

Don Thibeau (), Open Identity Exchange

Editors:

Andrew Hughes (), Individual

Peter Alterman (), SAFE-BioPharma Assn.

Shaheen Abdul Jabbar (), JPMorgan Chase Bank, N.A.

Abbie Barbir (), Aetna

Mary Ruddy (), Identity Commons

Related work:

This specification is related to:

Analysis of Methods of Trust Elevation Version 1.0.Work in progress.
Survey of Methods of Trust Elevation Version 1.0. Work in progress.
Electronic Identity Credential Trust Elevation Framework Version 1.0. Edited by Peter Alterman, Shaheen Abdul Jabbar, Abbie Barbir, Mary Ruddy, and Steve Olshansky. 22 May 2014. OASIS Committee Specification 01. Latest version:

Abstract:

Electronic Identity Credential Trust Elevation Methods are used to increase assurance in entity identification using authentication events and related entity information for the purpose of risk mitigation when making access control policy decisions.

The goals of this Fourth Deliverable are:

To propose simple Trust Elevation architectural patterns demonstrating the use of Trust Elevation in modern Access Control architectures.
To describe a common metadata set, mechanisms and protocol elements for Trust Elevation information exchanges.
To promote the use of Trust Elevation elements to facilitate standardization among the many technologies and approaches currently in use for credential & authentication risk mitigation.

Status:

This document was last revised or approved by theOASIS Electronic Identity Credential Trust Elevation Methods (Trust Elevation) TCon the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document.Any other numbered Versions and other technical work produced by the Technical Committee (TC) arelisted at

TC members should send comments on this specification to the TC’s email list. Others should send comments to the TC’spublic comment list, after subscribing to it by following the instructions at the “Send A Comment” button on the TC’s web page at

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC’s web page (

Citation format:

When referencing this specification the following citation format should be used:

[Trust-El-Protocol-v1.0]

Authentication Step-Up Protocol and Metadata Version 1.0. Edited byAndrew Hughes, Peter Alterman, Shaheen Abdul Jabbar, Abbie Barbir, and Mary Ruddy. 22 October 2016. OASIS Committee Specification Draft 02 / Public Review Draft 02. Latest version:

Notices

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS"is a trademarkof OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see for above guidance.

Table of Contents

1Introduction

1.1 Terminology

1.2 Normative References

1.3 Non-Normative References

2Landscape and Context

2.1 Goals of the Fourth Deliverable

3Conceptual Models

3.1 Trust Elevation Core Model

3.2 Trust Elevation Concepts

3.3 Use of Authorization Architectures and Models

3.3.1 Attribute Based Access Control Model

3.3.2 User Managed Access Authorization Model

3.3.3 XACML Authorization Model

3.3.4 SAML Backend Attribute Exchange (BAE) Model

4Architecture & Design

4.1 Trust Elevation System Context

4.2 Assumptions for Trust Elevation Systems

4.3 Architecture & Design Factors

4.3.1 Definition of ‘Elevation’ or ‘Step-Up’

4.3.2 Use of Shared Definitions

4.3.3 Authentication State Tracking

4.3.4 Location of Policy Decisions

4.3.5 Consideration of Time or Quality Degradation

4.3.6 Responsiveness to Threat Environment

4.4 Trust Elevation Architecture Components

4.4.1 Trust Elevation Services Component

4.4.1.1 Trust Elevation Method Determiner

4.4.1.2 Trust Elevation Method Repository

4.5 Other Architecture Components

4.5.1 Authorization Services Component

4.5.2 Risk-Based Engine Component

5Implementation Considerations

5.1 Orchestration

5.2 Enumeration of Authentication Methods

5.2.1 Subject Component

5.2.2 Effect of Device Capability Changes

5.3 User Enrolment

6Trust Elevation Sequence (Example)

6.1 Use Case: Online banking transactions

6.1.1 Description

6.1.2 Pre-conditions

6.1.2.1 Transaction Risk Levels

6.1.2.2 Policy Table*

6.1.2.3 Methods Table

6.1.3 Process Flows

6.1.3.1 Transaction 1: Check Account Balance

6.1.3.2 Transaction 1: Sequence

6.1.3.3 Transaction 2: Transfer Funds Out

6.1.3.4 Transaction 2: Sequence

7Metadata and Assertions

7.1 Component-Component Communications

7.2 PDP to TE Method Determiner Request

7.3 TE Method Determiner to PDP Response

8Conformance

Appendix A.Acknowledgments

Appendix B.State Models for Assurance Level Evaluation

8.1 Evaluation of Assurance Requirements at Transaction Time

8.1.1 Up-Front Policy Evaluation of Proofing and Authenticator Levels

8.1.2 Time-Based Degradation of Authenticator Assurance Levels

8.1.3 Threat Environment Effects on Effective Authenticator Level

Appendix C.Revision History

trust-el-protocol-v1.0-csprd0222 October 2016

1Introduction

All text is normative except for labeled examples and notes.

1.1Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in[RFC2119].

1.2Normative References

[trust-el-analysis-v1.0]

Analysis of Methods of Trust Elevation Version 1.0.Edited by Peter Alterman, Shaheen Abdul Jaabar, Jaap Kuipers, Thomas Hardjono, and Mary Ruddy.Work in progress.

[trust-el-survey-v1.0]

Survey of Methods of Trust Elevation Version 1.0. Edited by Peter Alterman, Shaheen Abdul Jabbar, Jaap Kuipers, Thomas Hardjono and Mary Ruddy. Work in progress.

[trust-el-framework-v1.0]

Electronic Identity Credential Trust Elevation Framework Version 1.0. Edited by Peter Alterman, Shaheen Abdul Jabbar, Abbie Barbir, Mary Ruddy, and Steve Olshansky. 22 May 2014. OASIS Committee Specification 01. Latest version:

[NIST800-63-2] NIST Special Publication 800-63-2,Electronic Authentication Guideline, August 2013.

[NIST800-162]NIST Special Publication 800-162,Guide to Attribute Based Access Control (ABAC) Definition and Considerations, January 2014.

[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <

[UMA]Hardjono, T., Maler, E., Machulak, M., Catalano, D. User-Managed Access (UMA) Profile of OAuth 2.0, April 2015.

[X.1252]Recommendation ITU-T X.1252 (2010). Baseline identity management terms and definitions.

[XACML3]OASIS Standard, eXtensible Access Control Markup Language (XACML) Version 3.0, 22 January 2013.

1.3Non-Normative References

[ISO ISMS]ISO/IEC 27000:2014 Information technology -- Security techniques -- Information security management systems -- Overview and vocabulary, 2014.

[NIST800-37-1]NIST Special Publication 800-37 r1, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach, June 2014.

[IDMgmt]Backend Attribute Exchange (BAE) v2.0 Overview

[OAuth2]Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <

[OMB M-04-04]Joshua B. Bolten, U.S. Government Office of Management and Budget,
E- Authentication Guidance for Federal Agencies, December 2003.

[OpenID.Core]Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” August 2015.

[SAML2]OASIS Standard, Security Assertion Markup Language (SAML) Version 2.0, 2 December 2009.

[SAMLAC]OASIS Standard, Authentication Context for the OASIS Security Assertion Markup Language (SAML) Version 2.0, 15 March 2005.

[X.1254]Recommendation ITU-T X.1254 (09/2012). ITU Telecommunication Standardization Sector (ITU-T) Entity authentication assurance framework.

[X.1255]Recommendation ITU-T X.1255 (09/2013). Framework for discovery of identity management information.

2Landscape and Context

This document, the fourth deliverable of the OASIS Trust Elevation Technical Committee, builds on the work of the first three. To recap: the first deliverable, Survey of Methods of Trust Elevation Version 1.0[trust-el-survey-v1.0], consists of a broad overview of current and near-future online trust elevation techniques used for (or capable of) elevating a relying party’s assurance that the user requesting access to its resources is actually the person he or she claims to be. The second deliverable, Analysis of Methods of Trust Elevation Version 1.0[trust-el-analysis-v1.0], evaluated how each of the identified trust elevation mechanisms operated and what threats they mitigated that added to the relying party’s confidence in the identity asserted. A discussion of the methodology used to analyze the identified mechanisms has been included in that deliverable. The third deliverable, Electronic Identity Credential Trust Elevation Framework Version 1.0[trust-el-framework-v1.0], is an abstraction intended to help to develop applications conforming to an accepted way of elevating trust of a digital identity.

As has been the pattern for this TC’s deliverables, this fourth deliverable builds on the work of the first three and specifies design considerations, implementation considerations and metadata for the elevation of trust through increased identification.

2.1Goals of the Fourth Deliverable

Trust Elevation Methods are used to increase assurance in entity identification using authentication events and related entity information for the purpose of risk mitigation when making access control policy decisions.

The goals of this Fourth Deliverable are:

To propose simple Trust Elevation architectural patterns demonstrating the use of Trust Elevation in modern Access Control architectures.
To describe a common metadata set, mechanisms and protocol elements for Trust Elevation information exchanges.
To promote the use of Trust Elevation elements to facilitate standardization among the many technologies and approaches currently in use for credential & authentication risk mitigation.

3Conceptual Models

This section is non-normative.

3.1Trust Elevation Core Model

As described in Electronic Identity Credential Trust Elevation Framework Version 1.0, the following depicts the core model for Trust Elevation.

3.2Trust Elevation Concepts

While the flow diagram above is easy to understand, implicit in the core model are several key components and processes, as shown in Section 4.2. The first of these is a component which functions as a policy engine capable of consuming the asserted user data and making a determination as to whether that data satisfies the resource’s policy for authentication risk mitigation. The resource manager must have previously performed a risk assessment and adopted a risk mitigation strategy([NIST RMF] and [ISO ISMS] are examples of methodologies for these antecedent steps).

The second key component is again an antecedent service generated during the risk assessment and mitigation process. It is composed of a capability to recognize which, if any, risks have been adequately mitigated by the initial transaction, which risks remain to be mitigated and preferred methods for satisfying the remaining needs.

The third key component is a component for evaluating the success of the trust elevation transaction. This could be an iteration of the first component, but it has been broken out in the above graphic to clarify the decision flow.

While these components are necessary to implement trust elevation of a presented online identity, they require the resource manager to have engaged in prior planning and assessments in order to generate the information necessary to direct the behavior of the components. In addition to implementing recognized, standards-based risk assessments, the prior work of this Technical Committee provide the necessary guidance for populating the decision-making components of the core model as well as most comparable models.

Trust Elevation methods are used to increase confidence in entity identification using authentication events and related entity information for the purpose of increased risk mitigation when making access control policy decisions.

Levels of Assurance models are structured such that increased risk mitigation results in increased credential or identity assurance level trust. These models require determination of a given transaction’s identity and authentication risk, expressed in terms of level of assurance requirements. Policies are designed such that credential or identity assurance level must meet or exceed the transaction’s level of assurance requirement.

As described in Electronic Identity Credential Trust Elevation Framework Version 1.0, entity identification confidence may be increased by: mitigating an authentication threat not addressed by the original authentication exchange; improved mitigation of the original authentication threat, or examination of contextual or environmental factors to corroborate the existing identification.

The definition of the composition of a particular assurance level scheme, and related policy evaluation criteria, is the responsibility of the parties involved in the transactions. The scheme should be tailored to the risk tolerance and requirements of the relying party. In other words, it is up to the resource manager to determine when sufficient mitigations of risk have occurred.

3.3Use of Authorization Architectures and Models

Another way to look at Trust Elevation is as a species of transaction or access control authorization. From this perspective, evaluation of the current state versus policy requirements results in decisions to ‘Permit’, ‘Deny’, or ‘Require Elevation’.

The Trust Elevation core model is compatible with other published authorization models, such as: Attribute Based Access Control (ABAC) [NIST800-162], User Managed Access ([UMA]), [OAuth2], [XACML3], and SAML Backend Attribute Exchange.

3.3.1Attribute Based Access Control Model

This section illustrates how Trust Elevation would fit into an Attribute Based Access Control model.

[NIST SP800-162] describes the elements of an Attribute Based Access Control Model.

As shown in the figure below, the primary components of Authorization Services are the Policy Enforcement Point (PEP) which intercepts resource requests; and, the Policy Decision Point (PDP) which checks supplied attributes versus access control policy. The PDP can obtain additional attributes from environmental conditions, Policy Information Point (PIP) and other sources. Based on the policy evaluation, the PDP instructs the PEP to permit or deny access to the resource.

In the diagram below, when the Authorization Services determine that Trust Elevation is required, the Trust Elevation Services take information from “Authentication Services” and “Risk-Based Engine” to evaluate what Trust Elevation Method should be used to achieve the desired result.

3.3.2User Managed Access Authorization Model

The User-Managed Access protocol (UMA) defines a mechanism for a policy enforcement point – known as the resource server – to delegate authorization of a requesting party to a policy decision point – known as the authorization server – using elements of the OAuth 2.0 authorization framework.

To gain access to a protected resource, an UMA client (web or mobile application operating on behalf of a requesting party) must present a valid access token, called a requesting party token (RPT), to the resource server. The RPT must be valid and associated with sufficient authorization data, issued through a trust elevation process, before the resource server can grant access.

The authorization server, guided by policies set by the owner of the protected resource, elevates trust by testing whether the requesting party meets the policies. As part of this process, it could demand that the requesting party (or the client on their behalf) provide claims, such as identity information or even promises to adhere to constraints set by the resource owner, such as an embargo on information release until a certain date.

One policy the authorization server can consider is what mechanism was used to authenticate the person. UMA doesn’t require use of any particular authentication protocol, but works especially well with OpenID Connect.