authentication step-up protocol and metadata version … · web viewandrew hughes...

Authentication Step-Up Protocol and Metadata Version 1.0

Working Draft 02

5 May 2015

Technical Committee:OASIS Electronic Identity Credential Trust Elevation Methods (Trust Elevation) TC

Chairs:Abbie Barbir ([email protected]), Bank of AmericaDon Thibeau ([email protected]), Open Identity Exchange

Editors:Andrew Hughes ([email protected]), IndividualPeter Alterman ([email protected]), SAFE-BioPharma Assn.Shaheen Abdul Jabbar ([email protected]), JPMorgan Chase Bank, N.A.Abbie Barbir ([email protected]), Bank of AmericaMary Ruddy ([email protected]), Identity Commons

Additional artifacts:This prose specification is one component of a Work Product that also includes: XML schemas: (list file names or directory name) Other parts (list titles and/or file names)

Related work:This specification replaces or supersedes: Specifications replaced by this specification (hyperlink, if available)This specification is related to: Related specifications (hyperlink, if available)

Declared XML namespaces: list namespaces declared within this specification

Abstract:Summary of the technical purpose of the document.

Status:This Working Draft (WD) has been produced by one or more TC Members; it has not yet been voted on by the TC or approved as a Committee Draft (Committee Specification Draft or a Committee Note Draft). The OASIS document Approval Process begins officially with a TC vote to approve a WD as a Committee Draft. A TC may approve a Working Draft, revise it, and re-approve it any number of times as a Committee Draft.

URI patterns:Initial publication URI:http://docs.oasis-open.org/trust-el/trust-el-protocol/v1.0/csd01/trust-el-protocol-v1.0-csd01.docPermanent “Latest version” URI:http://docs.oasis-open.org/trust-el/trust-el-protocol/v1.0/trust-el-protocol-v1.0.doc(Managed by OASIS TC Administration; please don’t modify.)

Copyright © OASIS Open 2015. All Rights Reserved.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

trust-el-protocol-v1.0-wd021 Working Draft 021 23 06 October May 20154Standards Track Draft Copyright © OASIS Open 20154. All Rights Reserved. of 24

https://www.oasis-open.org/policies-guidelines/ipr

https://www.oasis-open.org/policies-guidelines/tc-process#standApprovProcess

https://www.oasis-open.org/policies-guidelines/tc-process#committeeDraft

https://www.oasis-open.org/policies-guidelines/tc-process#dWorkingDraft

http://www.identitycommons.net/

mailto:[email protected]

http://www.bankofamerica.com/


http://www.jpmorganchase.com/


http://www.safe-biopharma.org/


http://www.openidentityexchange.org/


http://www.bankofamerica.com/


https://www.oasis-open.org/committees/trust-el/

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.


Table of Contents1 Introduction............................................................................................................................................ 4

1.1 Terminology....................................................................................................................................... 41.2 Normative References....................................................................................................................... 41.3 Non-Normative References...............................................................................................................4

2 Landscape and Context......................................................................................................................... 52.1 Goals of the Fourth Deliverable.........................................................................................................52.2 Assumptions for Trust Elevation Approaches....................................................................................6

3 E-Authentication Context & General Model...........................................................................................73.1 Identity Proofing and Verification Processes.....................................................................................73.2 Credential Capabilities and Characteristics.......................................................................................73.3 Authentication Secrets Characteristics..............................................................................................83.4 Graphical Models of Trust Elevation Events......................................................................................8

3.4.1 A: Mandatory Step-Up Policy.....................................................................................................93.4.2 B: Environmental Risk Factor Affects Effective Assurance Level.............................................103.4.3 C: Time-based Degradation of Assurance Levels....................................................................11

4 Concept of Operations.........................................................................................................................124.1 Trust Elevation Design Considerations............................................................................................12

4.1.1 Authentication System Design Considerations.........................................................................124.1.2 Risk Engine Integration Considerations...................................................................................124.1.3 Access Control Policy Considerations......................................................................................124.1.4 User Enrollment Considerations...............................................................................................134.1.5 User Provisioning Considerations............................................................................................13

5 Trust Elevation Method Repository.....................................................................................................146 Trust Elevation Sequences.................................................................................................................. 15

6.1 Original Sequence Diagram............................................................................................................157 Assertions............................................................................................................................................ 17

