What is the Federal ICAM Backend Attribute Exchange (BAE) v2?

The BAE is a standards based architecture and interface specification to securely obtain attributes of subjects (e.g. PIV and PIV-I card holders, federation members with a unique identifier), from authoritative sources, to make access control decisions and/or to do provisioning.

While the original BAE v1 specification was a theoretical whiteboard exercise, the v2 specification incorporates the hands-on protocol profiling lessons learned from an initial proof-of-concept implementation, as well as a follow-on end-to-end pilot implementation of a pull based access control architecture. As such the "BAE documentation set" consists of:

• BAE v2 Overview
• Federal ICAM Governance for BAE v2
• SAML 2.0 Identifier and Protocol Profiles for BAE v2
• SAML 2.0 Metadata Profile for BAE v2
• SPML 2.0 Read-Only Profile for BAE v2

The BAE architecture and interface specification defines a mechanism for implementing a pure attribute provider and is not in the business of authenticating an end-user. Take a look at my previous entry on FICAM Support for Identity Federation Flows to see how the BAE v2 architecture fits in with the larger Authentication, Attribute Exchange and Authorization mechanisms.

To keep this focus on Attribute Provider functionality, I have started using the term BAE-AP (BAE Compliant Attribute Provider) to refer to an attribute service that implements the BAE protocol profiles.

As you can see in the documentation breakdown above, an implementation of a BAE-AP supports both the real-time, on demand, querying of attributes of a single person using SAML 2.0, and a "batch" read-only mechanism to retrieve attributes of multiple people using SPML.  The latter capability is important to satisfy many of the occasionally-connected and dynamic provisioning use cases that exist within the community.

The SAML 2.0 Profiles are fully baked while the SPML Profile is currently being developed as part of a Pilot.

There were some specific choices made in developing the BAE v2:

• The most important was to make sure that there were no dependencies between the Governance mechanisms and the implementation of the technical profiles. The Governance document illustrates how Federal ICAM will implement the BAE environment as an example. But organizations that are outside the Federal Government or Agencies and Departments who wish to implement a BAE-AP internally are free to utilize their own Governance mechanisms.
• During the development of the SAML profiles and the subsequent implementations, my team actively reached out to multiple forward-leaning vendors in this space and built a business case with each of them as to why they should support the BAE-AP profiles within their product set. We also stood up a reference implementation that is being used for interoperability and conformance testing. I am happy to note that products from Layer 7, Vordel and Intel currently have built in support for generating a BAE-AP SAML Attribute Service, and that  External Authorization Management (PDP) vendors such as BiTKOO and others have built in the capability to query a BAE-AP SAML end-point directly from their PDP.
• Last, but not least for the SAML profiles, we consciously separated the profiling of the Identifiers from the profiling of the Protocol which will allow anyone to snap-in additional identifiers as needed without impacting or changing the protocol profile. What that means in generic terms is that while the current SAML profile explicitly profiles the usage of a Subject DN from an X.509 Certificate,  FASC-N from a PIV Authentication Certificate or a UUID from a PIV-I Certificate to query a BAE-AP, you are free to extend what "key/Subject Name Identifier" you can use to query a BAE-AP. For e.g. Our reference implementation currently supports, in addition to the above, e-mail address and JID (Jabber ID) as identifiers that can be used to query for attributes. We simply advertise, within the metadata, the Subject Name Identifiers that are supported by our implementation of the BAE-AP. The expectation is that the Governance mechanism for a particular community will define the minimal set of Subject Name Identifiers everyone must support, but individual BAE-APs will be free to go beyond the minimal set given their particular use cases.

The Federal ICAM Architecture Working Group is in the process of reviewing and incorporating the comments from multiple parties, and once approved by the ICAMSC, the BAE v2 architecture and specification will become the US Federal Government's standard way to exchange attributes if using the "back-channel".

In the many conversations that took place in the sidebars, asides and hallways of the NSTIC Governance workshop this past Thursday and Friday, I found one, which I am calling the "Canvas Theory of Levels of Assurance (LOA)", to be particularly interesting. It goes something like this:

