NIST Proposes Metadata Schema for Evaluating Federated Attributes

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’.

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 focused on subjects (individual users); objects and data tagging, while related, are out of scope.”

Related: Kantara Initiative Assists With EU Privacy and GDPR Issues 

http://feedproxy.google.com/~r/Securityweek/~3/BWVWwq93DZQ/nist-proposes-metadata-schema-evaluating-federated-attributes