7.1 LoA Assessment (LA)......................................................................................................................177.2 Method Determination (MD)............................................................................................................17

8 Use cases............................................................................................................................................ 198.1 Trust-El Use Case 1........................................................................................................................ 198.2 Trust-El Use Case 2........................................................................................................................ 198.3 Trust-El Use Case 3........................................................................................................................ 20

9 # Conformance.................................................................................................................................... 21Appendix A. Acknowledgments..............................................................................................................22Appendix B. Trust Elevation as an Authorization Type...........................................................................23

B.1 Subsidiary section........................................................................................................................... 23B.1.1 Sub-subsidiary section.............................................................................................................23

Appendix C. Revision History.................................................................................................................24


1 Introduction[All text is normative unless otherwise labeled]

1.1 TerminologyThe 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.2 Normative References[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP

14, RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt.[Reference] [Full reference citation] ISO 29115NIST SP 800-63-2

1.3 Non-Normative References[Reference] [Full reference citation]

NOTE: The proper format for citation of technical work produced by an OASIS TC (whether Standards Track or Non-Standards Track) is:

[Citation Label]Work Product title (italicized). Edited by Albert Alston, Bob Ballston, and Calvin Carlson. Approval date (DD Month YYYY). OASIS Stage Identifier and Revision Number (e.g., OASIS Committee Specification Draft 01). Principal URI (version-specific URI, e.g., with stage component: somespec-v1.0-csd01.html). Latest version: (latest version URI, without stage identifiers).For example:

[OpenDoc-1.2] Open Document Format for Office Applications (OpenDocument) Version 1.2. Edited by Patrick Durusau and Michael Brauer. 19 January 2011. OASIS Committee Specification Draft 07. http://docs.oasis-open.org/office/v1.2/csd07/OpenDocument-v1.2-csd07.html. Latest version: http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2.html.


http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2.html

http://docs.oasis-open.org/office/v1.2/csd07/OpenDocument-v1.2-csd07.html

http://www.ietf.org/rfc/rfc2119.txt

2 Landscape and ContextThis 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, consists of a broad overview of current and near-future online trust elevation techniques used for (or capable of) raising 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, 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 mechanisms has been included in that deliverable. The third deliverable, Electronic Identity Credential Trust Elevation Framework Version 1.0, is an abstraction that helps to develop applications conforming to an accepted way of elevating trust on an electronic identity. As has been the pattern for this TC’s deliverables, this fourth one builds on the work of the first three and specifies protocols for elevation of trust.

2.1 Goals of the Fourth DeliverableTrust 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.The goals of this Fourth Deliverable are:

To describe a common metadata set, mechanisms and protocol elements for Trust Elevation information exchanges.

To propose simple Trust Elevation architectural patterns demonstrating the use of Trust Elevation in modern Access Control architectures.

To promote the use of Trust Elevation elements to foster standardization between among the many technologies and approaches currently in use for credential & authentication risk mitigation.


2.2 Assumptions for Trust Elevation ApproachesThere are several assumptions that help set the context for this work:

Subjects (users) that need elevation are previously known and registered with the Resource Owner’s authentication and authorization services, or are registered in a Federated service

The Resource Owner has defined a set of requirements for authentication and/or authorization control. The requirements may include any combination of static rules and dynamic risk evaluations.

In the case of Federated services, the Federation agreement defines the available identification and authentication methods, and their relationship to discrete ‘levels’ of certainty that map to risk mitigation or compensating controls.

Federation partners share a common catalogue of authentication method descriptions and mappings

Authentication methods are described sufficiently to allow creation of sets of compatible methods that cover identifiable risks or threats. For example, E.g. Ppassword authentication and hard token authentication are known to cover independent authentication factors.

The Trust Elevation techniques described in this document require that authentication method state is maintained. This is to allow the Trust Elevation engine to determine specific methods required to change trust level without relying on the Subject to keep and communicate its own authentication state.


Peter, 05/06/15,

I don’t know what this means.

3 E-Authentication Context & General Model[EDITORS NOTE: This section might seem superfluous, but I find that without this kind of context, the reader is going to have a hard time understanding the different scenarios we want Trust Elevation to work in: Static LOAs, Risk/Threat based Authentication policy; Stale/missing information for Identification; others. Yes, I realize that the Section 3 language and use of terms floats around and is inconsistent – please ignore that for now, it will be fixed over time.]This section contains a general model of e-Authenticationa process whereby a Relying Party authenticates the identity of an individual requesting access to its resources using either an online electronic identity credential or a non-credential-based procedure. Identity Credential Trust Elevation is concerned with Identification of a Subject Entity that is attempting a transaction. Once iIdentified to a sufficient degree, the transaction or resource owner is able to determine entitlements or authorization policy for the Subject. Note that Trust Elevation can be viewed as a form of Authorization, even though it directly uses Authentication methods.This e e-Authentication general model shows demonstrates how Subject assertion of identityIdentification certainty is related to identity proofing and verification processes, authentication methods and credential characteristics. A ‘static’ profile of the model is presented to represent a strict NIST SP800-63 approach to asserting levels of assurance. Also, a profile is also provided that, demonstratesing a simplistic approach to dynamically accounting for the threat environment, fraud activity and system security dynamically.In the e-Authentication Model, transactional risk is expressed as an assurance level requirement that must be satisfied by the Credential Authentication event and associated Attribute Informationusing the identity attributes that are asserted in the credential. If the identity assertion does not sufficiently mitigate the authentication risks identified by the Relying Party, assurance level requirement for the transaction is not achievedallowed. As an alternative to rejection,, Trust Elevation mMethods may be used by the Relying Party to increase the mitigation of risk of false assertion of identity in order to allow the Subject to step-up to engage in the transactionmeet the requirement.Generally speaking, tThe major factors used by Relying Parties to determineas input into identity assertion assurance level determination are: Identity Proofing processes used when the Subject is enrolledenrolling Subjects; the type, characteristics and capability of credential tokens to resist attack; the ability of tokens to generate transmit Authenticators for verification by Authentication Services,; and, the operational policies and procedures whereby the previous elements are implemented in practicetype, characteristics and processes for secret key generation, distribution and management.

3.1 Identity Proofing and Verification ProcessesThese processes are typically performed by Registration Agents on behalf of Identity Manager Services or Identity Provider ServicesCredential Service Providers. The Identity Proofing and Verification (IDPV) Processes are used to establish identity records for the Subject. IDPV consists of three main activities: collection of evidence about the Subject; matching evidence to sources for validation; and, verification that evaluation of the available facts resolves to a the single Subject who is the ApplicantSubject, unique within the scoped population. Evaluation of facts corroborates multiple sources using documented processes to establish that the Subject represents a real entity who is the Applicant, within a quantifiable range of certainty.Generally, trust frameworks and federation agreements specify the process parameters required to achieve defined levels of assurance for their member entities.

3.2 Credential Capabilities and CharacteristicsOnce an Identity Record is has been established, authentication credentials must be supplied to the Subject for future use when for engaging in online transactions.attempting resource access. These authentication credentials make re-identification of a specific Subject possible by the Relying Party.


Peter, 05/06/15,

I think this paragraph is sufficient. 3.1-3.3 just confuse the issue. Delete.

.Broadly speaking, both credentialscredential-based and non-credential-based online identity assertions are used during authentication events to create Authenticators that are supplied by the Subject to the Relying Party’s authentication service Verifier. Because the Subject that receivesd the original credential is the only entity possessing the authentication secrets needed to use the authentication method to create and submit the authenticator (for example a userID/Password pair or a private-public asymmetric cryptographic key pair, if the Verifier is able to successfully process the Authenticator using the authentication method, the Subject is considered to be have been Authenticated, e.g., iIdentified. Note that dDifferent credentials technologies and authentication methods are capable of different degrees of certainty that only the original Subject can use the credential, and that the authentication process results in a unique identification.Credential Strength is a loose function related to a credential’s resistance to forgery, tampering, interception and replay by unauthorized entities. Credential Strength is also related to the capabilities of a credential to generate similarly resistant Authenticators using the authentication method.Comparison between credential strengths is an inexact process and may depends on implementation details and attacker abilities. Federation or Trust Framework policies generally describe technology profiles and implementation practices to clarify and specify credential strengths.

3.3 Authentication Secrets CharacteristicsAuthentication sSecrets are used during authenticator generation in ways that make it possible for the Verifier to conclude that only the original recipient of Subject authentication secrets could have created the specific Authenticator.Authentication sSecrets can be of several types: shared, encrypted, symmetric cryptographic keys, asymmetric cryptographic public-private key pairs, userID/password pairs, structured text assertions, biometrics, etc. Each type has different characteristics of resistance to compromise, ease of management and ease of use.Authentication Secrets (keys) must be generated and either stored directly, or stored as a unique derived value. Key generation techniques include: human-generated secret passwords; machine-generated keys; knowledge-based or activity-based secrets; and, symmetric or asymmetric cryptographic key generation.Key storage techniques include: file system or database storage in plaintext or hashed (preferably salted per secret); hardware storage, potentially in a secure element or secure execution environment.Key distribution techniques include: use of normal communications paths (email, sms, phone); physical (written or hardware device); or via public key infrastructure.Each of the authentication secret types, generation techniques, storage techniques and distribution techniques are subject to different types of attacks and weaknesses.The relative strength of authentication secrets is a loose function of the resistance to compromise. Resistance to interception, key recovery, replay, substitution and use by unintended entities are strength factors.

3.4 Graphical Models of Trust Elevation Events One of the core assumptions of Trust Elevation is that a sSubject attempting a tTransaction is unable to meet the policy requirements for identification certainty unless an Elevation event occurs.One of three cases could cause this: a) resource owner policy that permits Subjects to gain basic access with lower-assurance credentials and requires higher-assurance credentials for specific transactions; b) the resource owner evaluates ongoing environmental risk factors and decides that the Subject is not sufficiently identified, for example based on observed unusual account activity the Subject is required to re-authenticate; and, c) the passage of time has degraded the identification certainty.NB: in the following graphs show that the assurance level of the Identity Information Attributes established via the Identity Proofing and Verification processes are separate and unlinked to the assurance level of


