230 likes | 415 Views
Functional Model Workstream 1: Functional Element Development. Background: Excerpt from the Functional Model AHG Terms of Reference.
E N D
Functional Model Workstream 1: Functional Element Development
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.
Functional Element Development Lifecycle Reduce Use Cases to common functional elements Consolidate and disaggregate common elements (as necessary) Test Functional Elements(s) against existing and future use cases, models, and architectures Discuss relevant Functional Elements within working group Develop list and describe each functional element Select Functional Elements for inclusion
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: • Provide a basis set of functional elements that can be combined to support NSTIC pilot and IDESG Use Cases • Be implementable by various Actors within the identity ecosystem to fulfil requiredRoles • Help to delineate the responsibilities of various Actors in the identity ecosystem so that accountability for privacy/security/legal requirements is clear. • Define the functional elements that can be assessed by certification providers to provide interoperable functional components.
Functional Element Key Terms • Functional Elements- The foundational set of functions and operations that occur within the Identity Ecosystem. • Not every function or operation is a Functional Element • Items were included for their common applicability across most environments, technologies, and transaction types. • Deliverable team defined two types of functional elements: • Core Operations- High level actions that will likely be integral to most Identity Ecosystem use cases, frameworks, and architectures. • Functions- Common functions that support the execution and completion of the Core Operations.
Core Operations & Functions • Registration • Functions: Application, Data Request, Submission of Data, Attribute Verification (Identity Proofing), Eligibility Determination • Credential Provisioning • Functions: Credential Issuance/Association, Token binding, Attribute Binding • Authentication • Functions: Access Request, Credential Presentation, Identity Mapping, Credential Validation, Authentication Decision • Authorization • Functions: Access Request Response, Access Control Policy, Data Request, Submission of Data, Attribute Verification, Authorization Decision • System Management and Maintenance • Functions: Revocation, Periodic Updates, Events Based Updates, Redress
Functional Elements Applied Frameworks/Architectures
Functional Elements Applied Use Cases
Use Case: Four Party Authentication and Authorization User IDP RP Authorized Authenticated Use case assumes & Have been previously completed. AP
Daon Componentized Services– Credential service* RP PII Credential Issuer/Manager/ Verifier AP / Identity Proofer PII (biographics) AuthN data + PII *From IDESG Presentation Pilot Outbrief, Dec. 2013
Daon Componentized Services– Credential service* RP PII Authenticated Identity Proofed Credential Issuer/Manager/ Verifier AP / Identity Proofer PII (biographics) AuthN data + PII *From IDESG Presentation Pilot Outbrief, Dec. 2013
Daon Componentized Services– Identity Service Provider* RP PII Credential Issuer/Manager/ Verifier AP / Identity Proofer PII (biographics) AuthN data + PII *From IDESG Presentation Pilot Outbrief, Dec. 2013
Daon Componentized Services– Identity Provider Service* RP PII Authenticated Identity Proofed Authorized Credential Issuer/Manager/ Verifier AP / Identity Proofer PII (biographics) AuthN data + PII *From IDESG Presentation Pilot Outbrief, Dec. 2013
Further Considerations and Next Steps • Map functional element to NSTIC derived requirements • Identify gaps, redundancies, or deficiencies. • Develop recommendations for additional security requirements. • 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 • Use case and framework selection • Develop mapping approach. • Coordination with Standards Committee. • Additional steps to complete Functional Model? • Actors, Roles, Participants? • What level of detail? • Do we build the variations? Or, do we allow potential participants to map their own functional models/architectures/federations to our functional elements?