Subject: [VoT] IPR disclosures

From: John Bradley <[email-masked]>
Date: Fri, 24 Nov 2017 05:23:03 +0900

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://datatracker.ietf.org/doc/draft-richer-vectors-of-trust/

Please reply to the list.

Regards
John B.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 23 Nov 2017 12:58:40 -0800

I am still not happy with this spec. 

The identity proofing portion is arbitrarily limited based on non-specific definitions. Iow. I believe an identity proof is based on a set of claims being individually calculated. 

The nist notion of identity proofing is largely a human rather than an informational conclusion leads to the kind of trouble the no fly lists have had. RPs need to know the difference between one john smith and another john smith and that a particular one is not another. This is not addressed by simply a level of proof that john is john. 

Phil

> On Nov 23, 2017, at 12:23 PM, John Bradley <[email-masked]> wrote:
> 
> Authors,
> 
> As part of the write-up for the Vectors of trust document, we need an IPR disclosure from all of you.
>

---

From: John Bradley <[email-masked]>
Date: Fri, 24 Nov 2017 06:18:03 +0900

Your unhappyness will be noted.

Justin has some new text for the introduction that may help.

Justin can you copy the proposed changes to the list?

To restate the previous discussion.  Like Authentication Context class
reference in SAML and OIDC it is separate trust frameworks/federation
agreements that define identity proofing.

How individual claims/attributes other than subject, that are asserted as
part of a security token are proofed and that is indicated in the token is
out of scope for VOT as it is for ACR.

I appreciate that you would like this specification to also cover asserted
claims.

Do I have that correctly?

Regards
John B.

On Nov 23, 2017 12:58 PM, "Phil Hunt" <[email-masked]> wrote:

> The identity proofing portion is arbitrarily limited based on non-specific
> definitions. Iow. I believe an identity proof is based on a set of claims
> being individually calculated.
>
> The nist notion of identity proofing is largely a human rather than an
> informational conclusion leads to the kind of trouble the no fly lists have
> had. RPs need to know the difference between one john smith and another
> john smith and that a particular one is not another. This is not addressed
> by simply a level of proof that john is john.
>
> Phil
>
> _______________________________________________
> vot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vot
>
>

---

From: Leif Johansson <[email-masked]>
Date: Thu, 23 Nov 2017 23:08:39 +0100

> Please reply to the list.  

I am not.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 23 Nov 2017 14:25:12 -0800

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 <[email-masked]> wrote:
> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dricher-2Dvectors-2Dof-2Dtrust_&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=QbLS61Tkq_l46PCZqD5dxO1fLIa4bYOrGBHGDtJrGNY&s=MzyyadRifkHa-POatwYHEwdNoC7wUj777DGKpyRF2RE&e=
>> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_vot&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=QbLS61Tkq_l46PCZqD5dxO1fLIa4bYOrGBHGDtJrGNY&s=vMBbg4PMZy1qgq6VilC4_SKh4m6b5wkecJsTBKu6txU&e=

---

From: "Grassi, Paul A. (Fed)" <[email-masked]>
Date: Fri, 24 Nov 2017 03:27:18 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Phil

On Nov 23, 2017, at 2:08 PM, Leif Johansson <[email-masked]<mailto:[email-masked]>> wrote:

As part of the write-up for the Vectors of trust document, we need an
IPR disclosure from all of you.

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=

Regards
John B.

I am not.

_______________________________________________
vot mailing list
[email-masked]<mailto:[email-masked]>
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=

_______________________________________________
vot mailing list
[email-masked]<mailto:[email-masked]>
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

---

From: "Grassi, Paul A. (Fed)" <[email-masked]>
Date: Fri, 24 Nov 2017 04:17:44 +0000

As the USG rep, I can confidently state that the use case this version supports is 90% of our use cases. Don’t hold us up for the last 10%. That 10% will be amazing, but can come later. What is being asked for is gold-plating, not something that if not done means we are wrong.

Paul

From: Chris Drake <[email-masked]>
Date: Thursday, November 23, 2017 at 10:49 PM
To: "Grassi, Paul A. (Fed)" <[email-masked]>, Phil Hunt <[email-masked]>
Cc: John Bradley <[email-masked]>, Leif Johansson <[email-masked]>, Justin Richer <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [VoT] IPR disclosures

Hi,

I'm on the side of "get it right".  OpenID swept a similar range of topics into the "out of scope" basket, which rendered their first standard so unusable they had to come back and do a second one.

Lets at least learn from history, and build something *effectively useable* out of the gate.

