Subject: [saag] Vectors of Trust - Experimental or Standards Track

From: Phil Hunt <[email-masked]>
Date: Tue, 12 Sep 2017 12:32:22 -0700

Adding saag so we can get this on the record per Kathleen’s suggestion.

Apologies I originally started this thread as communications with the authors.

Justin, I initiated this thread because of the classification of the Vectors of Trust document[0] as “experimental". As weird as you suggest the IETF is, RFC2026 defines “experimental” designation as:
> 4.2.1 <https://tools.ietf.org/html/rfc2026#section-4.2.1>  Experimental
> 
>    The "Experimental" designation typically denotes a specification that
>    is part of some research or development effort.  Such a specification
>    is published for the general information of the Internet technical
>    community and as an archival record of the work, subject only to
>    editorial considerations and to verification that there has been
>    adequate coordination with the standards process (see below).  An
>    Experimental specification may be the output of an organized Internet
>    research effort (e.g., a Research Group of the IRTF), an IETF Working
>    Group, or it may be an individual contribution.

R&D is not the case with this draft given what is on track with NIST and OpenID Foundation.
The OpenID Foundation iGov Working Group and apparently NIST are *currently* referencing this as a mandatory requirement for operational use rather then use exclusively in research and development, the classification is inappropriate. Specifically the iGov draft refers to the VoT as an IETF “standard”. The OpenID iGov draft was just voted to “implementation” status which means people are now implementing for production and NOT R&D. Regardless of the differences in terms, iGov is intended to be a standard while VoT is currently not.[1]
I understand new SP-800-63 regulations are being developed that will use this “standard”.[2]

I am concerned that as “experimental", the VoT draft will not receive the proper scrutiny it needs to have. I am not sure why it is at the IETF since its domain of use is largely OpenID and SAML.

I will leave comments regarding “VoT” draft for the VoT list at a later time.

[0] https://tools.ietf.org/html/draft-richer-vectors-of-trust-05
[1] https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/igov/raw/master/openid-igov-profile.xml#rfc.section.3.4
[2] https://github.com/usnistgov/800-63-3/blob/volume-d/sp800-63d/vot_mapping.md

Thanks clearing this up.

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
> On Sep 12, 2017, at 10:47 AM, Justin Richer <[email-masked]> wrote:
> 
> Phil,
> 
> The draft started out in standards-track then moved to experimental during one of the revisions due to some feedback. Recent feedback has asked to put it back in standards-track, and I’d be fine with either to be honest. But in the end I don’t think that designation really matters, and you’re reading way more into it than is intended. I recall there was a similar discussion a couple years ago (that you, Phil, were a part of), where OAuth was called out as not being a “real standard” because the RFC states it’s a “proposed standard”. This, like now, I think is a misinterpretation of the meaning and intent of the document designations and is a distraction from what’s important. Yes, the IETF is weird in how it calls things — but we don’t get to pick their terms or redefine their meanings. 
> 
> I anticipated VoT going to RFC well over a year and a half ago — it’s been stable that long, and that’s why you don’t see much recent traffic on the vot@ietf mailing list — but as an AD-sponsored document it’s been slow finding shepherds and getting through the process without a WG chair pushing things. This doesn’t make it any less valid of a standard, but it does change the process that it goes through, somewhat. It will still get full IESG review. And, the important part, it’s still useful and usable. 
> 
> As far as I can see it, your main argument against using VoT is that it’s a draft standard — but so is iGov. And VoT can and will be moved forward in the IETF as an RFC standard. That process is happening now, John is the shepherd and has the power to move it forward.
> 
> So with this in mind, John’s discussion below is spot on. The way that VoT gets used is fairly simple:
> 
> The RP can request a “vtr", which basically says “this is the VoT that I’d like”. IdP can respond with “vot”, which is “here’s your vector values”, along with “vtm", which is “here’s where the contents of this vector are defined”. NIST, as mentioned and as I’d linked to you, is defining its own “vtm” document. This will define what “P1” means (surprise, it maps directly to IAL1), among everything else. The values in the VoT draft aren’t used in that case, since they exist under a “vtm” defined by the RFC, once that’s assigned and published, but you don’t have to use them. And iGov is not in the business of defining which “vtm” people should be using, but we want implementations to at least use the same mechanism — VoT — for conveying similar information. 
> 
>  — Justin
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 12 Sep 2017 16:46:05 -0400

