1. Use Case Development Scott Shorter, Electrosoft Services January/February 2013

2. Use Case Development 2 Use Case Template Terms Template Categories Use Case Levels Concept of levels defined Draft levels proposed Use Case Examples Privacy Preserving Attribute Verification NIST IR 7817 Credential Models

3. Use Case Template - Terms 3 TermDefinition Use Case A use case is the statement of the goal the primary actor has toward the system's declared responsibilities, and the collection of possible scenarios between the system under discussion and various actors, showing how the primary actor’s goal might be delivered or might fail. Actor An actor is something with behavior. Actors can include people, organizations, software processes or services, depending on the level of the use case. Primary Actor The primary actor is one whose goal the use case is supposed to satisfy. Secondary Actor A secondary actor is an external actor against which the system under design has a goal. There can be more than one secondary actor. Scenario A scenario is a sequence of interactions that happens under certain conditions, with the intent to achieve the primary actor’s goal, and having a particular result with respect to that goal. Typically, a scenario is phrased in generic terms, using placeholders for the identity of the primary actor and the actual values passed around. Step A step is a unit of writing in a use case. Usually one sentence, describing the behavior of only one actor. Steps may be described at various levels of detail, depending on the purpose.

4. Use Case Template 4 Use Case: Name the use case here. Use an action verb name to describe the use case, not including the primary actor name, but identifying any subject actors. Verb modifiers may be used to refine the use case. Examples: authenticate to system with trusted identity, authenticate to system with pseudonymous identity, match names between systems, verify attributes with privacy protection Category: Describe what category the use case belongs to. (Categories of Use Cases slide for a list of categories and their descriptions). Contributor:Identify the person or organization that contributed the use case, including their stakeholder group. Actors: Identify actors associated with the use case. Provide the primary actor first. Actors can include people, roles, organizations, software processes or services. Actors should be listed in the Actor Template format provided in Table 2. Goals: A general description of the intended outcome of the use case from the perspective of the primary actor, including any artifacts created. This section may address risks and threats related to the use case and how they may be mitigated. Assumptions: A listing of any assumptions made about the use case including its actors, services, environment, etc. Pre-conditions – Conditions that must be met for to the use case being possible Post-conditions – Any assumed actions that take place upon completion of the use case Requirements: A listing of any requirements that must be met, these can be references to published standards and guidelines or requirements stated by the contributor. Examples : FIPS 201, ISO 27001, etc. Process Flow:A text or graphic description of the overall process flow of the use case. Success Scenario: Describe the successful execution of the use case here as a sequence of numbered steps. If multiple paths or multiple outcomes are permitted to occur, they should all be documented. Error Conditions: Describe errors that can take place, considering what can go wrong at each step of the success scenario. For each error, describe how the actors should handle the results. Citations:Provide any citations to additional information or references.

5. Use Case Template - Categories 5 CategoryDescription Identity Registration Use cases in which initial identity claims are verified (through “identity proofing” processes) and applicants become users. Authentication Use cases in which claims about identities pertaining to registered users are verified. Identity Management Use cases for creating and maintaining online identities and trust frameworks. PrivacyUse cases supporting the protection of user privacy. Trust/Assurance Use cases pertaining to the establishment of trust and assurance in Identity Ecosystem participants. InteroperabilityUse cases pertaining to confirming and testing interoperability. Consumer ChoiceUse cases that support customer choice in Identity Ecosystems. E-NotarizationUse cases supporting binding high-value online transactions.

6. Use Case Levels 6 The level of a use case denotes the overall scope of the goal that the use case represents. The steps of higher levels use cases can be considered lower level cases. High Level Low Level WHY HOW Goal of Use Case Goal of Steps Goal of Use Case Goal of Steps (diagram inspired by Writing Effective Use Cases, Alistair Cockburn)

7. Use Case Levels 7 Proposed Levels: Strategic Level – goals cover the long range goals of individuals and organizations System Level – goals cover medium range goals of individuals and organizations User Level – goals cover short term goals of individuals Component Level – goals cover immediate interactions of communicating components

8. Use Case Examples by Level 8 Strategic Level Operate Credential Service (enroll user, maintain credential status, terminate user) System Level Enroll User (identity proof, authorize suitability, issue credentials) User Level Identity Proof (identity claim, presentation of evidence, validation of evidence) Component Level Identity Claim (server send a form to user’s browser, user fills out fields, user submits form)

9. User Level Example – Verify Attributes with Privacy Protection 9 Use Case:Verify attributes with privacy protection Category:Privacy Contributor:Scott Shorter Actors: Service Provider, Attribute Provider, User Goals: The goal is for the Service Provider to obtain verified attributes about the User from the Attribute Provider without knowing the user’s identity. Assumptions: Pre-conditions – User can authenticate to Attribute Provider, Attribute Provider has a trustworthy source of attribute data, Service Provider and Attribute Provider have a trust relationship Post-conditions – Service Provider makes a business decision based on the verified attributes of the User Requirements: Could support COPPA or HIPPA Process Flow: 1.User initiates access request to Service Provider. 2.Service Provider directs User to Attribute Provider, requesting a validated attribute (e.g. Year of Birth) 3.User authenticates to Attribute Provider (assumed through preconditions) 4.Attribute Provider provides requested attribute to the Service Provider Success Scenario: Attribute provider has a trusted binding of the attribute to the User, without knowing any additional PII. Error Conditions: Describe errors that can take place, considering what can go wrong at each step of the success scenario. For each error, describe how the actors should handle the results. Citations:NSTIC Strategy

10. User Level Example –Two-Party Enterprise SSO 10 Use Case:Two-Party Enterprise SSO Category:Authentication Contributor:Scott Shorter Actors: Service Provider, Authentication Server, User Goals:The goal is for multiple service providers within an enterprise to rely on a single authentication session Assumptions: Pre-conditions – User can authenticate to Authentication Server, Post-conditions – Service Provider grants or denies access to User Requirements: Process Flow: 1.User logs into Authentication Server 2.User initiates access request to Service Provider 3.Service Provider queries Authentication Server about the status of the User 4.Service Provider received an assertion attesting to prior authentication by the Authentication Server. Success Scenario: Service Provider uses the identity grants or denies access to the User Error Conditions: User cannot log into Authentication Server Service provider cannot validate assertion Citations:NIST IR 7817, Section 2.1

11. User Level Example –Two-Party Delegation 11 Use Case:Two-Party Delegation Category:Authentication Contributor:Scott Shorter Actors: Service Provider, Third-Party Service, User Goals: The goal is for a Service Provider to issue delegation credentials that are tailored for access to data for a Third Party Service on behalf of the User. Assumptions: Pre-conditions – User can authenticate to Service Provider, Third-Party Service does not have Delegated Credentials for User yet Post-conditions – Service Provider grants or denies access to Third-Party Service Requirements: Process Flow: 1.User accesses Third-Party Service which wants data from Service Provider 2.Third-Party Service requests Delegated Credentials for User 3.Service Provider obtains User consent for delegation 4.Service Provider grants Delegated Credentials to Third-Party Service Success Scenario: Third Party Service can access limited User data from Service Provider Error Conditions: Third-Party Service forges User consent for Delegation Citations:NIST IR 7817, Section 2.1.1

12. Questions? 12