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.