1. Functional Model Workstream 1: Functional Element Development

2. Background: Excerpt from the Functional Model AHG Terms of Reference Background: At the July 2013 plenary meeting in Boston, the Security Committee offered to steward the progression of the IDESG functional model work. Some preliminary work had previously been done under the auspices of the Standards Committee. The consensus out of the Plenary meeting in Boston was that these activities should be carried forward by the Security Committee. These Terms of Reference recite the basis for this work, and establish an Ad Hoc Group under the Security Committee to which all IDESG members are invited to participate. Purpose: The purpose of the Functional Model AHG is to define Functional Elements of identity ecosystems, which can be combined to implement identified and sustainable IDESG Use Cases. The functional model that comprises such Functional Elements can be used to: a) characterize the adoption of the NSTIC Guiding Principles by identity systems; b) explore comparability among existing identity trust frameworks; c) provide a basis for other deliverables within IDESG, such as evaluation methodologies; and d) articulate a proposed model of identity functional areas with elements that can be articulated to the broader identity community. Deliverables: A document describing the identity functional areas, including a diagram, entitled “IDESG Functional Model(s) Definition” will be produced.

3. Functional Element Development Lifecycle IDENTIFYCONSOLIDATEDESCRIBEDISCUSSSELECTTEST Reduce Use Cases to common functional elements Consolidate and disaggregate common elements (as necessary) Develop list and describe each functional element Discuss relevant Functional Elements within working group Select Functional Elements for inclusion Test Functional Elements(s) against existing and future use cases, models, and architectures

4. Functional Element Goals/Objectives Create a modular, flexible, and adaptive set of functional elements that can be effectively applied to the broadest possible collection of use cases, frameworks, and identity models. Establish functional elements in such a way that requirements can be written to them and assessed against them. Thus, the Functional Elements should: o Provide a basis set of functional elements that can be combined to support NSTIC pilot and IDESG Use Cases o Be implementable by various Actors within the identity ecosystem to fulfil required Roles o Help to delineate the responsibilities of various Actors in the identity ecosystem so that accountability for privacy/security/legal requirements is clear. o Define the functional elements that can be assessed by certification providers to provide interoperable functional components.

5. Functional Element Key Terms Functional Elements- The foundational set of functions and operations that occur within the Identity Ecosystem. o Not every function or operation is a Functional Element o Items were included for their common applicability across most environments, technologies, and transaction types. Deliverable team defined two types of functional elements: o Core Operations- High level actions that will likely be integral to most Identity Ecosystem use cases, frameworks, and architectures. o Functions- Common functions that support the execution and completion of the Core Operations.

7. Core Operations & Functions Registration o Functions: Application, Data Request, Submission of Data, Attribute Verification (Identity Proofing), Eligibility Determination Credential Provisioning o Functions: Credential Issuance/Association, Token binding, Attribute Binding Authentication o Functions: Access Request, Credential Presentation, Identity Mapping, Credential Validation, Authentication Decision Authorization o Functions: Access Request Response, Access Control Policy, Data Request, Submission of Data, Attribute Verification, Authorization Decision System Management and Maintenance o Functions: Revocation, Periodic Updates, Events Based Updates, Redress

8. Functional Element Matrix Core OperationsFunctions Description Registration Set of processes that establishes the identity of an entity to the extent necessary prior to creating the digital identity and issuing a credential. ApplicationProcess by which an entity requests initiation of registration. Data Request Process by which an entity is notified of the attributes required for determining eligibility to create the digital identity. Submission of Data Process for collecting identity data once an application has been received and data has been requested. Attribute Verification (Identity Proofing) Process of confirming or denying that claimed identity attributes are correct and meet the pre-determined requirements for accuracy, assurance, etc. to the required levels. Eligibility Determination A decision that an entity does or does not meet the pre-determined requirements of eligibility for an entitlement. Credential ProvisioningThe process to bind an established digital identity with a credential. Credential Issuance/AssociationProcess by which ownership of a credential is transferred or confirmed. Token BindingThe process of binding a physical or electronic token to a credential. Attribute BindingThe process of binding pre-determined attributes to a credential. Authentication Process of determining the validity of one or more credentials used to claim a digital identity. Access RequestProcess by which authentication is initiated by an entity. Credential Presentation Process by which a entity submits a credential for the purposes of authentication. Identity MappingProcess of linking the presented credential to a stored digital identity. Credential Validation/VerificationThe process of establishing the validity of the presented credential. Authentication Decision The decision to accept or not accept the results of the credential validation process.