Peter, 05/06/15,

This is nothing more than recapitulation of the basic model graphic. Either delete or reference the graphic.

the Authentication Event (which includes Credential and Authenticator details). This approach is consistent with the NIST SP800-63 LOA calculation method, which uses a high water mark approach.

3.4.1 A: Mandatory Step-Up PolicyFor case a) the graph shows the simplest case of mandatory step-up policy for a given transaction.

Notes: The ‘Assurance Score’ is a simple numerical representation of the degree of certainty for

illustrative purposes. ‘Assurance Level 3’ has been arbitrarily defined as ‘30’ on the scale The Grey line represents the assurance level resulting from the Identity Proofing and Verification

process; established at Subject Registration time by the Registration Agent. Assume no time-based degradation

The Black line represents the assurance level resulting from the Authentication event. It takes credential, authentication secrets and authenticator generation factors into account. Assume no time-based degradation.

The Green line represents the Resource Owner defined assurance score/level required for the transaction. It is based on the Resource Owner’s risk determination methods. In this example, the Transaction Requirement is ’30’ or ‘LOA3’

The Black line lower level represents a single factor authentication, (probably password since the level is insufficient for a ‘LOA3’)

The step in the Black line shows the addition of another authentication event. The resultant Black AND Grey lines now satisfy the policy requirement for the Transaction, and

