NSTIC Pilot Common Considerations 5: An Identity Ecosystem Functional Model for the Modern Market
In this fifth blog in our series
highlighting some of the common questions and observations that have
emerged as the NSTIC pilots continue to move forward, we build upon the
previous blogs on terminology and trust frameworks,
to discuss an identity ecosystem functional model. As the NSTIC pilots
have developed, we note that what we initially thought was a
“terminology disconnect” was, in most cases, caused by the fact that in
today’s market, functions can be implemented by different participants
in the identity ecosystem. This was confusing the terminology regarding
actors and their functional roles.
We believe that an understanding of the implementation
characteristics of identity systems’ functions leads to a clear
understanding of their adherence to the NSTIC Guiding Principles. We are
not alone in this belief – and note that at the recent IDESG Plenary
meeting at MIT, several Committees engaged in a similar dialog.
Building on those discussions, this blogpost follows up with a
discussion of an identity ecosystem functional model that recognizes the
different roles ecosystem participants can and do play in the current
market.
This blog focuses on the functions in an identity system, and how the
implementation of such functions by various participants—such as users,
identity providers, attribute providers, attribute verifiers,
intermediaries, and relying parties—affects the overall system
characteristics.
Identity Ecosystem Functional Model
Two related Common Considerations discussed in this blog are:
- Within existing identity systems and trust frameworks there has
historically been a lack of recognition of the separated functions of
identity proofing and authentication. More recently, intermediary
technology components between identity services and relying parties have
evolved as additional identity system participants, and have similarly
not yet been formally recognized by identity trust frameworks.
- The above observation on identity proofing and authentication
functions, and intermediary technology components, is symptomatic of a
general lack of a clear functional model for identity ecosystems, which
distinguishes between the various participants and functions.
Functional Model: Recent Trends
The NSTIC pilots encompass a wide range of technologies and
capabilities, and support a number of different use cases. Across the
pilots it is becoming clear that a few functions can be used to support a
wide range of identity system use cases, but the nature of such
functions continues to evolve. As an example, identity proofing and
authentication are two key functions that in some cases are being
separated into “atomic” functions (compared to a “traditional” Credential Service Provider
model) that support identity systems. This functional atomization has
been driven largely by vendor specialization and commercial forces, but
also provides additional architectural flexibility (with some attendant
challenges) to support security, privacy, interoperability, and ease of
use. Such an architectural capability has been recognized by Trust
Framework Providers such as Kantara Initiative,
although it has not yet been incorporated into their certification
scheme. As a further example of functional atomization in the pilots, we
have observed that attribute provision and verification are used to
support identity proofing and authentication functions, as discussed in a
previous blog in this series.
In analyzing this trend of identity function atomization, we
gravitate towards an analysis of the binding mechanisms between the
functions, as has been discussed by the Kantara Initiative and Anil John.
In addition to this binding mechanism, another consequence of
functional atomization is the growing use of an intermediary technology
layer to orchestrate transactions between the various identity services
and relying parties. These topics are discussed further in the following
sections.
Identity System Functions and Participants
We can reduce the operations in an identity ecosystem to a few basic functions
Identity Proofing
Determination of the underlying confidence that a set of attributes ties a user to their identity.
Authentication
Determination of the level of confidence that the user is the rightful owner of a credential.
Binding
The linking between the identity proofing and authentication functions.
Figure 1. Basic overview of identity systems.
With reference to Figure 1 above and to the previous blog on terminology,
authentication and identity proofing together support the degree of
confidence in an individual’s identity at a time of entitlement
provision. The binding between these functions can be seen in the
broader context of identity and credential lifecycle management. For
example, NIST SP 800-63-1
discusses separated functions, and reiterates that the level of
assurance in any overall sequence of identity functions is equal to the
lowest level of assurance – the so-called “low watermark” – of any one
function or binding. In this blog we focus on how these functions, and
how the binding function by a participant (e.eg. CSP, RP, intermediary)
has several consequences, such as transaction linkability, consent
flows, credential branding, and interoperability, which influence how a
system adheres to the NSTIC Guiding Principles.
Figure 2 – Various identity architectures: a) “classic” Credential
Service Provider (CSP) model; b) Relying Party performs identity
proofing and binding; c) intermediary is used to produce “blind”
operations between the CSP and the RP; d) intermediary is used along
with relying party identity proofing; and e) intermediary performs
identity proofing and binding. In all cases, the dashed line in the
figure depicts a boundary that incorporates the participant(s)
(indicated in red font) that conduct(s) identity proofing and binding.
Figure 2 above depicts five different scenarios that are currently
being deployed. Figure 2a depicts the “traditional” credential service
provider model where identity proofing and authentication are delivered
by the same provider and so the binding is inherent in the service.
Figure 2b depicts the case where each relying party performs its own
identity proofing and also maintains the binding to the authentication
service being used. Figure 2c depicts the model in which an intermediary
is used between the CSP and RP services. This architecture allows RPs
to interface with a number of CSPs without the effort and cost of
integrating each of them, and is the basis for the U.S. government’s
upcoming Federal Cloud Credential Exchange
(FCCX). Architectures using such intermediary layers can also be used
to render the operations between participants blind – in such a case,
the CSPs and the RPs don’t know who is performing an authentication or
transaction, respectively. Figure 2d depicts the scenario where an
intermediary can be used to provide an abstraction to a number of
different authentication means, but each relying party still performs
its own identity proofing. This architecture forms the basis for the Canadian Cyber Authentication Renewal Project in conformance with the Canadian federal Privacy Act.
The ability for RP’s to perform identity proofing allows them to either
“know their customer” in accordance with legislative requirements, or
to use compensating factors to enhance the authentication process prior
to the provision of a service. Lastly, Figure 2e) depicts a system in
which an intermediary provides both authentication and identity proofing
– this scenario is applicable when an intermediary wishes to offer a
range of identity services in an “a la carte” manner and/or use
compensating controls to create “enhanced” credentials.
Note that these five scenarios are intended to be illustrative only,
and they do not represent an exhaustive set. For example, it was noted
previously that the identity proofing and authentication functions can
be implemented at a more atomic level using attribute provision and
attribute verification. It is interesting to note how the different
scenarios dictate how an identity system adheres to the NSTIC Guiding
Principles – this is particularly influenced by operation of the binding
function.
Identity Ecosystem Evaluation and the NSTIC Guiding Principles
The functional model of any given identity solution can greatly
influence its adherence to the NSTIC’s four Guiding Principles. A
successful transition to the identity ecosystem envisioned in the NSTIC
will depend on models that enable an appropriate balance of, and an
increased adherence to, all four NSTIC Guiding Principles over time.
NSTIC Guiding Principle: Privacy-Enhancing and Voluntary
From a privacy perspective, a functional model allows an evaluator to
consider how the FIPPs may be best implemented by illuminating how
personal data flows or resides among the different components. For
example, as intermediaries take on the role of orchestrating various
authentication and identity proofing functions, it is critical to
understand considerations such as user interface flow, consent flow,
redress, and the principles of anonymity, unobservability, and unlinkability.
NSTIC Guiding Principle: Secure and Resilient
From a security perspective, the functional model clearly articulates
the “target of evaluation” and delineates for each component interface
where vulnerabilities could be present. The security evaluation
methodology as part of the IDESG Security Committee work charter will
likely be based on such a functional model, and a working group in the
IDESG is currently investigating notional functional models.
In addition, recent efforts to determine the underlying confidence of
atomized functions, such as attribute verification, will help to
quantify how such functions can be appropriately combined.
NSTIC Guiding Principle: Interoperable
The various scenarios depicted in Figure 2 above illustrate how the
binding operation between identity proofing and authentication can be
implemented by different participants. This has a profound effect on
credential interoperability. For example, a fully-integrated credential
as depicted in Figure 2a offers full credential interoperability
(assuming technical compatibility), whereas the resultant credential
created in Figure 2b is interoperable in terms of reducing the number of
credentials a user holds, but the increased strength of the identity
proofing conducted by a Relying Party may not be portable to other
Relying Parties. We are seeing the scenario depicted in Figure 2b being
used in some of the pilots due to a reluctance by relying parties to
trust the identity proofing by other participants (or due to a mandate
to do their own identity proofing). Lastly, the scenario of Figure 2e
facilitates the “enhancement” of credentials by an intermediary, but
such credentials are “owned” by the intermediary that created them.
NSTIC Guiding Principle: Cost Effective and Easy to Use
As identity functions continue to be atomized, it is clear that users
and consumers will be offered more choice in light of a more
competitive environment. This should help to drive costs down. The
usability capabilities of an identity system are impacted by how a user
is re-directed across various components, in terms of user interface
continuity, continuity of branding across the ecosystem, and ease of
use. Increased modularity of any system should also increase the ability
of innovators to adhere to standards, increasing the prevalence of
solutions that are responsive to consumers’ tastes.
Functional Model and Certification
Understanding the consequences of various functional models on the
guiding principles is a key step towards an accreditation scheme that
aligns with the NSTIC. This is especially true when identity proofing
and authentication are separated, or when intermediaries are used. The
boundaries between functions and participants are critical and, as
discussed above, the binding between them is an important consideration
that relates to all four of the NSTIC Guiding principles. A clear
definition of a functional model will allow an accreditation scheme to
be developed based on ownership and data flow relating to credentials,
and that is inclusive of all aspects of security and privacy and a clear
understanding of interoperability and ease-of-use. As noted in previous
blogs, such accreditation schemes should consider all actors in the
identity ecosystem, including relying parties.
Operators of identity trust frameworks should: 1) consider all
aspects of an identity solution’s participants and functional model; 2)
base their system on mutually-recognized implementations of all
functional components, and 3) determine the optimal scenario to be used
based on their requirements for adherence to the NSTIC Guiding
Principles. Note that the inclusion of mutually-recognized
implementations of functional components is intended to anticipate
scenarios where functional components which are accredited under
different Trust Frameworks can be interoperable.
As mentioned in the introduction, the importance of functional models
has been highlighted and actively discussed by the IDESG at the fourth
and fifth Plenary meetings. Furthermore, we anticipate that the ongoing
analysis of Use Cases by the IDESG Standards Committee will reduce
functionality down to a basis set of functional components, as
contemplated here. This functional model can then be evaluated “through
the lens” of security, privacy, and usability, as well as analyzed for
interoperability.
We hope that this blog post will catalyze further discussion around
these topics within the IDESG, and that the IDESG will look to define
some recommendations to attempt to resolve these challenges. Initial
questions that we’d offer to stakeholders include:
- Should accreditation schemes include all components within an identity ecosystem, such as Relying Parties and intermediaries?
- Should accreditation schemes be based more on functions than follow the more traditional focus on actors/roles?
- Should the IDESG TFTM Committee play an active role in defining
functional models, along with Committees such as Standards, Privacy and
Security?
- How can the architectures proposed by the IDESG Use Cases be reduced
to functional models and evaluated relative to the NSTIC guiding
principles of Security, Privacy, Interoperability and Usability?
- Will better standardization of identity proofing lead to greater credential interoperability?
- Will improved credential interoperability lead to broader RP adoption and therefore a clearer business case?
- Should the IDESG contemplate creating reference implementations of
functional models that clearly address the trade-offs between security,
privacy, interoperability, and ease of use so that identity framework
operators can make appropriate decisions?
We have established a forum for further discussion regarding these and other related topics at the following location:
https://www.idecosystem.org/content/functional-model-1