[VoT] LoA, Use cases and other points raised

[Joanne Knight <[e-mail]>]

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 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.

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.
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 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.

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.

Take or leave as you will.

Joanne



From: Justin Richer [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]
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

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=