the Subject is permitted to proceed.


Peter, 05/06/15,

Important to add “generic” or “theoretical” or “model” to this graph. Also, the Levels should be noted to be policy-based determinations that come from risk assessments.

3.4.2 B: Environmental Risk Factor Affects Effective Assurance LevelFor case b) the graph shows the effect that changes in environmental threat level has on the effective assurance level. Note that depending on the specific time of evaluation, the Resource Owner Transaction policy may or may not be satisfied.

Notes: The graph uses a simple additive scoring method to subtract environmental threat score from

authentication score to illustrate the effect. The Grey, Black and Green lines have the same meaning as the previous graph Assume that the Identity Attribute level is constant, and is above the required threshold The graph shows single factor authentication, addition of a second factor and addition of a third

factor Depending on the evaluation of the degree of threat, the effective assurance level from the

authentication event increases or declines. Notice that there is a point of significant threat depicted in the 2nd authentication level: at that point

the effective assurance level dips below the Transaction requirement. A step-up would be required at that specific point in time, which would not be required at the other points in time on the 2nd level


Peter, 05/06/15,

While this discussion is interesting, it complicates the process of making the point. Also, it is flawed. Actually, the graph does not show the trust element addition events. I’m skeptical about this model, because – again - I see the “Levels” as predetermined static requirements. Delete.

