Attribute Metadata Publication
The repository is for the active development of an attribute metadata schema.
Full HTML version can be viewed at https://pages.nist.gov/NISTIR-8112
Organization:
2
Type:
Reference (Include section and paragraph number):
3.2.2.1
3.2.1.3
Comment (Include rationale for comment):
A nice to have...
For example in situations where RP and AP are roles within the same organisation, it may be useful to also indicate a specific staff-member that executed the verification of an attribute or changed the value of an attribute.
Example:
Within an enterprise there may be a process in which a ServiceDesk operator changes the email-address for an enduser.
By means of additional attributes it can be made transparent to the RP and/or enduser which operator applied the change.
Suggested Change:
Introduce
Organization: 1 = Federal, 2 = Industry, 3 = Other
1:
Minor:
4,1 Federated Access ...:
Since Monique is on SIPRNet, change Clearance requirement to "Secret":
Suggested Change:
Organization: 1 = Federal, 2 = Industry, 3 = Other
Organization:
Type:
Reference (Include section and paragraph number):
3.2.1.4
Comment (Include rationale for comment):
Description for "Acceptable Uses" speaks of additional uses. It's not clear in addition to what.
I think this is a remnant of previous version of the report that had primary and additional uses.
Suggested Change:
Organization: 1 = Federal, 2 = Industry, 3 = Other
Organization:
MITRE:
Section 3.2.1.2:
Last Update and Last Verification are similar, as mentioned in a different issue. Expiration Date is more distinct.:
Reorder to Last Verification, followed by Last Update, followed by Expiration using an order driven by a combination of stability and logical order (e.g. create reqts precede update reqts. precede delete reqts in requirements lists. Yes, this example is not directly germane.:
Organization: 1 = Federal, 2 = Industry, 3 = Other
MITRE:
Minor:
Section 3 Metadata first paragraph:
Implies attributes are single valued in fourth sentence.
Change "the attribute and its value" to "the attribute and its value[s]:
Organization: 1 = Federal, 2 = Industry, 3 = Other
Organization: 2
Type:
Reference (Include section and paragraph number): Definitions: Section 2 - Assertions; Section 2 - Claims
Comment (Include rationale for comment): Attribute Assertions are often made by Users when registering to obtain a new account from an RP. These assertions include those attributes required by an RP to authorize service for the User. The RP may choose to verify the User Asserted attributes via 3rd party Attribute Providers (AP) who in turn will generate Claims (and/or Scores) about the validity of the User Assertions. For example, contextual attributes, including affiliation (e.g., job status, clearance), biometric and device identity attributes that are associated with a User may be Asserted by users to generate verification Claims from corresponding AP services each time a user attempts to authenticate to a service. This would also be the case for "Step-Up" authentication requirements.
Suggested Change: Include User Asserted attributes as a class of Asserted attributes for the purpose of account registration, Claims refresh, and contextual authentication requirements.
Organization: 1 = Federal, 2 = Industry, 3 = Other
Organization: ITIM Consulting
Type: 2
Reference (Include section and paragraph number): Section 3, para (many)
Comment (Include rationale for comment): Definitions in SP800-63-3 have been modified over time. This issue is a reminder to re-synchronize definitions between the documents. For example these definitions in NISTIR 8112 no longer match 800-63-3 definitions: Assertion, Federation, Identity Provider (definition and case of acronym), Credential Service Provider, Relying Party, Attribute Claim,
Suggested Change:
Update the definitions in NISTIR 8112 using NIST SP 800-63-3 as the source.
Organization: 1 = Federal, 2 = Industry, 3 = Other
Organization:
2 www.iwelcome.com
Type:
Reference (Include section and paragraph number):
3.2.1.5
Comment (Include rationale for comment):
The classification section currently has 'classification' attribute, which can be used to document an attribute's security classification.
For processing of personal data also a sensitivity/confidentiality classification may be relevant. For example, a person's racial or ethnic origin, sex life or sexual orientation should be treated with higher level of confidentiality as 'regular' personal data like address information.
Suggested Change:
A 'privacy/sensitivity/confidentiality classification' could be added to document an attribute's classification. Recommended values could be:
In the context of the EU's GDPR, this privacy classification is defined by http://www.privacy-regulation.eu/en/9.htm
Alternately, the definition of the 'classification' data could be made more general: "A sensitvity, confidentiality, security or any other classification level of the attribute"
---
Organization: 1 = Federal, 2 = Industry, 3 = Other
1:
:
Section 3.2.1.4 Acceptable Uses Element:
I can see a number of combinations of this Element which is not described as multivalued. For example, an attribute may be used for multiple authorizations, some of which are by another party. Does this mean Secondary Use is the value of is it just Authorization? Secondary Use's description includes "beyond initially divulged" but sort of assumes the original divulging was for authorization. That may not be the case. And what does No Further Disclosure mean when an attribute may flow from an Origin to a Provider to another Provider? Just who is not supposed to disclose it further?:
This has to be rethought, because it combines the attribute value's use and its dissemination. This may require two different elements.:
Organization: 1 = Federal, 2 = Industry, 3 = Other
Organization: 2
Type:
Reference (Include section and paragraph number): section 2
Comment (Include rationale for comment): 'Trust Time' is not defined in the definitions section
Suggested Change:
Please add a definition for 'trust time'
Organization: 1 = Federal, 2 = Industry, 3 = Other
Organization:
Type:
Reference (Include section and paragraph number):
Comment (Include rationale for comment):
In case a consent is given for usage of a minor's data, this consent may not be given by the subject himself, but by one of his parents.
It makes sense to capture this in the metadata for transparancy and auditing purposes.
Suggested Change:
Introduce a "grantor" privacy metadata attribute that holds information about who granted the consent when different from the subject-user.
(I'm not a native speaker of the english language, I hope i express myself clearly)
---
Organization: 1 = Federal, 2 = Industry, 3 = Other
Organization:
2
www.iWelcome.com
Type:
IDaaS provider
Reference (Include section and paragraph number):
3.2.1.4 Privacy
Comment (Include rationale for comment):
The European Union introduces the GDPR, which is effective May 2018.
It lists 6 types of legal basis for the processing of personal data, one of which is consent by the data subject. (http://www.privacy-regulation.eu/en/6.htm)
NISTIR-8112 has a privacy section that puts focus on consent. This is however just one possible legal basis for processing of personal data.
Suggested Change:
In the privacy section, introduce 'legal basis' defined as 'legal basis for processing of the personal data'. In the EU, possible values would be:
"consent"
"contract"
"legal obligation"
"vital interest of data subject"
"public interest"
"legitimate interest persued by data controller"
---
Organization: 1 = Federal, 2 = Industry, 3 = Other
1:
Minor:
3.2.1.3 Pedigree element, Derived value:
This may be superseded by DCoxe's issue, but the example in Derived is too simple. To say that I can determine age from DOB suggests a new value: "Calculated":
I'm not sure Calculated as a value is useful, and a revisit of Derived based on the other issue may lead to a different example.:
Organization: 1 = Federal, 2 = Industry, 3 = Other
Organization:
Type:
Reference (Include section and paragraph number):
Comment (Include rationale for comment):
Suggested Change:
Replace Acceptable Uses in executive summary with the 2 privacy attributes indicated in the 'core' document: Accepotable Primary uses and Acceptable Additional Uses.
---
Organization: 1 = Federal, 2 = Industry, 3 = Other
NSTIC Workshop,
I have compiled a list of comments on the draft, below. I hope that some or all of them are useful to you in this laudable endeavor, and that even those comments you disagree with may lend some insight into those aspects of the presentation which may lead to a misunderstanding. Thank you for your work.
1) There is an apparent oversight of including classification/dissemination for data subject to collateral agreements other than FVEY, e.g. NATA classification, bilateral agreements, etc.
2) It is unclear whether the classification metadata element is the classification of the data or the classification of the metadata associated with the data. In either case, there probably needs to be metadata designating the classification/dissemination caveats for the data AND the metadata, particularly the description.
3) The Description column for the Releasability row has a grammatical flaw.
4) Cache Time to Live -- a clock time, UTC, or a time period (in which case the time of the cache needs to be made a metadata element).
5) A generalization of (4) above, a scrub needs to be performed for all of the metadata elements for which a particular format is required -- another example would be "date consented" the date metadata needs to be consistently parsed, and should be based on a standard (for example, the date at the international date-line). "No restrictions" is too vague for many of these elements.
6) While the use cases focus on access control, not all of the metadata elements are focused on access control. What other use cases should be included (which hints at what other metadata tags are required)? For instance, for intelligence estimates, a confidence level would be important.
Organization: 2
Type:
Reference (Include section and paragraph number):
3.2.1.1. Accuracy Metadata Elements - Verification Methods
3.2.1.3. Provenance - Pedigree
Comment (Include rationale for comment): Data stores about users are generally created using "Derived" methods by cross-correlating data from many sources - including commerce transaction data, court data, insurance data, US Postal data, and authoritative data sources from government. These AP services support Attribute Verification based on Derived Methods, and generally through an online interface. These AP services may include data from Methods 1 - 4, but are not necessarily Authoritative.
The Section under Attribute Provenance and Pedigree includes the category of Derived, but falls short on a crucial concept: Attributes are verified based on pairs or combinations of attribute assertions. An attribute assertion is generally not verifiable without correlation to other attributes. For example: verification of assertion pairs is possible such as Name and Address; Name and cell phone number; Name, address, clearance, job status, ss#, and telephone number. These assertion pairs are correlated to generate a "Confidence" score about the validity of each attribute in the context of the others. A single attribute such as Name cannot be verified with assurance without the context of affiliated attributes that constitute the User's identity.
Suggested Change:
Organization: 1 = Federal, 2 = Industry, 3 = Other
Organization:
Type:
Reference (Include section and paragraph number):
Comment (Include rationale for comment):
Whenever a consent is given, that consent is given to some legale entity.
In context of (European) privacy regulations, that entity would be seen referred to as a "data controller".
Suggested Change:
Introduce a metadata element (in privacy category) to hold the name of the data controller to whom the consent was given.
Organization: 1 = Federal, 2 = Industry, 3 = Other
Organization:
www.iWelcome.com
Type:
Reference (Include section and paragraph number):
3.2.1.1
Comment (Include rationale for comment):
The accuracy metadata are relevant or pertaining to determining if the attribute’s value is correct and belongs to a specific subject.
The focus/bias of possible values for VerificationMethod is on the aspect of "belongs to a specific object". For attributes that are self-asserted but have not been verified, there is the notion of validation: some values can be known to be valid or not, regardless of the question whether or not the value belongs to the specific subject. A valid but unverified, self-asserted address has more value than an invalid, unverified, self-asserted address.
Having this attribute brings the value of not applying a verification process on invalid values.
Suggested Change:
Introduce Validation attribute in the 'accuracy' category.
Possibly also a Validator attribute.
Validity has possible values "Valid", "Invalid", "Possibly valid", "Not validated".
Validator could be something like https://www.ups.com/content/us/en/bussol/browse/online_tools_us_address_validation.html.
Note that "Possibly valid" could be used to indicate situations where the value cannot be invalidated but cannot be confirmed to be valid with certainty.
Organization: 2 = Industry
Organization:
2
Type:
Reference (Include section and paragraph number):
3.2.1.1
4.2
Comment (Include rationale for comment):
The report distinguishes between the following parties:
The allowed/recommended values for the Verifier-attribute suggest it's either the Origin or the Provider that is verifying the attribute.
It may however be the case that an attribute is verified by neither Origin nor AP. In this case the Pedigree could be "Sourced".
An IDP could act as a attribute 'proxy', acting as a RP towards one or more APs and acting as a AP to various RPs. Note that section 3.2.1.3 recognizes sources other than Origin. In a similar fashion, it makes sense to recognize different Verifiers
Suggested Change:
The report could suggest as possible values for Verfier:
Alternately, the report could explain that the "Provider" (Provenance), does NOT have to be the Attribute Provider itself. In the 2nd use case it says "Verifier: Provider: The clearance was verified by the IDP (also acting as the AP in this instance)", so that suggests that indeed the "Provider" does not have to be the AP. The example in section 4.2 could be improved to give an example value for the Provider attribute, indicating the relevant IDP.
Extending the previous remark, I would suggest
---
Organization: 1 = Federal, 2 = Industry, 3 = Other
Organization:
2
Type:
Reference (Include section and paragraph number):
1.2
Comment (Include rationale for comment):
Intuitively, people speak of 'attribute metadata'. The document describes two flavors of metadata.
While talking about 'attribute metadata', it will be easier to distinguish which sub-flavor is being discussed if each falvor has it's own term.
Suggested Change:
I think it wood be usefull to call the two flavors:
Organization: 1 = Federal, 2 = Industry, 3 = Other
1:
Minor:
4,1:
"... is protected by ABAC." implies ABAC is a thing, rather than a technique. :
Change to "... protected using ABAC principles.":
Organization: 1 = Federal, 2 = Industry, 3 = Other
Organization:
2
Type:
Reference (Include section and paragraph number):
3.2.2.1
Comment (Include rationale for comment):
The specification indicates various Verification Methods. The description implicitely suggests one method is perceived as stronger than others.
I think it could make sense to somehow classify or order the various methods, so the RP can more easily decide whether or not it will use the attribute.
See also related comments here: #19
Suggested Change:
Provide guidance for strength of methods, or introduce a new Accuracy-attribute named "Verification Strength".
The RP can then say: I'll accept anything with strength at least "3".
Order of strength is probably
Organization: 1 = Federal, 2 = Industry, 3 = Other
Otherwise we can't edit down the road and always have to hunt down Danna. Please put source files in /media folder as well.
Thanks!
MITRE:
Minor:
3.2.1.2 "Last Update":
"Last update" .... date and time .. last refreshed" may be confusing. To me, update implies a change whereas refresh implies rewriting with the same value.:
Based on the definition, I would change the title to "Last Refresh" or "Last Verified":
Organization: 1 = Federal, 2 = Industry, 3 = Other
MITRE:
Minor:
Section 3.2.1.2, Origin and Provider:
Expecting legal name of the entity is too legalistic and cumbersome. While it may better ensure all parties are "using the same sheet of music", it precludes agreement on other vocabularies and forces everyone to scurry around (and debate) lengthy organization names and whether "LLC" is part of the name and should be spelled out, etc.:
Delete "legal" and allow parties to decide what names they want to use.:
Organization: 1 = Federal, 2 = Industry, 3 = Other
Organization:
2
Type:
Reference (Include section and paragraph number):
3.2.1.4
Comment (Include rationale for comment):
The user typically would give consent for a certain usage of the attribute.
User may have expressly given consent to use his e-mail address for password reset e-mails.
It may be "Unknown" whther user has given consent to use his e-mail address for newsletters.
Etc.
Suggested Change:
Each attribute should get a multivalued set of (complex) Privacy-attributes. Imho these could be:
An additional attribute could be:
Maybe in this way it would be better to see "Acceptable Additional Uses" as just another value for this multivalued "Privacy"-attribute set, having "Use"="Disclosure" and "Individual Consented"="No".
---
Organization: 1 = Federal, 2 = Industry, 3 = Other
Organization:
2
Type:
Reference (Include section and paragraph number):
1.2
3.2.1.5
Comment (Include rationale for comment):
The report states in sectiuon 1.2: "While the schema in this document is intended to demonstrate the value of attribute metadata in supporting U.S. Federal Government use cases, 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. "
However the description/definition of classification-metadata is written to accomodate Federal Government use cases.
Suggested Change:
Classification: "The regulatory classification level of the attribute."
For example, in the European Union, different regulations will apply to personal data such as the GDPR. In the Attribute metadata "Allowed Values", it can be made specific which regulatory classifications are applicable.
Probably the Releasability can be gneralised as well.
Another consideration would be if the classification-metadata is really attribute VALUE metadata or attribute metadata (on schema level).
Organization: 1 = Federal, 2 = Industry, 3 = Other
MITRE:
Minor:
Section 3.2.1.3:
Unwinding Origin, Provider, etc. challenges the reader because these are both elements and values.:
Move Provenance to be first; it describes the most stable values and is the logical starting point. Then Accuracy follows, which is more dynamic / varying by attribute value. Last would be Currency, the most dynamic.:
Organization: 1 = Federal, 2 = Industry, 3 = Other
Organization: 2
Type:
Reference (Include section and paragraph number): section 3.2.1.2. Currency Metadata, Expiration Date paragraph
Comment (Include rationale for comment): It appears that the 'Last Update' element should actually refer to the 'Last Refresh' element
Suggested Change:
confirm which element is intended to be referenced
Organization: 1 = Federal, 2 = Industry, 3 = Other
MITRE:
Minor:
3.2.1.2:
The distinction between Last Update and Last Verification is unclear. Is there some usefulness in knowing that an AAS pushed out the same attributes without verifying them?:
Depends on results of discussion of question above. Also, though, I think a role assignment would be a better example in Last Verification than security clearance; it has broader utility to the audience and it's a chronic problem to take away role assignments.:
Organization: 1 = Federal, 2 = Industry, 3 = Other
Organization:
2
Type:
IDaaS
Reference (Include section and paragraph number):
3.2
Comment (Include rationale for comment):
When first reading the document it was not clear to me how to interpret the information in the "Values" / "Recommended Values" columns.
At the same time I appreciate that agreements about (Recommended) Values are to be agreed, as per the "Allowed Values", as indicated in section 3.1.2.
The report seems a bit ambiguous whether it's open for RP/APs to agree on allowed/recommended values versus prescribing allowed values.
Suggested Change:
Example:
Organization: 1 = Federal, 2 = Industry, 3 = Other
Organization:
Type:
Reference (Include section and paragraph number):
Comment (Include rationale for comment):
Suggested Change:
Organization: 1 = Federal, 2 = Industry, 3 = Other
Organization: 2
Type: Overall comment on the type of data being collected and confidentiality
Reference (Include section and paragraph number): General
Comment (Include rationale for comment):
This standard appears to be adding some Personally Identifiable Information (PII) to documents. I did not see the mention of document: NIST SP800-122
Guide to Protecting the Confidentiality of Personally Identifiable Information anywhere.
http://csrc.nist.gov/publications/nistpubs/800-122/sp800-122.pdf
In addition, due to the sensitivity of this information, there may be a requirement for encrypting the document. Again, no references appear that mention encrypting said documents.
Suggested Change:
Organization: 1 = Federal, 2 = Industry, 3 = Other
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.