Verification Methods and Provenance - Derived Attribute Claims and Assertion Pairs

[DCoxe]

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:

• Include Derived methods as a type of Verification Method.
• Add the concept under Attribute Provenance and Pedigree that Attributes, and the corresponding confidence of accuracy, are verified based on pairs or combinations of attribute assertions.
• As a general comment: The underlying theme of this document appears IDP- centric where attributes are primarily used for ID Proofing. Identity federation and ABAC use cases will often employ verification of contextual attributes not available via participating IDPs, and may involve users asserting attributes for verification (claims generation) from 3rd party AP services, enterprise LDAP, biometric and device ID services. In these use cases, the IDP service may be primarily utilized for outsourcing the authentication service for login rather than for a means of provisioning verified attribute claims that are contextual to a specific RP use case requirements.

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

[RGalluzzo]

David,

Thanks for the comments!

With regard to Verification Method--we were taking a very strict view of the term when thinking about the different values and debated several times the inclusion of a method that reflected leveraging different non-authoritative data sources to corroborate or correlate an attribute’s value. We landed on not including this since we did not consider "corroboration" or "correlation" to be the same as “verification.” That being said, we are open to including a new verification method, though we are leaning towards the term "correlated" rather than "derived" to avoid confusion with the other AVM item of the same name.

On your second item comment, this seems to be more relevant to the binding of attributes into a single identity rather than verification of attribute values. While we agree there is value in viewing an attribute within the context of a single identity, it does not necessarily make those correlated attributes more accurate. For example, just because my name and DOB are bound to my clearance does not make the value of any of those more accurate or correct. This paper is more focused on the characteristics of the individual attributes that could be useful for determining whether or not they can be adequately trusted when making authorization decisions.

We also agree with your final assertion that the attributes used in specific use cases could come from almost any source. We intended to make this document agnostic of source and will review the language again to avoid an bias towards a specific federation model or architecture.

Thanks again and please let us know if you have any additional thoughts on this disposition.

[DCoxe]

Ryan,

Thanks for your feedback. My suggestions are intended to reflect the state of the market with existing attribute providers and the terminology used. If you are focusing on identity proofing versus ABAC use cases, verification methods will vary. I believe verification is a better term that will apply for all use cases, and will be accepted by industry paticipants.

To the extent attributes are asserted by users via online interfaces versus in-person, the collection of attribute assertions are what each RP requires to resolve to an identity and ultimately mitigate risk. Depending upon the use case and target user group, the RP may emphasize the need to verify certain attributes. For example, a mobile application may want to verify a user’s cell phone number over email address when collecting other PII.

The attached NASPO study highlights the need to use multiple attributes to resolve to an identity. Another interpretation is that a single attribute cannot be verified without the context of other identity attributes. Given the current state of the attribute/data business ecosystem, a single attribute cannot be relied upon to resolve to a unique identity with any accuracy, particularly online. I’m not sure the premise of defining “characteristics of the individual attributes that could be useful for determining whether or not they can be adequately trusted when making authorization decisions” is supportable.

Unfortunately, most identity attributes are transitory and are subject to errors in collection, storage and fraud. I have a personal story about my DoB that I’ll share with you if you are interested. Even Biometrics can arguably be modified. As such, linking an individual to a single attribute is problematic, and mainly reliable when verified at a point in time within the context of a specific purpose (e.g., issue a credential, authorize service via a trusted device).

This is a set of topics that we debated heavily when we finalized the OIX AXWG Specification. You might want to touch base with Kim Little from Lexis if you want additional input.

Regards,

Dave

David Coxe, CEO ID/DataWeb, Inc. DCoxe@IDDataWeb.commailto:DCoxe@IDDataWeb.com 571-332-2740 cell 571-723-4310, ext 502 office

From: RGalluzzo [mailto:notifications@github.com] Sent: Friday, August 05, 2016 10:57 AM To: usnistgov/NISTIR-8112 Cc: Dave Coxe ID; Author Subject: Re: [usnistgov/NISTIR-8112] Verification Methods and Provenance - Derived Attribute Claims and Assertion Pairs (#19)

David,

Thanks for the comments!

With regard to Verification Method--we were taking a very strict view of the term when thinking about the different values and debated several times the inclusion of a method that reflected leveraging different non-authoritative data sources to corroborate or correlate an attribute’s value. We landed on not including this since we did not consider "corroboration" or "correlation" to be the same as “verification.” That being said, we are open to including a new verification method, though we are leaning towards the term "correlated" rather than "derived" to avoid confusion with the other AVM item of the same name.

On your second item comment, this seems to be more relevant to the binding of attributes into a single identity rather than verification of attribute values. While we agree there is value in viewing an attribute within the context of a single identity, it does not necessarily make those correlated attributes more accurate. For example, just because my name and DOB are bound to my clearance does not make the value of any of those more accurate or correct. This paper is more focused on the characteristics of the individual attributes that could be useful for determining whether or not they can be adequately trusted when making authorization decisions.

We also agree with your final assertion that the attributes used in specific use cases could come from almost any source. We intended to make this document agnostic of source and will review the language again to avoid an bias towards a specific federation model or architecture.

Thanks again and please let us know if you have any additional thoughts on this disposition.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/usnistgov/NISTIR-8112/issues/19#issuecomment-237872922, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQt-7XKb_S422pMLpv1DJ4NgDq1MPIvtks5qc09BgaJpZM4JatOc.

[JaapFrancke]

Hi, Interesting discussion! I agree with David's view that often a verification process is applied to a combination of attributes.

In the European Union, the concept of STORK assurance levels has been introduced. See https://www.eid-stork2.eu/. "STORK is a platform which allows people to use their national electronic ID to establish new e-relations with foreign electronic services, which may be operated by public or private service providers. STORK 2.0 extends the STORK platform by allowing legal persons (such as companies) to be represented by natural persons." The ultimate goal would be to have identities with STORK level 4; in this case the identity's profile-attributes have been proven with face-to-face authentication. STORK level 2, however, acknowledges situations where a certain combination of attributes values accurately correspond with (for example) a passport, proving the combination of name and DoB correspond to an existing person. At STORK level 2, no face-to-face authentication has taken place, however, so the person that 'owns' the e-ID might as well be the spouse or anyone else that has access to a passport. At STORK level 3, an e-identity has the accuracy that one knows for sure a person exists with a certain combination of attributes (i.e. Name, adress, DoB, etc..), an authentication token was sent (out-of-bound) to a user's phonenumber and/or home address, but still....it could be the user's spouse that is in fact in possession of the electronic identity. STORK-3 is consdered as fairly trustworthy none-the-less. Long story short: accuracy of attributes is not a black-or-white thing in terms of proofing.

My suggestion is to introduce a VerificationCorrelationID. Attribute values that have been verified through one and the same verification process, could be given the same VerificationCorrelationID to 'link' them together.

See also my suggestion to introduce the concept of verification strength https://github.com/usnistgov/NISTIR-8112/issues/48

I hope I expressed myself clearly (not being a native speaker),

regards, Jaap