Re: [VoT] IPR disclosures

[Justin Richer <[e-mail]>]

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]> 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=>