3.4.3 C: Time-based Degradation of Assurance LevelsFor the purposes of Identification, the freshness of attribute information is important. Also, over time, the certainty that authentication secrets are uncompromised decreases.For case c), the graph shows a representation of the time-based degradation of identification AND authentication assurance certainty.

Notes: The downward slopes represent the time-based degradation of certainty of identity information

and also authentication assurance The upward peaks represent points in time where the information or tokens are refreshed or

reissued back to their starting values The graph shows that even though the Transaction requirement is met by adding the 2nd factor,

the exact assurance level changes over time


Peter, 05/06/15,

See above comment. For these graphs to be useful, they need to demonstrate changes to the threat environment, and they don’t do that. Delete.

4 Concept of Operations[EDITORS NOTE: I’m not sure what to do with Section 4 – I think it speaks to the considerations that a system Designer would need when constructing the Trust Elevation Methods repository and when defining specific available elevation paths. But this info might be in a different section or stated differently.]The context for the Trust Elevation techniques described in this document is a closed trust system. The participants, authentication methods, communication protocols and authorization methods must be agreed between upon among the participants (excluding Subjects). New participants or methods may be introduced to the trust system using appropriate onboarding processes.The trust system must be closed due to the lack of universally agreed-upon criteria and evaluations of an authentication method’s efficacy to counter threats, mitigate impacts or reduce negative occurrence frequency, as well as the inevitable local extrinsic concerns. For example, one trust system may consider passwords to be sufficient for identification whereas another trust system may require substantial fraud detection infrastructure to realize the same degree of sufficiency.Without universal authentication method metrics definitions, relative capabilities between trust systems are undefined. The semantics of combining authentication methods to increase risk mitigation are dependent on local evaluation of authentication method characteristics, and unless shared between trust systems, differences in local evaluation lead to differences in efficacy of risk mitigation.

4.1 Trust Elevation Design ConsiderationsTrust Elevation is applied to a Subject’s assertion of identity at Transaction time by a Relying Party in the form of entitlement authorization policy evaluationa policy-based assessment of the assertion’s risk mitigation capability against the application’s risk mitigation requirements. HoweverFor this process to operate, the Relying Party must, build into preparation must occur during authentication system design a risk assessment and a risk mitigation profile that , integration with existing environmental risk engines, controls access control policy definition, user enrollment and user provisioning.and practice.

4.1.1 Authentication System Design ConsiderationsThe implemented authentication methods must be enumerated and details captured in some form of Trust Elevation Repository.The details that must be captured are identified in Deliverable 2, comprised of threats eliminated and risks mitigated. The detailed information will enable analysts to design Trust Elevation sequences that use complementary authentication methods to strengthen risk mitigation.<<<ED: more detailed example here>>>

4.1.2 Risk Engine Integration ConsiderationsIf a trust system includes capabilities for dynamic environmental risk evaluation, the Trust Elevation scheme must be integrated. For example, if the risk evaluation engine detects an general increase in fraudulent activity, it may instruct the Trust Elevation scheme to require additional authentications and checks for all transactions.The specific technique for this integration is locally determined, perhaps by modifying risk factor weightings or modification of access control policies.

4.1.3 Access Control Policy ConsiderationsAccess Control Policy must be capable of inclusion ofincluding Trust Elevation information. There must be a mapping between policy statements and available Trust Elevation Repository information to allow for the Access Control Policy to require specific types of methods as appropriate.


Peter, 05/07/15,

This sort of comes out of nowhere. Background information such as a general increase in fraudulent activity, is simply an input to the engine. The risk evaluation engine is part of the elegant design you mapped out. This is only one of its inputs.

Peter, 05/07/15,

Rewriting the initial paragraphs with graphic should provide the needed detail.

Peter, 05/07/15,

This is good. It should be tied into the rewrite of the above section. See prior comments.

Peter, 05/07/15,

This section should describe the design methodology for TE and should include one of those graphics you prepared early on to describe the architecture. Then you go on to define each component, why it’s there and how it interacts. Not this.

Peter, 05/06/15,

Doesn’t this belong in the “Context” section?

Peter, 05/06/15,

What? What does this mean. Jargon.

For example, a policy statement might equate to: “For transactions over xxx value, where methods X, Y and Z are deemed inadequate, elevation methods A, B and C are mandatory and must be less than yyy milliseconds old.”The details of how this is configured in any particular access control system are specific to the system.The relationships between implemented authentication methods must be defined. Additionally, sets of authentication methods may be defined to enable convenient reference in policy. For example: “Level of authentication Assurance x is satisfied when methods (1 and 2) or (2, 3, 4) or (1 and 5) are successful.”

