Privacy Req 3: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
m (14 revisions imported: Initial Upload of old pages from IDESG Wiki)
 
(One intermediate revision by one other user not shown)
Line 15: Line 15:
For example, an attribute could be a birth date and a claim could be “old enough to buy alcohol beverage in the state of WA”.
For example, an attribute could be a birth date and a claim could be “old enough to buy alcohol beverage in the state of WA”.


See also [[Privacy Req 3 Supplemental Guidance]].
=== Supplemental Information ===
 
IDENTITY-PROVIDERS (and any other entities releasing attributes MUST provide the opportunity for attributes to be released as claims as well as detailed attributes; see also [[Privacy_Req_1|PRIVACY-1]] on granularity of requests to support data minimization by requesters, generally.
 
Attribute providers may be required by their own business processes to collect and store, although not necessarily transmit, attributes in their attribute form, in which case significant alteration or filtering may be required when that data is re-used or transmitted to others.
 
=== References and Guidance (non-normative) ===
 
* NIST SP 800-162: Attribute Based Access Control Definition and Considerations (2014), pages 26, 28, 31: http://csrc.nist.gov/publications/nistpubs/800-162/sp800_162_pre-publication.pdf
 


=== REFERENCES ===
=== REFERENCES ===

Latest revision as of 04:03, 28 June 2018

<< Back to Baseline Functional Requirements Index

PRIVACY-3. ATTRIBUTE MINIMIZATION

Entities requesting attributes MUST evaluate the need to collect specific attributes in a transaction, as opposed to claims regarding those attributes. Wherever feasible, entities MUST collect, generate, use, transmit, and store claims about USERS rather than attributes. Wherever feasible, attributes MUST be transmitted as claims, and transmitted credentials and identities MUST be bound to claims instead of actual attribute values.

SUPPLEMENTAL GUIDANCE

Where feasible, Identity Providers (and any other entities releasing attributes) should provide the opportunity for attributes to be released as claims as well as detailed attributes; see also PRIVACY-1 (DATA MINIMIZATION) on granularity of requests to support data minimization by requesters, generally.

Attribute providers may be required by their own legal or business processes to collect and store, although not necessarily transmit, attributes in their attribute form, in which case significant alteration or filtering may be required when that data is re-used or transmitted to others.

For example, an attribute could be a birth date and a claim could be “old enough to buy alcohol beverage in the state of WA”.

Supplemental Information

IDENTITY-PROVIDERS (and any other entities releasing attributes MUST provide the opportunity for attributes to be released as claims as well as detailed attributes; see also PRIVACY-1 on granularity of requests to support data minimization by requesters, generally.

Attribute providers may be required by their own business processes to collect and store, although not necessarily transmit, attributes in their attribute form, in which case significant alteration or filtering may be required when that data is re-used or transmitted to others.

References and Guidance (non-normative)


REFERENCES

Further reference materials to aid organizations interested in conforming to these Requirements can be found at the wiki page Supplemental Privacy Guidance; this has been archived at https://workspace.idesg.org/kws/public/download.php/56/Supplemental-Privacy-Guidance.docx

APPLIES TO ROLES

1 - RELYING PARTIES
2 - IDENTITY PROVIDERS
3 - Attribute Providers
4 – Intermediaries
5 - Credential Service Providers (where there is user interaction)

APPLIES TO ACTIVITIES

REGISTRATION, CREDENTIALING, AUTHENTICATION, AUTHORIZATION, INTERMEDIATION

KEYWORDS

ATTRIBUTE, IDENTIFIER, LIMITATION, MINIMIZATION, PRIVACY



Quick Links: SALS | Baseline Functional Requirements v1.0 | Glossary |