Difference between revisions of "Attribute"
From MgmtWiki
m (→Context) |
(→Attribute Based Access Encryption) |
||
| (22 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
| − | Any datum (piece of data) about a digital entity. | + | Any datum (piece of data) about a digital entity. Where a digital entity is a named object. |
| + | |||
| + | Definitions from NIST IR 8480 (Initial Public Draft) Attribute Validation Services (AVS) for Identity Management: Architecture, Security, Privacy, and Operational Considerations<ref>Ryan Galluzo +3, 'NIST IR 8480 (Initial Public Draft) | ||
| + | Attribute Validation Services for Identity Management: Architecture, Security, Privacy, and Operational Considerations 2024-10-07) https://csrc.nist.gov/pubs/ir/8480/ipd</ref><blockquote>At its core, an attribute is a "quality or characteristic ascribed to someone or something" [NIST SP 800-63-3], such as a person's date of birth, residential address, or Social Security Number. Attributes are essential in confirming an individual’s identity or their eligibility to access certain services or information. An AVS validates these attributes against reliable data sources to confirm their accuracy. This validation process plays a pivotal role in secure identity proofing, access control, and fraud prevention.</blockquote> | ||
==Context== | ==Context== | ||
| − | *At one time [[Attribute]]s were | + | * In [[Identity Management]] an [[Attribute]] is also known as (aka) a [[Claim]]. |
| + | *At one time [[Attribute]]s were considered to be a useful way to perform [[Authentication]] of a [[User]].<ref>NIST Special Publication 800-162 ''Guide to Attribute Based Access Control (ABAC) Definition and Consideration'' https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.sp.800-162.pdf</ref> | ||
**Now it is realized that this method releases much [[User Private Information]] and offers low [[Assurance]]. | **Now it is realized that this method releases much [[User Private Information]] and offers low [[Assurance]]. | ||
| − | **Even the ISO definition of [[Personally Identifiable Information]] (or PII) seems to imply the existence of [[Attribute]]s that are not personally identifying. | + | **Even the ISO definition of [[Personally Identifiable Information]] (or PII) seems to imply the existence of [[Attribute]]s that are not personally identifying; but we now know that is not possible as relatively few attributes are sufficient to identify the real world individual with reasonable [[Accuracy]]. |
*There are two main sources of user [[Attribute]]s: | *There are two main sources of user [[Attribute]]s: | ||
| − | **The user is often asked to supply [[Attribute]]s, sometimes with a high level of [[Assurance]]. The [[Attribute]] may come directly from the user or from an [[Identifier or Attribute Provider]]. | + | **The user is often asked to supply [[Attribute]]s, sometimes with a high level of [[Assurance]]. The [[Attribute]] may come directly from the user or from an [[Identifier or Attribute Provider]]. In either case [[User Consent]] is easy to request and control. |
| − | **External sources generate [[User Information]] which could become [[Attribute]]s that help identify them, for example [[EHI]] or electronic health information from lab tests or health provider notes. | + | **External sources generate [[User Information]] which could become [[Attribute]]s that help identify them, for example [[EHI]] or electronic health information from lab tests or health provider notes. [[User Consent]] is harder to track and control since the user may not even understand the data generated or its implications. |
| + | |||
| + | Every attribute is a generalization, a categorization, a stereotype, a limitation on the real person to whom it applies. Human beings all have evolved to form generalizations about our world, it is how we make sense of the world. It is how we learn about the world. It is how we talk about the world. But, in the final analysis, all generalizations are at least partially wrong. Each person has their real identity and as we learn about them, we find new things about them. To remember we assign that person additional attributes so that we can remember them and so that we can talk about them. However we model attributes in the digital world, it needs to conform to the use that humans make of attributes in the real world.<ref>Hans Rosling, ''Factfulness.'' (2018-04) Flatiron chapter 6 ISBN 978-1-250-10781-7</ref> | ||
==Problems== | ==Problems== | ||
| Line 15: | Line 21: | ||
==Solutions== | ==Solutions== | ||
| − | * [[Attribute]]s should not be released until [[User Consent]] is obtained. | + | * [[Attribute]]s should not be released until informed [[User Consent]] is obtained. |
| + | |||
| + | ===Attribute Based Access Control=== | ||
| + | After releasing sufficient attributes about a entity, eventually the digital entity becomes associated with a real-world entity. | ||
| + | It is not a privacy-preserving operation but is still used in 2021 to do the digital to real-world binding. | ||
| + | * NIST Internal Report (NISTIR) 8112: Attribute Metadata defines a schema for metadata that describe a subject’s attributes; it is intended to give relying parties (RPs) greater insight into the methods attributes are determined to assist in making risk-based business decisions. As a result, RPs can examine this metadata and determine if they have the confidence they need in the attribute value before making an authorization decision. This NISTIR is being treated like an “implementers’ draft” – an approach used that focuses on real-world implementation results and lessons-learned before the document can become finalized. | ||
| + | * [https://www.dnsstuff.com/rbac-vs-abac-access-control RBAC vs. ABAC: What’s the Difference?] | ||
| + | * [https://techcommunity.microsoft.com/t5/azure-active-directory-identity/introducing-attribute-based-access-control-abac-in-azure/ba-p/2147069 Introducing Attribute Based Access Control (ABAC) in Azure] by Stuart Kwan in 2021-05-13. | ||
| + | ===Attribute Based Access Encryption=== | ||
| + | * Bill https://asecuritysite.com/abe/go_abe03 | ||
| + | * Brent Waters Goyal, Pandey, and Sahai published a paper entitled "Attribute-based encryption for fine-grained access control of encrypted data". It was published in 2006 and has been cited over 7,262 times, and is now known as the GPSW method: | ||
==References== | ==References== | ||
| − | + | <references /> | |
| + | ===External Material=== | ||
| + | |||
[[Category:Glossary]] | [[Category:Glossary]] | ||
[[Category:Identity]] | [[Category:Identity]] | ||
| + | [[Category:Attribute]] | ||
| + | [[Category:Privacy]] | ||
Latest revision as of 15:45, 17 November 2024
Contents
Full Title or Meme
Any datum (piece of data) about a digital entity. Where a digital entity is a named object.
Definitions from NIST IR 8480 (Initial Public Draft) Attribute Validation Services (AVS) for Identity Management: Architecture, Security, Privacy, and Operational Considerations[1]At its core, an attribute is a "quality or characteristic ascribed to someone or something" [NIST SP 800-63-3], such as a person's date of birth, residential address, or Social Security Number. Attributes are essential in confirming an individual’s identity or their eligibility to access certain services or information. An AVS validates these attributes against reliable data sources to confirm their accuracy. This validation process plays a pivotal role in secure identity proofing, access control, and fraud prevention.
Context
- In Identity Management an Attribute is also known as (aka) a Claim.
- At one time Attributes were considered to be a useful way to perform Authentication of a User.[2]
- Now it is realized that this method releases much User Private Information and offers low Assurance.
- Even the ISO definition of Personally Identifiable Information (or PII) seems to imply the existence of Attributes that are not personally identifying; but we now know that is not possible as relatively few attributes are sufficient to identify the real world individual with reasonable Accuracy.
- There are two main sources of user Attributes:
- The user is often asked to supply Attributes, sometimes with a high level of Assurance. The Attribute may come directly from the user or from an Identifier or Attribute Provider. In either case User Consent is easy to request and control.
- External sources generate User Information which could become Attributes that help identify them, for example EHI or electronic health information from lab tests or health provider notes. User Consent is harder to track and control since the user may not even understand the data generated or its implications.
Every attribute is a generalization, a categorization, a stereotype, a limitation on the real person to whom it applies. Human beings all have evolved to form generalizations about our world, it is how we make sense of the world. It is how we learn about the world. It is how we talk about the world. But, in the final analysis, all generalizations are at least partially wrong. Each person has their real identity and as we learn about them, we find new things about them. To remember we assign that person additional attributes so that we can remember them and so that we can talk about them. However we model attributes in the digital world, it needs to conform to the use that humans make of attributes in the real world.[3]
Problems
- Any attribute about a digital entity can be used to narrow the population that exhibits that attribute.
- If you want to see how little data is needed to uniquely determine your real world identity, or your preferences, just enter your data into this little tool].
Solutions
- Attributes should not be released until informed User Consent is obtained.
Attribute Based Access Control
After releasing sufficient attributes about a entity, eventually the digital entity becomes associated with a real-world entity. It is not a privacy-preserving operation but is still used in 2021 to do the digital to real-world binding.
- NIST Internal Report (NISTIR) 8112: Attribute Metadata defines a schema for metadata that describe a subject’s attributes; it is intended to give relying parties (RPs) greater insight into the methods attributes are determined to assist in making risk-based business decisions. As a result, RPs can examine this metadata and determine if they have the confidence they need in the attribute value before making an authorization decision. This NISTIR is being treated like an “implementers’ draft” – an approach used that focuses on real-world implementation results and lessons-learned before the document can become finalized.
- RBAC vs. ABAC: What’s the Difference?
- Introducing Attribute Based Access Control (ABAC) in Azure by Stuart Kwan in 2021-05-13.
Attribute Based Access Encryption
- Bill https://asecuritysite.com/abe/go_abe03
- Brent Waters Goyal, Pandey, and Sahai published a paper entitled "Attribute-based encryption for fine-grained access control of encrypted data". It was published in 2006 and has been cited over 7,262 times, and is now known as the GPSW method:
References
- ↑ Ryan Galluzo +3, 'NIST IR 8480 (Initial Public Draft) Attribute Validation Services for Identity Management: Architecture, Security, Privacy, and Operational Considerations 2024-10-07) https://csrc.nist.gov/pubs/ir/8480/ipd
- ↑ NIST Special Publication 800-162 Guide to Attribute Based Access Control (ABAC) Definition and Consideration https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.sp.800-162.pdf
- ↑ Hans Rosling, Factfulness. (2018-04) Flatiron chapter 6 ISBN 978-1-250-10781-7
