What Does it Mean to Embrace the NSTIC Guiding Principles?

As the IDESG Trust Framework Trustmark (TFTM) Committee continues to consider various approaches to support a trustmark scheme for the Identity Ecosystem – and other IDESG committees such as standards, security, and privacy contemplate the appropriate requirements – committee members have continued to urge that, regardless of the particular approach taken, any IDESG scheme should embrace the four NSTIC guiding principles.

While this is an approach we heartily endorse – it also begs the question:  “just what does this mean?” The guiding principles can be recited in four lines – but the text of the NSTIC that supports them covers more than 40 pages.  It is thus important when considering adherence to the guiding principles that we consider the requirements that they imply.

Focusing here on the original NSTIC document is important: as outlined in the National Strategy, the Identity Ecosystem Framework should be grounded in the NSTIC guiding principles, and IDESG schemes should “validate participants’ adherence to the requirements of the Identity Ecosystem Framework”.   This viewpoint underpinned our recent blog on “An Identity Ecosystem Functional Model for the Modern Market,” and appears to resonate with much of the recent discussion on the TFTM list serve and at the IDESG Plenary meeting in Boston.

To help accelerate the conversation, we thought that it would be helpful to go back to the NSTIC document itself to pull out Identity Ecosystem requirements which can be derived from the document.  This set of derived requirements – posted at the IDESG document repository – was extracted from the NSTIC document verbatim wherever possible, and is arranged according to the guiding principles.

The NPO derived a total of 34 requirements from the NSTIC, of which 14 related to the voluntary and privacy enhancing guiding principle, 10 to the secure and resilient principle, 8 to the interoperable principle, and 5 to the cost-effective and easy-to-use guiding principle (note that some of the derived requirements relate to more than 1 principle).

A question at the end of the functional model blog asked: “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?” One further question might be: “How can the NSTIC derived requirements be incorporated into the IDESG’s work?”

We hope the committees will consider these derived requirements to a) help to level-set discussions regarding the NSTIC Principles and derived requirements, and b) serve as a starting point for the definition of IDESG requirements.   Once the set of IDESG requirements is defined, it can be used as a yard stick for comparability of requirements across existing accreditation schemes, and/or to define test and conformity methods for the IDESG that are based on the NSTIC guiding principles.

We believe that the respective committees should review these derived requirements for appropriate coverage of the identity ecosystem.   We look forward to continued progress toward the Identity Ecosystem Framework and its associated trustmark scheme.

 

This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to What Does it Mean to Embrace the NSTIC Guiding Principles?

  1. Andrew Hughes says:

    Very valuable work here.

    The TFTM Leadership team (comprised of Chair, Vice-Chair, myself as Secretary, and NPO) reset the focus of the TFTM at the July plenary. We presented a frame of reference to structure, contain and focus TFTM work planning; to solidify the inter-committee information exchanges and interactions; and, to set the stage for the hard work of IDESG designing and defining the details of what will become the ID Ecosystem Framework and Ecosystem.

    We made a concerted push to a) return to the NSTIC Strategy document as a ‘mandate’ document which set out the future state of the ID Ecosystem and b) return to simple project organization and project management patterns.

    On item a) we have proposed to traverse the route set out mindfully: if and when the NSTIC Strategy document conflicts with market, government and industry realities, deliberation followed by decision will occur to adjust the mandate or require changes for the Ecosystem.

    On item b) simply: Requirements precede Design. Design precedes Implementation. We prepare and plan for evolution and incremental design and implementation so as to deliver the right results quickly, efficiently and at the right time.

    The work of the NPO on Requirements based on the NSTIC Strategy is a critical foundation for the work that follows.

    Andrew Hughes, TFTM Secretary

  2. Admin says:

    The IDfra identity infrastructure provides for compliance with the NSTIC Principles as follows:

    Security: The IDfra identity infrastructure combines: (i) foundational identification in a manner consistent with the requirements of The Real ID Act, augmented by incremental identity data, with measurable credibility, accumulated from transactions over time; (ii) authentication using multifactor authentication techniques, including the use of any of the emerging cost effective, less-spoofable biometric technologies; (iii) the use of metadata to create credibility coefficients for each data point; and (iv) the decentralization of personal data from massive honey pots to individual data storage devices/systems.

    Privacy: The IDfra identity infrastructure provides for: (i) the identity owner’s ability to chose whether to release real data or to allow for a metadata query; (ii) to make data query responses in real time and/or automatically based upon pre-conditioned criteria; and (iii) to allow for very limited, transaction-specific metadata query responses that could form the basis for reliable transaction decisions without the actual release of personal data. In additional, the decentralization of the data, as referenced above, would serve as a strong practical deterrent against the loss of privacy due to hacking, theft or carelessness.

    Interoperability: The IDfra identity infrastructure envisions the use of a highly flexible, open architecture database that would allow industries to evolve industry-specific data points within the broader architecture, so that a single personal database could contain financial data, medical data, credit data, criminal history data, etc., containing data points relevant to each industry.

    Usability: Because the IDfra system would allow for pre-conditioned automatic real time evaluations of what data, and/or what kind of data (i.e, real data or metadata) would be released, routine commercial transactions could be highly streamlined. For example, a person could pre-condition the release of monetary information for the purpose of paying for a type of purchase upon the acceptably-credible authentication of the vendor and the purchase details. Because the IDfra system would allow for the use of a single, personal, biometrically-encrypted, all-purpose database for virtually all transactions, users on both sides of any transaction would only need to deal with one world of data and one authentication process. In addition, each individual would have the ability to review, in a single location (and potentially correct) all of the data recorded about them, as well as all of the data queries issued to them.

    See http://www.idfra.com.

Leave a Reply

Your email address will not be published. Required fields are marked *

*