9. Functional Element Matrix (Cont.) Core OperationsFunctionsDescription Authorization Authorization is the process of granting or denying specific requests for access to resources. Access Request ResponseProcess by which authorization is initiated by an entity. Access Control Policy Rules that are executed by an access control system that defines what access an entity should be granted or denied to the resource. Data Request Process by which a entity is notified of the attributes required for determining access to a specific resource; typically, these attributes for authorization have not been bound to the credential or previously available to the organization making the authorization decision. Submission of Data Process for collecting attributes required to make a determination regarding authorization. Attribute Verification The process of confirming or denying that claimed attributes are correct and meet the pre-determined requirements for authorization; typically, these attributes for authorization have not been bound to the credential or previously available to the organization making the authorization decision. Authorization Decision The decision to grant and deny access to a resource based on access controls that determine what operations are allowed to be performed on the resource System Management and Maintenance Process of creating, maintaining, deactivating and deleting digital identities, credentials, and tokens within a system. Revocation The process by which an issuing authority renders an issued credential useless for authentication to a specific digital identity. Periodic Updates Periodic scheduled background update to determine eligibility for an entitlement. Event Based Updates Background update to determine eligibility for an entitlement as a result of changes in a entity's status (e.g., change in marital status, end of subscription, etc.) Redress The process by which entities and organizations reconcile errors that occur during the operations and processes of an identity system.

10. Functional Elements Applied Frameworks/Architectures

13. NIST 800-63 IdM Architecture

14. 7

16. Functional Elements Applied Use Cases

17. Use Case: Four Party Authentication and Authorization IDP RP AP Authenticated User Authorized Use case assumes & Have been previously completed.

18. RP PII AP / Identity Proofer Credential Issuer/Manager/ Verifier AuthN data + PII PII (biographics) Daon Componentized Services– Credential service* *From IDESG Presentation Pilot Outbrief, Dec. 2013

19. RP PII AP / Identity Proofer Credential Issuer/Manager/ Verifier AuthN data + PII PII (biographics) 19 Authenticated Identity Proofed Daon Componentized Services– Credential service* *From IDESG Presentation Pilot Outbrief, Dec. 2013

20. Daon Componentized Services– Identity Service Provider* PII AP / Identity Proofer Credential Issuer/Manager/ Verifier AuthN data + PII PII (biographics) RP *From IDESG Presentation Pilot Outbrief, Dec. 2013

21. RP PII AP / Identity Proofer Credential Issuer/Manager/ Verifier AuthN data + PII PII (biographics) 21 Authorized Daon Componentized Services– Identity Provider Service* *From IDESG Presentation Pilot Outbrief, Dec. 2013 Authenticated Identity Proofed

22. Further Considerations and Next Steps Map functional element to NSTIC derived requirements o Identify gaps, redundancies, or deficiencies. o Develop recommendations for additional security requirements. o Communicate the role of functional elements and models in requirements development to the other committees of the IDESG. Map functional elements to selected use cases and frameworks o Use case and framework selection o Develop mapping approach. o Coordination with Standards Committee. Additional steps to complete Functional Model? o Actors, Roles, Participants? o What level of detail? o Do we build the variations? Or, do we allow potential participants to map their own functional models/architectures/federations to our functional elements?

23. Questions?