Re: [VoT] LoA, Use cases and other points raised

[Justin Richer <[e-mail]>]

Joanne, thanks very much for your comments. Replies inline below.


> On Nov 27, 2017, at 12:56 AM, Joanne Knight <[e-mail]> wrote:
> 
> Apologies for the long time lurking without commenting.
>  
> Writing from the perspective of a jurisdiction that never considered a single value of LoA, both NIST and VoT’s move to this model is welcomed ;-).
>  
> However, as I have stated before, approaching a core competency from a single delivery channel will mean that it is more likely that use cases will be excluded and that what is developed is prone to dating (we do not know what we do not know, especially new technology that will arise).

While it’s true that we’ve picked a specific serialization for the data model, we’ve tried to define the vector syntax as something that’s friendly to inclusion in a variety of locations, from JSON fields to XML elements to query parameters to headers, etc. So ultimately we’re not specifying a delivery channel, but we are specifying how it can be delivered over two existing channels (OIDC ID Tokens and SAML assertions).

>  
> While I am confident that the VoT needs the 4 elements P, C, M and A, and the resulting ‘Trustmark’ (the mechanism)  is logical, the point at which use cases become problematic is in the defining of the number and make-up of levels in each of the components, clauses 3.1 to 3.4. I have before suggested a more principled based approach and for there to be a clear separation between aspects of identity and aspects of the delivery channel.

This dichotomy came about from a desire to balance two things: defining a completely general-purpose approach that’s so non-specific that it would have to be nearly fully defined by anything that wanted to use it; or a fully comprehensive and future-proof thing that’s usable out of the box. We’ve decided to go between these and lean more towards the former: VoT defines a model and approach for splitting assurance along multiple dimensions, a general-purpose syntax for conveying this model, and a simple (and very much non-comprehensive) example definition of the vector’s contents. 

>  
> The question comes down to how much has to be right in the first cut?
> In my view I would replace the word ‘calculate’ in the abstract/introduction with ‘indicate’. I would also not add any reference to a particular jurisdiction’s work.

With “calculate” I wanted to emphasize that the parties in question have to do some processing on the values, particularly the RP who has to make sense of it in making security decisions. I’m open to a better term to convey this if there is one, as an engineer I tend to think in terms of code execution and calculations. :) The NIST guidelines are given as an example of such single-scalar frameworks, as they were one of the first and arguably internationally known. VoT is not intended to be tied to any jurisdiction, and we can try to make it more clear that they’re an example.

> Then for 3.1 to 3.4 either _
> ·         Avoid specifying the number and make-up of levels (‘usable out the gate’, leaving this to be agreed initially between the parties of an exchange) or 
> ·         We do the requisite work to ensure these capture potentially all existing and future use cases (the gold level or ‘unicorn’, suggest using the aforementioned principles-based approach to make it more encompassing). 

As above, we tried to do a little of both. We fully expect groups like NIST to define their own vector contents, or even components entirely (After all, you’re not limited to P, C, M, and A, those are just the four that we defined as common, core components). Other groups might want to just pull the values directly from the RFC, and use them in a way that makes sense to their environment. These groups shouldn’t need to have to define everything from scratch just to have *something* in place. In all cases, the values defined in the document (all of section 3) are there to guide people defining their own values. 

>  
> As far as ‘John being John’ and the iGov reference, Gov bods (of which I am one) need to remember that not everyone (including a lot of gov) needs to know if ‘John really is John’ in order to provide him a service. I keep seeing way too many instances where orgs (including gov) are requesting more than they need identity-wise, to deliver a transaction or service.

Completely agree, this is one of the motivating factors for splitting proofing into its own bucket to begin with.

>  
> There is one further step that I have not yet seen in this stream. To quote one of our other members ‘Attributes, not identity’!
> What we are currently proposing applies equally to any attribute needing assertion, not just ‘identity’ attributes. Add to this, the difficulty with interpretation caused by ‘identity’ having a random set of attributes associated to it, depending on context. I would therefore like to see our unicorn cater for any attribute and for the VoT to apply to individual attributes and not a set as currently stated.
>  