Actually, I’d had a few bits that were waiting in the update queue already, so I went ahead and changed that flag and published a new version just now:

https://tools.ietf.org/html/draft-richer-vectors-of-trust-06 <https://tools.ietf.org/html/draft-richer-vectors-of-trust-06>

 — Justin

> On Sep 12, 2017, at 3:47 PM, Justin Richer <[email-masked]> wrote:
> 
> Right, and now that there are concrete implementations and references, I'd agree that it's not as experimental anymore and we can switch it to standards track. As I mentioned below, you're not the first to make this suggestion. It's a tiny change and I can do that easily during the next revision when we get shepherd or IESG comments that require changes. 
> 
> Thanks, 
> 
> --Justin
> 
>  Sent from my phone
> Right, and now that there are concrete implementations and references, I'd agree that it's not as experimental anymore and we can switch it to standards track. As I mentioned below, you're not the first to make this suggestion. It's a tiny change and I can do that easily during the next revision when we get shepherd or IESG comments that require changes. 
> Thanks, 
> --Justin
>  Sent from my phone
> -------- Original message --------
> From: Phil Hunt <[email-masked]>
> Date: 9/12/17 3:32 PM (GMT-05:00)
> To: Justin Richer <[email-masked]>
> Cc: John Bradley <[email-masked]>, Tony Nadalin <[email-masked]>, Kathleen Moriarty <[email-masked]>, Leif Johansson <[email-masked]>, [email-masked]
> Subject: Vectors of Trust - Experimental or Standards Track
> 
> [0] https://tools.ietf.org/html/draft-richer-vectors-of-trust-05 <https://tools.ietf.org/html/draft-richer-vectors-of-trust-05>
> [1] https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/igov/raw/master/openid-igov-profile.xml#rfc.section.3.4 <https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/igov/raw/master/openid-igov-profile.xml#rfc.section.3.4>
> [2] 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>
> 
> Thanks clearing this up.
> 
> Phil
> 
>> On Sep 12, 2017, at 10:47 AM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Phil,
>> 
> -------- Original message --------From: Phil Hunt <[email-masked]> Date: 9/12/17  3:32 PM  (GMT-05:00) To: Justin Richer <[email-masked]> Cc: John Bradley <[email-masked]>, Tony Nadalin <[email-masked]>, Kathleen Moriarty <[email-masked]>, Leif Johansson <[email-masked]>, [email-masked] Subject: Vectors of Trust - Experimental or Standards Track 
> Justin, I initiated this thread because of the classification of the Vectors of Trust document[0] as “experimental". As weird as you suggest the IETF is, RFC2026 defines “experimental” designation as:4.2.1  Experimental
> 
> R&D is not the case with this draft given what is on track with NIST and OpenID Foundation.The OpenID Foundation iGov Working Group and apparently NIST are *currently* referencing this as a mandatory requirement for operational use rather then use exclusively in research and development, the classification is inappropriate. Specifically the iGov draft refers to the VoT as an IETF “standard”. The OpenID iGov draft was just voted to “implementation” status which means people are now implementing for production and NOT R&D. Regardless of the differences in terms, iGov is intended to be a standard while VoT is currently not.[1]I understand new SP-800-63 regulations are being developed that will use this “standard”.[2]
> [0] https://tools.ietf.org/html/draft-richer-vectors-of-trust-05[1] https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/igov/raw/master/openid-igov-profile.xml#rfc.section.3.4[2] https://github.com/usnistgov/800-63-3/blob/volume-d/sp800-63d/vot_mapping.md
> Thanks clearing this up.
> 
> Phil
> Oracle Corporation, Identity Cloud Services [email-masked]@oracle.com
> 
>