Connect with us

Hi, what are you looking for?


Identity & Access

NIST Proposes Metadata Schema for Evaluating Federated Attributes

NIST’s Attribute Metadata Schema Could Help Privacy Compliance in Multi-Domain Transactions

NIST’s Attribute Metadata Schema Could Help Privacy Compliance in Multi-Domain Transactions

Verifying identities (entities) is one problem. Managing the authorized transactions available to that verified entity is a separate problem. As industry and government increasingly move online, both the complexity and criticality of different possible cross-domain transactions increase. A single verified entity may be authorized for some transactions, but not others.

The decision to authorize or decline access to a protected resource depends upon different attributes (metadata) associated with each entity. In a federated identity and access management (IAM) process, different metadata is obtained from different authoritative providers. The National Institute of Standards and Technology (NIST) recently published ‘Attribute Metadata: a Proposed Schema for Evaluating Federated Attributes‘ (PDF) in order to provide the basis for the evolution of a standardized approach to entity attributes.

This is an internal report (NISTIR 8112) that will not be imposed upon federal agencies, but can be used by both public and private organizations. Its purpose is to allow a system (RP, the relying party) that uses federated IAM to better understand and trust different attributes; to apply more granular and effective access authorizations; and to promote the federation of attributes.

“NIST envisions that the core set of metadata proposed here can serve as a library or menu from which both commercial and federal implementers can draw common semantics, syntaxes, and values to support their specific needs,” notes the report. “This will serve as a starting point for the development of a metadata standard that can enable greater federation across markets and sectors.” 

NIST believes that it could become the foundation for a future attribute confidence scoring structure to help align attribute-based authorizations with an organization’s risk environment. Furthermore, it adds, “the ideal metadata schema could be used in both commercial and public-sector implementations, thus serving as a foundation to enable greater federation across markets and sectors.”

The NIST proposal comprises two core concepts: Attribute Schema Metadata (ASM, or the attribute’s own metadata — a definition of the attribute); and Attribute Value Metadata (AVM, or the value contained in the metadata). The ASM for an attribute includes its description, allowed values, its format, its verification frequency, and a description of the basis for processing attributes and attribute values.

The AVM defines 15 separate metadata elements around the value contained in an attribute. There are five categories: provenance (3), accuracy (2), currency (3), privacy (5) and classification (2). The provenance category includes three elements: ‘origin’, which is the name of the entity that issues the attribute; ‘provider’, which is the name of the entity providing the attribute and might be different to the origin; and ‘pedigree’, which is the relationship of the attribute value to an authoritative source, such as ‘authoritative’, ‘derived’ or ‘self-asserted’.

Advertisement. Scroll to continue reading.

The Classification (security level) metadata comprises two elements: classification and releasability. The classification metadata element could be any one of six values: unclassified, controlled unclassified, confidential, secret, top secret, and company confidential. The releasability element has seven possible values: NATO, NOFORN (no-one foreign), FVEY (only members of the Five Eye allies), public release, for business purposes, do not release, and none.

However, the remaining eight metadata elements have no defined values nor restrictions on what could be included. The five ‘privacy’ elements are particularly interesting because they can be used both to provide compliance with privacy regulations — including aspects of the EU’s General Data Protection Regulation — and demonstrate compliance to auditors. The elements are date of consent, type of consent, acceptable uses, cache time limit, and date for data deletion.

Consent is an essential part of user data collection and user data processing. Having the date consent was given, separate data processors have greater legal status in processing user data. The type of consent is equally important. Values could include ‘opt-in’, ‘opt-out’ or parental-delegated consent, among others. Since different jurisdictions can demand ‘opt-in’ consent, or allow ‘opt-out’ consent, knowing which attribute applies to the data is important for privacy compliance.

The acceptable uses element can be used to specify the use conditions for the entities that receive attributes. Again, since under GDPR and other regulations, user data can only be used for the purposes for which it was collected, it is an aid to ensuring and demonstrating compliance. The NIST document suggests, “organizations or trust frameworks might also maintain their own categories of acceptable uses based on their policies.”

The cache time limit reflects the sensitivity of different data, and can be used to specify the maximum time that data may reside in cache memory, perhaps for re-use in other transactions. “In some cases,” says NIST, “the time to live may be dictated by regulation or law, and this information needs to be relayed to RP systems so data are handled accordingly. The more sensitive an attribute value, the shorter time it will likely be enabled to live in temporary memory.”

The data deletion data attribute simply ensures that a best practice privacy principle can be applied. “Some attribute values may produce little to no privacy risk for individuals,” writes NIST. “Other values may add new privacy risks or increase existing privacy risks. A deletion date ensures that sensitive information does not remain in systems indefinitely.”

“This NISTIR,” says the report, “defines a set of optional elements of an attribute metadata schema to support cross-organization decision making, such as two executive branch agencies, in attribute assertions. It also provides the semantics and syntax required to support interoperability. NIST does not intend to make any of this schema required in federal systems and attribute-based information sharing. Rather, this schema represents a compendium of possible metadata elements to assist in risk-based decision making by an RP. This schema is focus
ed on subjects (individual users); objects and data tagging, while related, are out of scope.”

Related: Kantara Initiative Assists With EU Privacy and GDPR Issues 

Written By

Kevin Townsend is a Senior Contributor at SecurityWeek. He has been writing about high tech issues since before the birth of Microsoft. For the last 15 years he has specialized in information security; and has had many thousands of articles published in dozens of different magazines – from The Times and the Financial Times to current and long-gone computer magazines.

Click to comment


Daily Briefing Newsletter

Subscribe to the SecurityWeek Email Briefing to stay informed on the latest threats, trends, and technology, along with insightful columns from industry experts.

Learn how to utilize tools, controls, and design models needed to properly secure cloud environments.


Event: ICS Cybersecurity Conference

The leading industrial cybersecurity conference for Operations, Control Systems and IT/OT Security professionals to connect on SCADA, DCS PLC and field controller cybersecurity.


People on the Move

SaaS security company AppOmni has hired Joel Wallenstrom as its General Manager.

FTI Consulting has appointed Brett Callow as Managing Director in its Cybersecurity & Data Privacy Communications practice.

Mobile security firm Zimperium has welcomed David Natker as its VP of Global Partners and Alliances.

More People On The Move

Expert Insights