Attribute metadata is very explicitly not the ocean we want to boil with VoT. If someone wants to adopt the VoT approach to attributes, that’s fine — but I strongly believe that is not work we should be trying to solve here. Specifically because VoT as-is solves a lot of problems that people have today. Access to attribute metadata will help some use cases, sure, but many use cases won’t care. I’ve gotten feedback on that last section of the intro text, and to be clear what I really mean here is that processing attributes by the RP is problematic because it’s prohibitive for simple cases, potentially disastrous for user privacy (since the RP can’t make a decision about data until it knows all the data and decides what it can ignore), but still is probably worth it for some transactions. I think it’s a bad design to make all transactions pay the cost of these complex cases. 

> Take or leave as you will.

Thanks again for the feedback, and please keep an eye out for the next revision. 

 — Justin


>  
> Joanne
>  
>  
>   <>
> From: Justin Richer [mailto:[e-mail] <mailto:[e-mail]>] 
> Sent: Sunday, 26 November 2017 6:01 PM
> To: Chris Drake; Phil Hunt
> Cc: John Bradley; Paul A. Grassi; Leif Johansson; [e-mail] <mailto:[e-mail]>
> Subject: Re: [VoT] IPR disclosures
>  
> It's no mistake that both NIST and VoT have moved toward this model. VoT started as a conversation that Paul Grassi and I had years ago about how to improve on LoA, and at that same meeting Leif and others joined the conversation and we set down the roots of what would become VoT, including the chartering of this very mailing list. 
>  
> Furthermore, I'm a co author on the newest version of the NIST document in question, and my involvement in the rewrite was in part to develop this model further. They're commentary and in fact we are currently working on an additional volume that explicitly maps the NIST xAL model into the VoT expression syntax. You can see this work on NIST's public GitHub: https://github.com/usnistgov/800-63-3/blob/volume-d/sp800-63d/vot_mapping.md <https://github.com/usnistgov/800-63-3/blob/volume-d/sp800-63d/vot_mapping.md>
>  
> So to answer if VoT gives anything that xAL doesn't is pretty simple: VoT provides a syntax for communicating the xAL (and potentially other information) across the network between parties. The xAL definitions provide detailed guidance to how to reach each level in each category, VoT says how to send that info in an ID Token. 
>  
> I'm curious what you have in mind for pii as eliminating liability, but I have a feeling it's a bit more ocean boiling than we're after here. 
>  
> --Justin
>  
>  Sent from my phone
>  
> -------- Original message --------
> From: Chris Drake <[e-mail] <mailto:[e-mail]>>
> Date: 11/25/17 11:17 PM (GMT-05:00)
> To: Justin Richer <[e-mail] <mailto:[e-mail]>>, Phil Hunt <[e-mail] <mailto:[e-mail]>>
> Cc: John Bradley <[e-mail] <mailto:[e-mail]>>, "Paul A. Grassi" <[e-mail] <mailto:[e-mail]>>, Leif Johansson <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]>
> Subject: Re: [VoT] IPR disclosures
>  
> Hi All,
> 
> NIST got rid of LoA for a reason - it seems disingenuous to express VoT in terms of something that's already been obsoleted - particularly the whistle-blower example, since that's exactly why NIST got rid of LoA in the 1st place.
> 
> If VoT brings anything that IAL/AAL/FAL does not, this needs to be spelled out.  If it does not bring anything, then it needs to be improved so it does - there's no need us building a VoT paring knife when everyone's already got the NIST paring knife .
> 
> In practical applications, I think NIST and VoT both have not properly considered commercial adoption risks - if improved addressing of PII protection and eradication of liability risks was incorporated, then VoT could be a standard that beats all others simply because it's commercially irresponsible to pick anything else.  This is radical innovation though, not mere improvement.
> 
> Kind Regards,
> Chris Drake
> 
> Sunday, November 26, 2017, 1:01:58 PM, Justin Richer wrote:
> 
> From a technical standpoint, this is done by configuration. I get a vector and a trustmark URL. As an RP, I can look at the trustmark URL and do a simple string comparison against a list of trustmark URLs that I’ve been configured to trust — much the same way that RPs that talk to multiple IdPs do so today with issuer URLs (in both OIDC and SAML worlds). You’re absolutely right that deciding what goes on that list is a business decision, and more philosophical than technical. However, as a technical spec, VoT seeks to solve the technical problem of how to convey the information of what the IdP thinks about the current user and the current transaction. It does not seek to solve the question of how the RP determines if the IdP is allowed to make those claims or not, but instead gives the IdP a means of making these claims (a means that doesn’t exist otherwise). It’s not the end-goal that you are seeking, but it’s a major step forward. 
> 
> Per John’s request, here’s the introduction text that I’ve been working on this week as the draft goes forward:
> 
> 
> Methods for measuring trust in digital identity transactions have historically fallen into two main categories: either all measurements are combined into a single scalar value, or trust decisions are calculated locally based on a highly detailed set  of attribute metadata. This document defines a method of conveying trust information that is more expressive than a single value but less complex than comprehensive attribute metadata. 
> 
> Prior to the third edition published in 2017, NIST Special Publication 800-63 used a single scalar measurement of trust called a Level of Assurance (LoA). An LoA can be used to compare different transactions within a system at a coarse level. For instance, an LoA4 transaction is generally considered more trusted (across all measured categories) than an LoA2 transaction. The LoA for a given transaction is computed by the identity provider (IdP) and is consumed by a relying party (RP). Since the trust measurement is a simple numeric value, it’s trivial for RPs to process and compare. However, since each LoA encompasses many different aspects of a transaction, it can’t express many real-world situations. For instance, an anonymous user account might have a very strong credential, such as would be common of a whistle-blower or political dissident. Despite the strong credential, the lack of identity proofing would make any transactions conducted by the account to fall into a low LoA. Furthermore, different use cases and domains require subtly different definitions for their LoA categories, and one group’s LoA2 is not equivalent or even comparable to another group’s LoA2. 
> 
> Attribute based access control (ABAC) systems used by RPs may need to know details about a user’s attributes, such as how recently the identity data was verified and by whom. Attribute metadata systems are capable of expressing a large and detailed amount of detail about the transaction. However, this approach requires the IdP to collect, store, and transmit all of this attribute data for the RP’s consumption. The RP must process this data, which may be prohibitive even for the most trivial security decisions. 
> 
> Vectors of Trust (VoT) seeks a balance between these two alternatives by allowing expression of multiple aspects of an identity transaction (including but not limited to identity proofing, credential strength, credential management, and assertion strength), without requiring full attribute metadata descriptions. This method of measurement gives more actionable data and expressiveness than an LoA, but is still relatively easy to process and calculate by the RP. It is anticipated that VoT can be used alongside more detailed attribute metadata systems. The RP can use the vector value for most basic decisions but be able to query the IdP for additional attribute metadata where needed. Furthermore, it is anticipated that some trust frameworks will provide a simple mapping between certain sets of vector values to LoAs, for RPs that do not have a need for the vector’s higher level of detail.
> 
> This document defines a data model for these vectors and an on-the-wire format for conveying them between parties, anchored in a trust definition. Additionally, this document defines a general-purpose component values and a mechanism for defining custom vector components which can be used by systems that need something more specific. 
> 
> 
> 
> Happy to hear feedback about the new intro and if it situates this work better. I still believe that you (Phil) want a different solution to a different problem than what VoT solves. Namely, I think you want the attribute metadata solution which would augment VoT, as described above. That’s great, and I look forward to seeing progress in that area as well. However, VoT shouldn’t be held up from solving the 90% use case that Paul mentions because the other 10% is going to take a lot more work. You want a surgical scalpel. We just need a good, sharp paring knife. Right now, everyone’s using a pointy stick and hoping for the best. VoT was never meant to solve what you’re asking it to solve, nor do I believe it should try to do so. Let other good work do that, and let this solve what it’s meant for. 
> 
> — Justin
> 
> On Nov 24, 2017, at 12:52 AM, Phil Hunt <[e-mail] <mailto:[e-mail]>> wrote:
> 
> What you described to me before required an RP to set up policy manually based on the reputation of the asserting party (eg its main business) in order to divine the meaning of its identity proofing. 
> 
> If that is the case, VoT as a standard does not improve interop, it causes more confusion because the spec does not define how a system may interpret the value other than in a philosophical sense. "Is John really John?" just isn't useful if it isn't the right John.
> 
> Phil
> 
> On Nov 23, 2017, at 7:27 PM, Grassi, Paul A. (Fed) <[e-mail] <mailto:[e-mail]>> wrote:
> 
> Fine. But as I have said you want a unicorn when we just want a car that can drive in the same Lane as SAML. Your unicorn is coming, as the phases of igov include international agreement on vot vectors/values and attribute metadata to assert 'assurance' of attributes that are unrelated to proofing.  
> 
> I happy for your contribution don't take unicorn comment poorly. Just a quick post turkey dinner way of making a point. Happy US Thanksgiving. 
> 
> Sent from my iPhone
> 
> On Nov 23, 2017, at 5:25 PM, Phil Hunt <[e-mail] <mailto:[e-mail]>> wrote:
> 
> The issue i am concerned about then is that by leaving out the issue of claims than the vot is incomplete and would require a separate statement. 
> 
> This leads to a lot of interop and complexity problems down the road.  Which value wins etc given they would overlap. 
> 
> The vot does not have to address it now but it should have the capability to do so (that may not be possible without a model). 
> 
> This is a lot like when we found loa was actually multi dimensional and it had to dramatically change.  IAL falls into the same problem. 
> 
> Phil
> 
> On Nov 23, 2017, at 2:08 PM, Leif Johansson <[e-mail] <mailto:[e-mail]>> wrote:
> On 2017-11-23 21:23, John Bradley wrote:
> Authors,
> As part of the write-up for the Vectors of trust document, we need an
> IPR disclosure from all of you.
> Are you aware of any IPR related to the following VOT document?
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dricher-2Dvectors-2Dof-2Dtrust_%26d%3DDwIGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DQbLS61Tkq_l46PCZqD5dxO1fLIa4bYOrGBHGDtJrGNY%26s%3DMzyyadRifkHa-POatwYHEwdNoC7wUj777DGKpyRF2RE%26e&data=02%7C01%7Cpaul.grassi%40nist.gov%7Cab4db3d0fc7a4643a7af08d532c119eb%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636470727310173986&sdata=1dkeGx37WKNwiWfLzR5YNC4KBjqYWqVnt%2B%2FOt7ArqvE%3D&reserved=0= <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Fdatatracker.ietf.org-5Fdoc-5Fdraft-2D2Dricher-2D2Dvectors-2D2Dof-2D2Dtrust-5F-2526d-253DDwIGaQ-2526c-253DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI-5FJnE-2526r-253Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA-2526m-253DQbLS61Tkq-5Fl46PCZqD5dxO1fLIa4bYOrGBHGDtJrGNY-2526s-253DMzyyadRifkHa-2DPOatwYHEwdNoC7wUj777DGKpyRF2RE-2526e-26data-3D02-257C01-257Cpaul.grassi-2540nist.gov-257Cab4db3d0fc7a4643a7af08d532c119eb-257C2ab5d82fd8fa4797a93e054655c61dec-257C1-257C0-257C636470727310173986-26sdata-3D1dkeGx37WKNwiWfLzR5YNC4KBjqYWqVnt-252B-252FOt7ArqvE-253D-26reserved-3D0-3D&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=6pFNIrvLm_EVnrUedIGFNW_kMZCvTRZ5ab06FeZUKjc&s=2RClbjcnYKDBXmf1KD7VanmYH6nDWpZDULEQ6sZ88j4&e=>
> Please reply to the list.  
> Regards
> John B. 
> I am not.
> _______________________________________________
> vot mailing list
> [e-mail] <mailto:[e-mail]>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_vot%26d%3DDwIGaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DQbLS61Tkq_l46PCZqD5dxO1fLIa4bYOrGBHGDtJrGNY%26s%3DvMBbg4PMZy1qgq6VilC4_SKh4m6b5wkecJsTBKu6txU%26e&data=02%7C01%7Cpaul.grassi%40nist.gov%7Cab4db3d0fc7a4643a7af08d532c119eb%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636470727310173986&sdata=kSRrzffFE6tfhI5p%2F4bk5qXC23kK%2BlMjSa34zlyqaZY%3D&reserved=0= <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Fwww.ietf.org-5Fmailman-5Flistinfo-5Fvot-2526d-253DDwIGaQ-2526c-253DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI-5FJnE-2526r-253Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA-2526m-253DQbLS61Tkq-5Fl46PCZqD5dxO1fLIa4bYOrGBHGDtJrGNY-2526s-253DvMBbg4PMZy1qgq6VilC4-5FSKh4m6b5wkecJsTBKu6txU-2526e-26data-3D02-257C01-257Cpaul.grassi-2540nist.gov-257Cab4db3d0fc7a4643a7af08d532c119eb-257C2ab5d82fd8fa4797a93e054655c61dec-257C1-257C0-257C636470727310173986-26sdata-3DkSRrzffFE6tfhI5p-252F4bk5qXC23kK-252BlMjSa34zlyqaZY-253D-26reserved-3D0-3D&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=6pFNIrvLm_EVnrUedIGFNW_kMZCvTRZ5ab06FeZUKjc&s=UqHpaS9QjeMY15gHdFCEX_FO5XRklOJMScA5eihR3vg&e=>
> 
> 
> _______________________________________________
> vot mailing list
> [e-mail] <mailto:[e-mail]>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fvot&data=02%7C01%7Cpaul.grassi%40nist.gov%7Cab4db3d0fc7a4643a7af08d532c119eb%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636470727310173986&sdata=6OwTIaa5BjmDXJU4vAzBWtOSbH1Zpav4J6O1Ume7Ra0%3D&reserved=0 <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Fvot-26data-3D02-257C01-257Cpaul.grassi-2540nist.gov-257Cab4db3d0fc7a4643a7af08d532c119eb-257C2ab5d82fd8fa4797a93e054655c61dec-257C1-257C0-257C636470727310173986-26sdata-3D6OwTIaa5BjmDXJU4vAzBWtOSbH1Zpav4J6O1Ume7Ra0-253D-26reserved-3D0&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=6pFNIrvLm_EVnrUedIGFNW_kMZCvTRZ5ab06FeZUKjc&s=ixALt99rsc4S4DHGtiVPqK6m-5hgnihnrWEMoWEwyM4&e=>
> _______________________________________________
> vot mailing list
> [e-mail] <mailto:[e-mail]>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_vot&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=6pFNIrvLm_EVnrUedIGFNW_kMZCvTRZ5ab06FeZUKjc&s=aoP99Dm88C5EjMwqmtCLIc8D3cn5YU15sh25LsYxKlw&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_vot&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=6pFNIrvLm_EVnrUedIGFNW_kMZCvTRZ5ab06FeZUKjc&s=aoP99Dm88C5EjMwqmtCLIc8D3cn5YU15sh25LsYxKlw&e=>