The current definition of Identity LOA, as defined by OMB and NIST [1], are too rigid/inflexible/yesterday/not today/[insert your preferred word here]. A model that is more [insert your opposing word choice here] is to treat a credential as a blank canvas. Over time, as the credential is used in transactions, the image of the credential holder becomes more and more clear on the canvas. And based on this visibility, the LOA of the credential can increase as more becomes known about the credential holder and their behavior. Alternatively it can also move down if the behavior or details about them are not in synch. As such LOA is something that should be dynamic, flexible and capable of real-time changes.

As a first step, it is important to be very clear about what LOA means. Paraphrasing OMB M-04-04 [2], [an] assurance level describes the [Relying Party's] degree of certainty that the user has presented an identifier (a credential in this context) that refers to his or her identity. In this context, assurance is defined as (1) the degree of confidence in the vetting process used to establish the identity of the individual to whom the credential was issued, and (2) the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued. What is important to note here is that the Relying Party's degree of certainty is dependent on both the process used to establish the identity of the person before the credential is issued to them, and the confidence that the credential is indeed being used by the person to whom it has been issued.

Secondly, if the end result is the subject being granted (or denied) access to information stored at a web site or the ability to invoke a service to perform some actions on their behalf, the implementation of the vision above results in the following:

• The "canvas attributes" (for lack of a better word) are not used as part of the access control decision but is instead used to "tune" the LOA level up or down
• The access control decision is then made primarily based on the new "tuned" LOA level
• The "tuned" LOA level has no connection to the vetting process and is simply dependent of the consistency and "knowledge-over-time" behavior of the credential
• Potentially frustrating experience for the subject because the relying party, since it has little or no confidence in the asserted identity's validity, may not be able to give the subject access to the information up front
• Even more critically important, the risk of identification of the subject now resides solely with the relying party

Whenever something like this is proposed, it is always worthwhile to look at who benefits from such a model. This is a model in which the IdP has no responsibility to put in place a vetting process to establish the identity of the subject, and has no liability when it comes to the potential mis-identification of the subject. Needless to say, the entities that I see this model appealing to are large consumer IdPs who do not want to disturb their existing identity proofing processes (or lack thereof) that they have with their customers.

This approach ultimately does not move the ball forward towards an identity eco-system that allows one to conduct high value and/or privacy sensitive medical, financial and government transactions.

What I would instead propose is the "Canvas Theory of Access Control":

Given that we are moving to an era where dynamic, contextual, policy driven mechanisms are needed to make real time access control decisions at the moment of need, the policy driven nature of the decisions require that the decision making capability be externalized from systems/applications/services. In this environment, we need to treat the level of access control as a blank canvas. Over time, as a credential is used in transactions, the image of the credential holder becomes more and more clear on the canvas. And based on this visibility, combined with many other factors, the level of access can increase.

LOA should just be one of the factors that go into the decision making process and is not a "tunable" component. What becomes a "tunable" component is the level of access that is granted to the subject based on information about the subject (e.g. LOA), information about the resource, environmental/contextual information, and more, that are often expressed as attributes/claims. The contextual information here could indeed be the "canvas attributes" that evolve over time and are fed into access control decision making process. This potentially allows a subject with a LOA 1 credential, combined with compensating controls such as an externalized authorization system and a risk analytics engine that takes subject/resource/ environmental/contextual/ canvas attributes as decision input, to render a decision that could allow the subject access to more and more content on a LOA 3 web site over time. But if the subject had a LOA 2 credential to start out with, they may get immediate access to all content on the web site given that a combination of LOA 2 credential plus other factors raises the confidence level in the subject.

This approach leverages the common and accepted understanding of what LOA is, enables usage of existing infrastructure technologies, and properly apportions risk across identity providers and relying parties.

[1] See FICAM Trust Framework Provider Adoption Process (TFPAP). Appendix A for a readable table of the requirements to issue a LOA 1-4 credential
[2] http://www.whitehouse.gov/sites/default/files/omb/memoranda/fy04/m04-04.pdf