For example, in one federation repetition of a password authentication to re-confirm the authenticator may change the risk mitigation from to In a different federation, the same risk mitigation ‘Low’ ‘Medium’. change might require a second authentication method which is different from the first one used. The full of permitted combinations and their effect on risk mitigation SHOULD be defined for the local entities. Use of Shared Definitions As with authentication method combinations, the specification of each permitted authentication method MUST be shared within a Elevation system. Note: if a fingerprint template biometric is to be used, common specification of sampling mechanics, template calculation and comparison algorithms is essential. Variance in specification within a Trust Elevation system will result in different semantic meaning when combining authentication methods. Authentication State Tracking Authentication state per Subject MAY need to be kept. The Trust Elevation system MAY need to know which authentication methods have been attempted in prior transaction attempts in order to select the a different authentication method or factor to be attempted next. Tracking state per Subject and transaction attempt may prove to be a complex undertaking unless care is taken when designing elevation policy. Location of Policy Decisions The architecture and design SHOULD be able to accommodate local, remote and distributed policy evaluation. Policy evaluation for trust elevation purposes may occur within a single system, or may occur in several different systems then combined. A mechanism for calculating the combined result of the policy evaluation MUST be designed. Consideration of Time or Quality Degradation When designing the state model for the authorization system, time-related degradation of information quality or authenticator validity SHOULD be considered. The degradation COULD be defined as nil, or according to a specified time function. Responsiveness to Threat Environment The effect of changes in the threat environment might cause changes of calculated assurance levels. Designers SHOULD determine if and how to respond to changes to the threat environment. If a system component is observed to be under active attack, the authorization system SHOULD require increased assurance levels through use of additional authentication methods. Trust Elevation Architecture Components This section is normative. The following architecture diagram shows Trust Elevation system components and other components related to Trust Elevation systems and their core functions. The dashed line boxes represent the boundary for each major component. The solid line boxes represent the functions within the major components. In other authorization model representations, the functions may have different names and may possibly appear within different major component boundaries.
For example, in one federation repetition of a password authentication to re-confirm the authenticator may change the risk mitigation from ‘Low’ to ‘Medium’. In a different federation, the same risk mitigation change might require a second authentication method which is different from the first one used. The full of permitted combinations and their effect on risk mitigation SHOULD be defined for the local entities. Use of Shared Definitions As with authentication method combinations, the specification of each permitted authentication method MUST be shared within a Elevation system. Note: if a fingerprint template biometric is to be used, common specification of sampling mechanics, template calculation and comparison algorithms is essential. Variance in specification within a Trust Elevation system will result in different semantic meaning when combining authentication methods. Authentication State Tracking Authentication state per Subject MAY need to be kept. The Trust Elevation system MAY need to know which authentication methods have been attempted in prior transaction attempts in order to select the a different authentication method or factor to be attempted next. Tracking state per Subject and transaction attempt may prove to be a complex undertaking unless care is taken when designing elevation policy. Location of Policy Decisions The architecture and design SHOULD be able to accommodate local, remote and distributed policy evaluation. Policy evaluation for trust elevation purposes may occur within a single system, or may occur in several different systems then combined. A mechanism for calculating the combined result of the policy evaluation MUST be designed. Consideration of Time or Quality Degradation When designing the state model for the authorization system, time-related degradation of information quality or authenticator validity SHOULD be considered. The degradation COULD be defined as nil, or according to a specified time function. Responsiveness to Threat Environment The effect of changes in the threat environment might cause changes of calculated assurance levels. Designers SHOULD determine if and how to respond to changes to the threat environment. If a system component is observed to be under active attack, the authorization system SHOULD require increased assurance levels through use of additional authentication methods. Trust Elevation Architecture Components This section is normative. The following architecture diagram shows Trust Elevation system components and other components related to Trust Elevation systems and their core functions. The dashed line boxes represent the boundary for each major component. The solid line boxes represent the functions within the major components. In other authorization model representations, the functions may have different names and may possibly appear within different major component boundaries.
trust-el-protocol-v1.0-cs01.docx