Accordingly, the federal government requires a standard mechanism for Relying Parties to obtain PIV Cardholder information (User Attributes), which are available off-card, directly from the authoritative source (Attribute Authority). The authoritative source is the PIV Card Issuing Agency, which is the agency that issued the PIV Card to the PIV Cardholder. The exchange of these User Attributes between backend systems is known as "Backend Attribute Exchange" (BAE). The architectural vision for the BAE can be found at IDManagement.gov (UPDATE: Direct link to "Backend Attribute Exchange Architecture and Interface Specification" - PDF has currently been taken down in anticipation of the upcoming BAE v2 release).

I, and members of my team, have been part of a joint DHS and DOD team that have been working on a proof of concept implementation of the BAE in order to validate the approach, gain valuable implementation experience, and to provide feedback to the relevant governance organizations within the US Federal Government. The results of our work are three-fold:

" /> Accordingly, the federal government requires a standard mechanism for Relying Parties to obtain PIV Cardholder information (User Attributes), which are available off-card, directly from the authoritative source (Attribute Authority). The authoritative source is the PIV Card Issuing Agency, which is the agency that issued the PIV Card to the PIV Cardholder. The exchange of these User Attributes between backend systems is known as "Backend Attribute Exchange" (BAE). The architectural vision for the BAE can be found at IDManagement.gov (UPDATE: Direct link to "Backend Attribute Exchange Architecture and Interface Specification" - PDF has currently been taken down in anticipation of the upcoming BAE v2 release).

I, and members of my team, have been part of a joint DHS and DOD team that have been working on a proof of concept implementation of the BAE in order to validate the approach, gain valuable implementation experience, and to provide feedback to the relevant governance organizations within the US Federal Government. The results of our work are three-fold:

" /> Accordingly, the federal government requires a standard mechanism for Relying Parties to obtain PIV Cardholder information (User Attributes), which are available off-card, directly from the authoritative source (Attribute Authority). The authoritative source is the PIV Card Issuing Agency, which is the agency that issued the PIV Card to the PIV Cardholder. The exchange of these User Attributes between backend systems is known as "Backend Attribute Exchange" (BAE). The architectural vision for the BAE can be found at IDManagement.gov (UPDATE: Direct link to "Backend Attribute Exchange Architecture and Interface Specification" - PDF has currently been taken down in anticipation of the upcoming BAE v2 release).

I, and members of my team, have been part of a joint DHS and DOD team that have been working on a proof of concept implementation of the BAE in order to validate the approach, gain valuable implementation experience, and to provide feedback to the relevant governance organizations within the US Federal Government. The results of our work are three-fold:

" />
Anil John
Making Digital Services Secure and Trustworthy

Anil John

SAML v2 Profiles for PIV Subjects and Backend Attribute Exchange

 Tweet  Share  Share  Comment  Print  Email

FIPS 201 defines a US Government-wide interoperable identification credential for controlling physical access to federal facilities and logical access to federal information systems. The FIPS 201 credential, known as the Personal Identity Verification (PIV) Card, supports PIV Cardholder authentication using information securely stored on the PIV Card. Some PIV Cardholder information is available on-card through PIV Card external physical topology (i.e., card surface) and PIV Card internal data storage (e.g. Magnetic stripe, integrated circuit chip).

Other PIV Cardholder information is available off-card. Examples of off-card information, say in the First Responder & Emergency Response domain, could be certifications that could be presented by a Doctor or EMT that could verify their claims and allow physical and/or logical access to resources.

Accordingly, the federal government requires a standard mechanism for Relying Parties to obtain PIV Cardholder information (User Attributes), which are available off-card, directly from the authoritative source (Attribute Authority). The authoritative source is the PIV Card Issuing Agency, which is the agency that issued the PIV Card to the PIV Cardholder. The exchange of these User Attributes between backend systems is known as "Backend Attribute Exchange" (BAE). The architectural vision for the BAE can be found at IDManagement.gov (UPDATE: Direct link to "Backend Attribute Exchange Architecture and Interface Specification" - PDF has currently been taken down in anticipation of the upcoming BAE v2 release).

I, and members of my team, have been part of a joint DHS and DOD team that have been working on a proof of concept implementation of the BAE in order to validate the approach, gain valuable implementation experience, and to provide feedback to the relevant governance organizations within the US Federal Government. The results of our work are three-fold:

  1. A SAML2 Profile of the BAE, with both normative and informative sections, that provide concrete implementation guidance, lessons learned as well as recommendations for folks seeking to support this profile
  2. Reference implementations stood up within the T&E environments of both DHS and DOD for interoperability testing
  3. Test suites that can be used by implementers to verify compliance with the profile

I am happy to report that the profile is currently at v1.0 (DRAFT) status, under external review, and that we are scheduled to give a briefing on the work to a sub-committee of the Federal CIO Council later this month. In addition, we have our reference implementations up and running and are putting the finishing touches on the Test Suites.

As someone who has and is participating in industry standards efforts, I am fully aware that one of the critical items for a standard to become successful is for incorporation of the standard into vendor tooling. Some of the choices that we made, beyond satisfying the needed functionality, was to make sure that it was as easy as possible to build in profile support by:

  • Not reinventing the wheel; Leverage the conventions and standards established by some of the fine work that has been done to date by the OASIS Security Services (SAML) TC on Attribute Query Profiles
  • Keep the delta's as small as possible between the BAE Profile and existing profiles such as the X.509 Attribute Sharing Profile (XASP)
  • Provide LOTS of informative guidance
  • Striking a balance between making sure that the profile was generic enough to be widely used and deployable, but provided enough information in the message flow for implementers to get full value.

The last item was something that we found to be critical and sometimes contentious to balance. But, we would not be where we are right now, had we not been informed by our actual proof-of-concept implementations. A pure paper effort would have left too many holes to patch.
We have also made an active effort to reach out to vendors, especially in the federation, entitlement management and XML security arenas, and have been gratified by their response in committing to support this profile in their tooling (In some cases, folks already have beta support baked in!). We are fully expecting to highlight and point out those folks during our out-brief later this month. If you are a vendor, want to find out what it takes to support this profile, and are interested in receiving a copy of the v1.0 DRAFT, please feel free to ping me.

This has been a pretty extensive, exciting and detailed effort and we are very grateful for the senior level support from both Organizations for this effort. Beyond that, it has been a blast working with some very smart people from both DHS and DOD to make this real.

UPDATE (6/18/2011): Please see my follow-up post on the current status of this work.


Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!

I will never share, rent, or sell your information to anyone. Cancel anytime.

This blog post first appeared on Anil John | Blog (https://blog.aniljohn.com). The opinions expressed here are my own and do not represent my employer’s view in any way.

Topic(s):
By on |

Continue The Conversation ...

I would love to know your thoughts on this blog post. Please leave a comment below!

I am a digital security coach. I help technical leaders make digital services secure and trustworthy. Learn more »

Free Updates

I will never share, rent, or sell your information to anyone