4.1.4 User Enrollment ConsiderationsEnrollment is a key phase for future execution of Trust Elevation. At enrollment time, the Resource Owner must identify, record and possibly provision authentication methods. These authentication methods could include user, device, geo-location, network location and environmental elements. Each of the authentication methods must be sufficiently recorded to allow the Resource Owner’s authorization service to select methods for the transactional Subject to use if needed for Trust Elevation.For example, if geo-location is an available authentication method, the expected geo-location parameters must be captured at enrollment such that they can be compared to the geo-location during the transaction.

4.1.5 User Provisioning Considerations<<ED: not sure about this part>>Once enrolled, a user may be provisioned with service entitlements. Use of the entitlements is subject to the Access Control Policy. It is unclear at this time whether entitlements with Access Control Policies that require authentication methods unavailable to the User should be granted. This may be a local operational decision and is dependent on the capabilities of the implemented access control system.


Peter, 05/07/15,

Out of scope – delete

Peter, 05/07/15,

Out of scope – delete.

Peter, 05/07/15,

Only another element of the engine. The policy engine. You need to completely reconceptualize this section along the lines of the rewrite of the first paragraph.

Peter, 05/07/15,

Creating a generic algorithm would be useful here.

5 Trust Elevation Method Repository[EDITORS NOTE: I would like to describe techniques and considerations that could be used to define relationships between trust elevation methods, how to express LOA’s if necessary, and a simple-ish structure for the Repository. This is where Deliverable 4 ties into the prior deliverables – using those matrices we should be able to construct a Repository.]The Trust Elevation Method Repository contains information about implemented authentication methods and their characteristics.Trust Elevation sequences are defined by associating complementary authentication methods. The Trust Elevation Method Determiner uses the Repository to identify which, if any, authentication method is required to elevate the transaction trust level.


Peter, 05/07/15,

Okay, but now think: this is one more of the boxes in your original architecture.

6 Trust Elevation Sequences[EDITORS NOTE: I think the sequence needs to be updated and maybe split to show a few different scenarios – this one might have too many actors & does not represent the simplest cases.]

6.1 Original Sequence Diagram

6.2 Trust Elevation Sequence – Story1. User invokes an application on a device to access a resource of a Relying Party (RP).2. User submits a passphrase along with device information and device network attributes to access

RP’s online resource through the device.


Andrew Hughes, 16/11/14,

BIG assumptions tied up in this step – presupposes the mode of authentication


Need to confirm that this way of describing the user-to-RP request is desirable

Peter, 05/07/15,

Agree. Reduce to the basic model for the sake of clarity.

3. RP requests associated Identity Provider (IdP) to validate the asserted identity and collects LoA. The IdP is assumed to be a member of a recognized Trust Framework or Federation that asserts the IdP operates in compliance with policies and practices.

4. RP validates all asserted attributes, if they are available, by querying one or more Attribute Provider(s) (AP). The AP(s) could be independent, part of RP or third parties. RP may involve multiple APs in a single transaction to validate various attributes.

5. RP determines if the asserted identity and attributes offer sufficient trustworthiness. For sufficient trustworthiness, present the resource. For insufficient trustworthiness, follow Trust Elevation steps. If there is no opportunity to elevate trust, then reject the request.

Trust Elevation steps:6. RP engages Trust-Elevation Method Determiner (MD) to determine the best possible type of

method be used for Trust Elevation. The MD is a repository of predetermined Trust Elevation methods for transactions involving various combinations of type of devices, RPs, IdPs, APs, LoAs and context. The MD could belong to an IdP, be independent, be part of RP or belong to some other third party.

7. RP, based on feedback from MD, requests valid biometric factors through the device. The user submits biometric factors and goes through steps 3 to 5 above.



Why is the RP requesting a specific mode of authentication? Isn’t this the IDP/CSP’s job?Is this sequence dependent on which authentication method is first encountered?


How does the MD know about ‘best’ ?


This seems to be a ‘redirect to login’ mode – which doesn’t actually match step 2 which makes assumptions about the authentication protocol being used – this should be restated as a ‘classic’ Redirect for better understanding

