1 / 23

Functional Model Workstream 1: Functional Element Development

Functional Model Workstream 1: Functional Element Development. Background: Excerpt from the Functional Model AHG Terms of Reference.

vance
Download Presentation

Functional Model Workstream 1: Functional Element Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 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

  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: • 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.

  5. 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.

  6. 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

  7. Functional Element Matrix

  8. Functional Element Matrix (Cont.)

  9. Functional Elements Applied Frameworks/Architectures

  10. NIST 800-63 IdM Architecture

  11. 7

  12. NIST 800-63 IdM Architecture

  13. Functional Elements Applied Use Cases

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

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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?

  20. Questions?

More Related