Functional Requirements

Introduction

There has been some discussion about which comes first in any architecture, the model or the requirements. In actual practice they tend to grow up together. A functional model is not concerned with reasons or justification, but only the mechanics of providing the needed services. Use cases or user experiences can be created at any level within the taxonomy of requirements; however at higher levels within the taxonomy they would also be very abstract. This requirements doc is informed by the efforts of the use case and user experience committee.

Contributor

Tom Jones

Levels of Abstraction

These requirements have been structured in the form of a categorization or taxonomy to show how to partition the problem. The following diagram shows a tree structure rooted in the IDESG Identity Ecosystem, which is still being defined. It is likely that some of the terminology below will change as the ecosystem progresses. Suggestion for changes should focus on the ideas expressed, rather than specific terminology which will be adapted as the thinking of NSTIC progresses. File:Functional Layers.png

Identity Ecosystem (level 1)

This level has a single node representing the full scope of the ID ecosystem as described in NSTIC. Only very basic interoperability is possible here based on common internet protocols. No new trust mark would be appropriate systems operating with this minimal set of definitions. Identity Design Patterns have been defined at this layer (click link).

1. Safe exchanges on the internet require identities that can be used to bind attributes.
2. Identifiers need to be effectively unique, which includes randomly assigned GUIDs from a large enough name space.
3. The internet can be effectively partitioned into affinity groups with similar identity requirements in a common framework. It would be possible for a relying party or user to list the affinity groups (frameworks) that they could support to permit negotiation at this basic level.
4. The base set of roles assumed by the parties to an interchange are: (n.b. this has been expanded to include all the 800-63 roles. It could be profitably pared back. -tj)
   1. Users (subject, subscriber, principal, guardian, delegate, claimant and other roles that a user can migrate through even in a single transaction.),
   2. Registration Authority (NIST 800-63) (not defined but used - A close relationship between the RA and CSP is typical)
   3. Identity Proofer (NIST = The process by which a CSP collects, validates, and verifies information about a person.)
   4. Verifier (NIST = An entity that verifies the claimant’s identifiers and attributes)
   5. Identifier Provider (that can get combined with Attribute and Authentication Provider in (e.g.) The OpenID Provider (OP), 800-63 calls this an Identity Manager)
   6. Resource Provider (In IAM this is usually just an Attribute Provider, but can get complicated in e.g. healthcare)
   7. Authentication Provider (NIST = Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to a system’s resources.)
   8. Authenticator (is one role of one software component in industry speak, but NIST = Something the claimant possesses and controls that is used to authenticate the claimant’s identity.)
   9. Authorization or Grant Provider (NIST defines the AZ Component to be a signed token)
   10. Relying party (RP called a user client in OAuth; NIST = An entity that relies upon the subscriber’s authenticator(s) and creds).
5. The base set of real world entities includes:
   1. natural persons
   2. Groups of natural persons (either formal or ad hoc)
   3. Legal persons
   4. Credential Service Provider (CSP) (A trusted entity hosting a subset of the above roles.) (aka Credential Provider)
   5. Unspecified entities
6. Entities have the ability to create names that unique only within an affinity group or federation.

Identity Framework (level 2)

Aerospace and Defense, Finance, Health or other affinity groups have the ability to add additional requirements beyond that specified in the ID ecosystem. It is possible that NSTIC could define a default identity framework that would apply if no other framework were negotiated, or just endorse the null framework which is just that framework that added no additional constraints beyond those provided by the ID ecosystem itself.

1. A coherent description of the requirements and assumptions of the affinity group covered by the framework.

1. Details about user types can by expanded to include such things as:
   1. User attributes such as proofing used when one party has a legitimate requirement for a high level of assurance of a user's identity.
   2. User preferences such as do-not-track
   3. Additional categories of user (note that there is no reason to assume that only a single user identifier is involved in an interchange). Categories could include:
      1. Transaction (covering a single interaction)
      2. Connection (covering a collection of interactions)
      3. Machine (to guarantee integrity of the interchanges)
      4. Service (silicon based life form, like a newsfeed)
2. The list of providers recognized by the framework can vary as needed. Some types of provider might include:
   1. Identity – provides an identifier which is controlled by some entity
   2. Name space – typically part of an identity provider. If unique the name space can help to scope the identifier.
   3. Attribute – provides attributes linked to some identifier.
   4. Certificate – provides an identifier and perhaps attributes in an unalterable formal structure.
   5. Registration – provides some level of identity proofing.
3. Within the limits imposed by the framework rules any real world entity can choose to limit the information disclosed.
4. Whether the user is permitted to express their intent about how information is to be either unlinkable, or handled by other parties.

Scenario (Use Case - level 3)

The scenario level depends on the assumptions of the affinity group agreed by the user and RP.

1. Description of the interaction of a user with providers to deliver to a relying party of an identifier and attributes linked to that identifier.
2. Goals of the user in the interchange
3. Types of entities that can operate in the user role.
4. Needs of the relying party in terms of identifier and attributes.
5. Types of identities and attributes created by different real-world entities acting in the role of provider.

Functional Details (level 4)

The implementation of a real-world system will likely be limited to one or a small number of Frameworks and support a limited number of scenarios. It is only at this level that Conformance to standards can reasonably be measured.

1. How the user acquires an identifier and attributes (information sent by the user and returned by the identity and attribute providers (IAP).
2. How the needs of the relying party can be specified to other parties so that real-world entities can effectively chose to release information.
3. Level of proofing needed to satisfy the needs of the relying party or one of the IAPs.
4. How identifiers and attributes of the user can be formulated in ways that prevent linkage of the user to real world

Examples

Aerospace and Defense Industry

Defining characteristic

• Legal and regulatory access requirements for content that must remain private.
• All users are employees or have other contractual obligations to maintain the security of content.

Unique Identity Requirements

• Strong identification usually with a second factor, like smart cards.

Unique Scenarios (Use Cases)

• Employees use their employer provided credential to obtain access claims for suppliers that provide access to proprietary documents.
• Employees obtain identity credentials from their employer to access third parties, like their IRA accounts at a brokerage.

Reference

• TSCP Use Case (employee accesses IRA at broker) [[1]]

Healthcare Industry

Defining characteristic

• Legal and regulatory (HIPPA) privacy requirements for the users of the healthcare system.

Unique Identity Requirements

• Users need sufficient proof of identity at time of service to avoid billing fraud.

Unique Scenarios (Use Cases)

• Healthcare professionals are able to prove their identity and credentials to prescribe drugs or treatments for identified users.

References

• Health IT Record Location Service (Data Aggregation) Use Case [[2]]

References

Identity Design Patterns is an IDESG web page defining use cases at the ID Ecosystem layer.