Re: [VoT] VoT Identity Proofing and individual claims

[Justin Richer <[e-mail]>]

I completely disagree with that statement. Like I've said several times, the trust frameworks that define the vector components will do that part, like the NIST document does already. I understand what you're saying: you can't take a bundle of attributes and just assume they're all equally valid, without any other context. I agree with this. However, it's not the goal of VoT to communicate that granularity of information within the vector, and in fact doing so was an explicit anti-goal. This was brought up years ago when I first proposed this, and it's in the list archives. 
Furthermore: We don't leave proofing undefined entirely, as you claim, it's just defined by a different piece that slots into this to make a wall working system. For NIST, this is 800-63A. Then 800-63D defines vector component values that reference that framework, and this VoT draft defines how those go together and get expressed in the authentication protocol. 
You can use VoT without the NIST framework, you could even use it without proofing values at all. It's a mechanism for conveying this information. If there's a way to better state this, please suggest text that helps convey that we're not covering that here in VoT. 
 If instead you're concerned with how the vector components are interpreted, then that's not really appropriate to be covered here. Rather, it's a comment for the document that defines them. I would suggest starting with the NIST document, which is going to be one of the first ones in use by iGov implementations (which started this whole discussion). 
--Justin
 Sent from my phone
-------- Original message --------From: "Phil Hunt (IDM)" <[e-mail]> Date: 9/13/17  5:32 PM  (GMT-05:00) To: Justin Richer <[e-mail]> Cc: [e-mail] Subject: Re: [VoT] VoT Identity Proofing and individual claims 
I am saying you cannot and must not solve the problem you are solving without dealing with the individual claims and how they combine to form an overall proof.
Leaving proofing undefined moves to a situation worse than depending on Level of authentication alone. 
Phil
On Sep 13, 2017, at 1:59 PM, Justin Richer <[e-mail]> wrote:

Phil, responses inline.

On Sep 13, 2017, at 3:09 PM, Phil Hunt <[e-mail]> wrote:

Justin,
I don’t believe making things arbitrarily out of scope helps simplify.  In this case, I believe it complicates matters.

I don’t understand your argument. We’re solving one problem, but not the problem you’re trying to solve. It feels complicated because you’re trying to use a tool that’s not fit for the problem you’re presenting. That doesn’t mean that it’s complicated for the problem the tool is designed for. Keeping other things out of scope is exactly making this a tractable problem within particular boundaries. This decision of scope for this work is hardly arbitrary or ill-informed, so dismissing it as such is both misunderstanding the work and not helpful in the conversation. 
Firstly, missing from the spec….a definition of Identity.
We didn’t try to define “identity” as a term because there is no one single agreed-upon definition of identity, and yet it is understood broadly as a concept enough to make identity systems work, isn’t it? We do have a discussion of our identity model at play in section 1.2 though. I’m assuming you’ve read that, so please submit text that would improve that section.

2.1.  Identity Proofing

   The Identity Proofing dimension defines, overall, how strongly the
   set of identity attributes have been verified and vetted.  In other
   words, this dimension describes how likely it is that a given digital
   identity transaction corresponds to a particular (real-world)
   identity subject.

   This dimension SHALL be represented by the "P" demarcator and a
   single-character level value, such as "P0", "P1", etc.  Most
   definitions of identity proofing will have a natural ordering, as
   more or less stringent proofing can be applied to an individual.  In
   such cases it is RECOMMENDED that a digit style value be used for
   this component.
What is meant by overall?  Is it an average?  The lowest value of all of the attributes (claims)?

Again, that depends on the specific trust framework that defines what the values mean. For NIST, for example, there are baseline proofings required for all mentioned attributes at a given IAL. If you don’t meet that level for all of those attributes, then you don’t meet that IAL. Other frameworks could provide something else, but I’ve yet to see a different approach. Do you know of a trust framework that defines an “average” proofing level for a user’s attributes? 
Also interesting to note: if you’re providing additional attributes that aren’t listed in the framework, like “has a medical degree”, then you’re on your own as the framework doesn’t address those. If you need to address those separately, you’ll need a framework (and vector definitions) that cover those. 
And if you want to have different sets of information for each attribute, then you’ll want a different solution that’s not VoT.
What is meant by a real world identity subject?  Do you mean a legal person?  Do you mean a device/thing?
Sure, those would all work. All depends on what the IdP is providing identity assertions for. We’re not going to artificially limit that, though we do have "a person using a computer system” generally in mind. Again, see section 1.2 for more details on that model. 