You can't drive unsafe or inappropriate cars on any roads, let alone in a SAML lane.  Nobody cares *how* it goes wrong, they just care that it did - so it's our job to look ahead and watch out for those obstacles now; rather than shroud them in SEP<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhitchhikers.wikia.com%2Fwiki%2FSomebody_Else%2527s_Problem_field&data=02%7C01%7Cpaul.grassi%40nist.gov%7Cc7d5fb325a5b4a20da7608d532ee6374%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636470921831105773&sdata=RSZtGAFRE%2B%2FJl2nT2iSnfndt0EW097naltRcS67%2BYQ0%3D&reserved=0>.

Kind Regards,
Chris Drake

Friday, November 24, 2017, 1:27:18 PM, Grassi, Paul A. (Fed) wrote:

Sent from my iPhone

Phil

Authors,

Regards

John B.

I am not.

vot mailing list

---

From: John Bradley <[email-masked]>
Date: Fri, 24 Nov 2017 13:36:46 +0900

We should probably try and keep the VOT and iGov discussions separate.

IGov's use of VOT should largly be on the iGov mailing list at the OIDF.
VOT is only a small reference in iGov.  If that needs to be expanded then
discuss over there.

This list is for the core VOT spec, and it's fitness to purpose.

Concrete examples of profiles for security token trust that cannot be
accommodated by VOT would be helpful when making points that the spec is
inadiquate in some way.

Taking off yet again, so out of communication for at least 12h.

John B.

On Nov 23, 2017 11:17 PM, "Grassi, Paul A. (Fed)" <[email-masked]>
wrote:

> As the USG rep, I can confidently state that the use case this version
> supports is 90% of our use cases. Don’t hold us up for the last 10%. That
> 10% will be amazing, but can come later. What is being asked for is
> gold-plating, not something that if not done means we are wrong.
>
>
>
> Paul
>
>
>
> *From: *Chris Drake <[email-masked]>
> *Date: *Thursday, November 23, 2017 at 10:49 PM
> *To: *"Grassi, Paul A. (Fed)" <[email-masked]>, Phil Hunt <
> [email-masked]>
> *Cc: *John Bradley <[email-masked]>, Leif Johansson <[email-masked]>,
> Justin Richer <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [VoT] IPR disclosures
>
>
>
> Hi,
>
> I'm on the side of "get it right".  OpenID swept a similar range of topics
> into the "out of scope" basket, which rendered their first standard so
> unusable they had to come back and do a second one.
>
> You can't drive unsafe or inappropriate cars on any roads, let alone in a
> SAML lane.  Nobody cares *how* it goes wrong, they just care that it did -
> so it's our job to look ahead and watch out for those obstacles now; rather
> than shroud them in SEP
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhitchhikers.wikia.com%2Fwiki%2FSomebody_Else%2527s_Problem_field&data=02%7C01%7Cpaul.grassi%40nist.gov%7Cc7d5fb325a5b4a20da7608d532ee6374%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636470921831105773&sdata=RSZtGAFRE%2B%2FJl2nT2iSnfndt0EW097naltRcS67%2BYQ0%3D&reserved=0>
> .
>
> Kind Regards,
> Chris Drake
>
>
> 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 <[email-masked]> 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
>
> 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%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7q
> IrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%
> 3DQbLS61Tkq_l46PCZqD5dxO1fLIa4bYOrGBHGDtJrGNY%26s%3DMzyyadRifkHa-
> POatwYHEwdNoC7wUj777DGKpyRF2RE%26e&data=02%7C01%7Cpaul.grassi%40nist.gov%
> 7Cab4db3d0fc7a4643a7af08d532c119eb%7C2ab5d82fd8fa4797a93e054655c6
> 1dec%7C1%7C0%7C636470727310173986&sdata=1dkeGx37WKNwiWfLzR5YNC4KBjqYWq
> Vnt%2B%2FOt7ArqvE%3D&reserved=0=
>
>
>
>
>
> 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%7C2ab5d82fd8fa4797a93e054655c6
> 1dec%7C1%7C0%7C636470727310173986&sdata=kSRrzffFE6tfhI5p%2F4bk5qXC23kK%
> 2BlMjSa34zlyqaZY%3D&reserved=0=
>
>
>
> 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
>
>
>
>
>
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 23 Nov 2017 21:52:43 -0800

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) <[email-masked]> wrote:
> 
> 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=

---

From: Phil Hunt <[email-masked]>
Date: Thu, 23 Nov 2017 21:56:01 -0800

Regardless of the WG, both IETF and OpenId Foundations are international orgs.  The specs have to work globally. 

VoT should work for Paul's cases AND everyone else. 

Phil

