BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

1.2.1 Creating Technical Interoperability Profiles of This Guideline 249

NIST PIV and digital identity SP 800-217 (Draft)
All changes in this version
first version loaded 1 Introduction 211 part of 1.2

Title

Creating Technical Interoperability Profiles of This Guideline 249

Control

250 251 252 253 254 255

256 257 258 259 260

261 262 263 264 265 266

267 268 269 270 271 272

273 274 275 276 277 278

279 280 281 282 283

284 285 The guidelines in this document alone are not intended to provide full technical interoperability profiles. In addition to this document and its prerequisites ( [FIPS201] , [SP800-63C] , and [SP800-157] ), PIV federation deployments will need technical interoperability profiles that are suitable for the federation protocol being used. The details of such profiles are out of scope for this document, but all technical interoperability profiles will need to consider the following points.

Target Protocols: Different federation protocols can be used to fulfill the requirements in the guidelines of this document in different and often incompatible ways. A technical interoperability profile ought to target each specific federation protocol in order to allow for more stringent definitions.

Attribute Naming: Each attribute that occurs within an assertion or the response from an identity API will need to have a name (or other means of address) defined. To ease interoperability, this name ought to reflect the value being asserted, such as exp for an expiration timestamp or sub for the subject identifier. Each entity of the federation has to use the same naming convention for interoperable attributes.

Attribute Contents: Each attribute that occurs within an assertion or the response from an identity API will need to have its type, format, structure, or other content restrictions sufficiently defined such that the value can be unambiguously understood between sender and receiver. For example, a timestamp format could be encoded as an integer number of seconds since the UNIX Epoch GMT or in an ISO 8601 date string.

Conformance Criteria: As PIV federation systems are likely to be built on top of existing federation software, a technical interoperability profile will need to define what additional options are allowed or forbidden by conformant implementations. For example, a profile of OpenID Connect could restrict use of the Implicit Grant Type for requests and responses.

Home Agency IdP Records: Agencies need to have a means of publishing verifiable home agency IdP records in a known location that is easily reached and machine-readable by other parties. This could take the form of a centralized directory service with a query function or a lookup pattern based on domain names.

All technical interoperability profiles also need to consider existing profiles and industry best practices for the target technology in question.