An overall level of confidence in how strongly a transaction corresponds to a particular identity subject sounds an awful lot like authentication confidence.
An overall confidence would be that, but this isn’t what we’re saying: it’s how much the attributes are tied to a real person. How strongly that gets tied to the transaction is subject to the other vector components, such as authentication credentials and assertions. That’s the whole reason of splitting it out separately. So yes, it’s not as granular as individual attributes, which you’re asking about below, but it’s more granular than a single level of confidence that you have stated here. It’s in between, like we say in the introduction. 

I can see how you might arrive at this definition looking an an internal data system like a payroll system. You can assess the procedures and establish an overall confidence level in the quality of data.  But as soon as you want to share that payroll data with other systems.  
I began my experience in Identity management building large scale meta-directories. We once assumed business systems like payroll systems were authoritative over things like employee addresses.  Turns out we were wrong.  Payroll doesn’t care about addresses, they care about bank account deposit numbers.  
Then, by your trust framework and context, you wouldn’t ask payroll for addresses, right? So if your trust framework requires you to verify the address at, say, P3, but you don’t do that, then you’re not doing P3 for those. And if you need to split out classes of users where you’ve got “authoritative bank account numbers” and “authoritative bank account numbers AND addresses”, then you define two different categories to represent those classes of users. If you want a system that can describe the assurance of an arbitrary attribute for a given transaction, then VoT doesn’t work for you. Go find a screwdriver and stop trying to figure out why this hammer doesn’t work for you.

Conclusion:  Just because the payroll department has a high level of confidence in the attributes they have *internally*, it does not mean there is high confidence for secondary uses.  If you ask payroll about sharing data, they might only share employee number, salary, and bank accounts as being accurate (assuming there was a valid reason to share).  Should an IDP based on payroll only assert high level data?  Can they assert low-level data for the purpose of correlation/confirmation?
Another case, look at Facebook and Twitter. They have variable assertions as well.  Some users are verified and some are not.  What does that mean? How would VoT help in this case?  Would it mean that the out of scope information in the name claim is deemed accurate?  Are we talking about the same Michael Douglas or are we talking about Michael Keaton (Michael Keaton’s real name is Michael Douglas).
VoT would help in exactly this case by being able to assert different proofing based on different accounts. But it all comes down to what you trust the IdP to assert given its trust framework context — if they agreed to proof the name, and they say they did, and you trust them to make that claim, well then you’re all set. If they don’t agree to that (as in it’s not stipulated in the trust agreements) , or they agreed to it and lied about it, or they did it but you don’t trust them to say it … then I can’t really help you with this. 
In the end, VoT is all about one simple thing: conveying bundles of information about mostly-orthogonal aspects of an identity transaction. It’s about an IdP telling an RP: “I did the following things from a list of things that we agreed upon”. Just like saying “LOA3” in the US Government context meant something pretty specific, saying “P2.Cc.Ab” also means something specific in that kind of context. But saying “LOA3” in Canada means something a little bit different, and saying “LOA3” elsewhere could be completely unrelated to either case. In all of these, both the LoA and VoT versions, interpretation of the result to a particular real-world meaning is outside the conveyance protocol or encoding. There’s a massive amount of context that is taken into account, and that context will tell you if you can trust the name or the address or anything else when you get a particular value.
You’re trying to fit it into something it’s not meant for and not good at, and asking why it doesn’t work; to me, it’s no surprise that it doesn’t work for that. VoT does not do what you’re describing, and that’s by design. That part is spelled out in the introduction. On the same token, your lawnmower makes a pretty bad toothbrush. But like I keep reiterating: if you have a different problem, use a different tool. I am perfectly happy with this technology not being a silver bullet or panacea or what have you. There are a lot of people who seem to have the problem that this tool solves, so we’re going to keep going with solving those problems. I look forward to seeing your solutions for attribute trust and metadata in the future.
Thanks, — Justin