> On Nov 23, 2017, at 8:36 PM, John Bradley <[email-masked]> wrote:
> 
> IGov's use of VOT should largly be on the iGov mailing list at the OIDF.  VOT is only a small reference in iGov.  If that needs to be expanded then discuss over there.  
> 
> Concrete examples of profiles for security token trust that cannot be accommodated by VOT would be helpful when making points that the spec is inadiquate in some way.  
> 
>> On Nov 23, 2017 11:17 PM, "Grassi, Paul A. (Fed)" <[email-masked]> wrote:
>> You can't drive unsafe or inappropriate cars on any roads, let alone in a SAML lane.  Nobody cares *how* it goes wrong, they just care that it did - so it's our job to look ahead and watch out for those obstacles now; rather than shroud them in SEP.
>> 
>> Kind Regards,
>> Chris Drake
>> 
>>

---

From: Chris Drake <[email-masked]>
Date: Fri, 24 Nov 2017 13:49:26 +1000

Hi,

Kind Regards,
Chris Drake

Sent from my iPhone

Phil

Authors,

Regards

John B. 

I am not.

vot mailing list

[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Sat, 25 Nov 2017 21:50:49 -0500

I am aware of no IPR related to VoT.

 — Justin

> On Nov 23, 2017, at 3:23 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Authors,
> 
> https://datatracker.ietf.org/doc/draft-richer-vectors-of-trust/ <https://datatracker.ietf.org/doc/draft-richer-vectors-of-trust/>
>

---

From: Justin Richer <[email-masked]>
Date: Sat, 25 Nov 2017 22:01:58 -0500

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 <[email-masked]> wrote:
> 
> On Nov 23, 2017, at 7:27 PM, Grassi, Paul A. (Fed) <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Nov 23, 2017, at 5:25 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>> On Nov 23, 2017, at 2:08 PM, Leif Johansson <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>>> 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=>
>>>>> 
>>>> [email-masked] <mailto:[email-masked]>
>>>> 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=>
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> 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=>
>> [email-masked] <mailto:[email-masked]>
>> 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=>

---

From: "Grassi, Paul A. (Fed)" <[email-masked]>
Date: Mon, 27 Nov 2017 19:09:07 +0000

WE have iGov tomorrow. I encourage those that are on the workgroup to come to discuss this, as we have made a bunch of changes (to include some recommended by Phil) and will be going to a vote soonest. I can assure you that even though USG requirements are represented in the draft, it isn’t interoperable and is inline with other international use cases.

From: John Bradley <[email-masked]>
Date: Thursday, November 23, 2017 at 11:37 PM
To: Paul Grassi <[email-masked]>
Cc: Chris Drake <[email-masked]>, Phil Hunt <[email-masked]>, Leif Johansson <[email-masked]>, Justin Richer <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [VoT] IPR disclosures

John B.

On Nov 23, 2017 11:17 PM, "Grassi, Paul A. (Fed)" <[email-masked]<mailto:[email-masked]>> wrote:
As the USG rep, I can confidently state that the use case this version supports is 90% of our use cases. Don’t hold us up for the last 10%. That 10% will be amazing, but can come later. What is being asked for is gold-plating, not something that if not done means we are wrong.

Paul

From: Chris Drake <[email-masked]>
Date: Thursday, November 23, 2017 at 10:49 PM
To: "Grassi, Paul A. (Fed)" <[email-masked]<mailto:[email-masked]>>, Phil Hunt <[email-masked]<mailto:[email-masked]>>
Cc: John Bradley <[email-masked]<mailto:[email-masked]>>, Leif Johansson <[email-masked]<mailto:[email-masked]>>, Justin Richer <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [VoT] IPR disclosures

Hi,

Kind Regards,
Chris Drake

Sent from my iPhone

Phil

Authors,

Regards

John B.

I am not.

vot mailing list

---

From: Jim Fenton <[email-masked]>
Date: Mon, 27 Nov 2017 16:42:27 -0700

I'm sure Paul meant to say, "is interoperable.". 

-Jim

> On Nov 27, 2017, at 12:09 PM, Grassi, Paul A. (Fed) <[email-masked]> wrote:
>

---

From: Chris Drake <[email-masked]>
Date: Tue, 28 Nov 2017 11:46:53 +1000

Hi All,

Completely missing from the standard are any "two directional" vectors:

100% of the work here is user-focussed, with no attention on RP / IdP legitimacy - a huge mistake, since 91% of successful attacks against authentication take advantage of the completely-missing "machine to user" authentication step (e.g. NIST "Verifier Impersonation Resistance").

I can't decide if this needs to be a new set of vectors, or if it makes sense to incorporate into one of the existing ones:

*. Who is the RP, and how certain is the User/IdP that the RP is legitimate ?
*. Who is the IdP, and how certain is the RP/User that the IdP is legitimate ?
*. What steps has the IdP taken to ensure the users and RPs are not duped ?

What I am certain about, is that it needs to be in the standard.  It makes NO SENSE to put all this effort into something that addresses only 9% of the problem.  NIST recently fixed this, so should we.

Kind Regards,
Chris Drake