7 Assertions[EDITORS NOTE: Depending on where we get to with the Methods Repository, these assertions may change. There are structures in SAML and OAuth (acr and amr) that are potential candidates for expression of Trust Elevation authentication stuff. Have to explore/try it out.]

7.1 LoA Assessment (LA)LA Request

<trustel:AssessLoaRequest><trustel:AssertedID>...</trustel:AssertedID> //could be SAML token<trustel:AssertedAttribute><trustel:Attribute>...</trustel:Attribute> //Attribute<trustel:AttributeProvider>...</trustel:AttributeProvider> //AP OU<trustel:AssertedAttribute><trustel:AssertedAttribute><trustel:Attribute>...</trustel:Attribute> //Attribute<trustel:AttributeProvider>...</trustel:AttributeProvider> //AP OU<trustel:AssertedAttribute><trustel:Loa>....</trustel:Loa> //current LoA Strength in numerical value<trustel:LoaAssessor>...</trustel:LoaAssessor> //LoA OU<trustel:AuthnContext><trustel:AuthnDeviceSig>..</trustel:AuthnDeviceSig> //Device Fingerprint<trustel:AuthnLocation>...</trustel:AuthnLocation> //Device location<trustel:AuthnIP>...</trustel:AuthnIP> //IP of the device<trustel:AuthnTime>...</trustel:AuthnTime> //time of request</trustel:AuthnContext></trustel:AssessLoaRequest>

LA Response<trustel:AssessLoaResponse><trustel:AssertedID>...</trustel:AssertedID> //could be SAML token<trustel:LoaStrength>...</trustel:LoaStrength> //could be numerical value<trustel:LoaAssessor>...</trustel:LoaAssessor> //LoA OU<trustel:LoaAssessorSig>...</trustel:LoaAssessorSig> //LoA OU Signature</trustel:AssessLoaResponse>

7.2 Method Determination (MD)MD Request

<trustel:MethodTypeRequest><trustel:AssertedID>...</trustel:AssertedID> //could be SAML token<trustel:AssertedAttribute><trustel:Attribute>...</trustel:Attribute> //Attribute<trustel:AttributeProvider>...</trustel:AttributeProvider> //AP OU<trustel:AssertedAttribute><trustel:AssertedAttribute><trustel:Attribute>...</trustel:Attribute> //Attribute<trustel:AttributeProvider>...</trustel:AttributeProvider> //AP OU<trustel:AssertedAttribute><trustel:Loa>....</trustel:Loa> //current LoA Strength in numerical value<trustel:LoaAssessor>...</trustel:LoaAssessor> //LoA OU<trustel:AuthnContext><trustel:AuthnDeviceSig>..</trustel:AuthnDeviceSig> //Device Fingerprint


<trustel:AuthnLocation>...</trustel:AuthnLocation> //Device location<trustel:AuthnIP>...</trustel:AuthnIP> //IP of the device<trustel:AuthnTime>...</trustel:AuthnTime> //time of request</trustel:AuthnContext></trustel:MethodTypeRequest>

MD Response<trustel:MethodTypeResponse><trustel:AssertedID>...</trustel:AssertedID> //could be SAML token<trustel:Method>...</trustel:Method> //could be "|" delemited array of methods<trustel:MethodDeterminer>...</trustel:MethodDeterminer> //MD OU<trustel:MethodDeterminerSig>...</trustel:MethodDeterminerSig> //MD OU Signature</trustel:MethodTypeResponse>


8 Use cases8.1 Trust-El Use Case 1

8.2 Trust-El Use Case 2


8.3 Trust-El Use Case 3


9 # ConformanceThe last numbered section in the specification must be the Conformance section. Conformance Statements/Clauses go here. [Remove # marker]


Appendix A. AcknowledgmentsThe following individuals have participated in the creation of this specification and are gratefully acknowledged:Participants:!!br0ken!!

[Participant Name, Affiliation | Individual Member][Participant Name, Affiliation | Individual Member]


Appendix B. Trust Elevation as an Authorization TypeTo foster greater understanding of the Trust Elevation mechanism and concepts, this section describes how Trust Elevation can be represented as a form of Authorization.

B.1 Subsidiary sectiontext

B.1.1 Sub-subsidiary sectiontext


Appendix C. Revision History

Revision Date Editor Changes Made

[Rev number] [Rev Date] [Modified By] [Summary of Changes]


authentication step-up protocol and metadata version … · web viewandrew hughes...

Documents