Phil
Oracle Corporation, Identity Cloud Services [e-mail]@oracle.com


On Sep 13, 2017, at 10:57 AM, Justin Richer <[e-mail]> wrote:
It applies to the IdP’s judgement across the entire assertion. How that’s calculated when the trust in different attributes differs will vary depending on the IdP, and probably defined by rules within the trust framework that defines the vector values themselves. NIST 800-63-3 volume A, for example, is very clear about how to handle all the attributes collected at different levels. If you were using NIST’s encoding of VoT, specified in the upcoming volume D of that document, then you’d be bound by those rules as an IdP. A university group, like you’re talking about below, might have different rules under its own trust framework and vector component definitions.
It looks like you might be asking if this is about per-attribute metadata. If you read the introduction, we explicitly state that we’re not trying to solve per-attribute metadata. If you’d like that kind of data, you’re looking for a different kind of solution, of which there have been numerous attempts over the years. Generally speaking, attribute metadata systems look great on paper but are incredibly complicated for RP’s to implement. When we wrote VoT, we directly decided to take a different approach, something between the granularity of attributes and the single-scale of LOA. 
This level of granularity is very, very useful in the real world, otherwise we wouldn’t have dozens of international trust frameworks based around the concept of proofing an individual and tying that account to a set of proofed attributes. There isn’t an easy way to express something complex as “We’re sure this is Justin but aren’t sure about his medical degree” in any VoT implementation that I’ve seen to date, and especially not in the example values given in the spec itself. But if you really wanted to, you could have something like:
 - P3: High level of confidence in individual’s name, address, phone, eye color, and shoe size - Pm: In person verification of a medical degree by making the claimant perform surgery on the verifier.
So if you wanted to express that, you could say “P3.Pm” or just “P3” if you weren’t so sure about that medical degree. However, like I described above, I don’t think this is a good solution for that as you’d need to get really specific with each attribute. If you really need that level of expressiveness, you’ll want a different solution and VoT doesn’t work for you. However, just because it doesn’t solve this use case doesn’t mean it’s not useful in many others. VoT is a tool fit for a purpose that we tried to express in the intro text, it fits in between attribute metadata and single scalar measurements. And in fact, you could use it side by side in the same system, and I see no conflict in this.
Don’t deny the world a hammer just because you think you need a screwdriver.
 — Justin
On Sep 13, 2017, at 1:01 PM, Phil Hunt <[e-mail]> wrote:

Section 3.1
Does 3.1 apply to the identifier issued, to the whole assertion? 
An Identity is usually an identifier and a set of claims.
So what about claims?   Some claims may be issued by a provider (and thus are P3) while others may be provided as self asserted by the subject.  Some, as in banking may have involved a physical documents or other mechanism and thus all claims are not equal.
I have trouble determining the affect of P0-P3 and worry that privilege escalation will occur since not all claims are equal.  There isn’t really a way to say “We’re confident this is Justin, we’re just not so sure about his medical degree”.
Consider a university knows student numbers and degrees and courses completed. Is it authoritative over nationality, residence, addresses?  Maybe. Maybe not.
Consider a social network. In many cases they can be considered authoritative over the social network identity (P3) but know nothing about most users.
I’m just not sure identity proofing as expressed is actually useful.

Phil
Oracle Corporation, Identity Cloud Services [e-mail]@oracle.com


_______________________________________________
vot mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/vot



_______________________________________________
vot mailing list
[e-mail]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_vot&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=YA2JdBOYM3SQx_1fv088j5CyhfvTmnNkKzLEMsXgaWg&s=QaJdlNrWPDiVCUqj1JxH47PsYrKlCK7y_cZGiMQ0_mY&e=