[Openid-specs-igov] Regarding the vote on Implementer’s Drafts of Two iGov Specifications
John Bradley
ve7jtb at ve7jtb.com
Mon Sep 11 18:20:41 UTC 2017
NIST is responsible for NIST standards and is mappoing SP800-63-3 to VOT.
I am guessing there will be multiple profiles of VOT.
Yes in the next version we should be more careful about using the term standard. Outside the IETF anything with a RFC number tends to get refers to as a standard.
We should really be talking about profiles of VOT rather than VOT.
I am not opposed to changing the track for VOT, it dosent necessarily need to be in a WG to be standards track.
I agree that to communicate the NIST defined vectors we need something other than Authentication Context Class Reference (ACR), that is probably why NIST is profiling VOT.
IGov can’t ignore what NIST is doing, even if VOT is an experimental ID.
In another thread Justin sent you a link to the section of SP-800-63-3 part D relating to the VOT mapping.
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>
I think this shows that people can profile VOT. That is one of the things the document shepherd has been looking for existence proofs of before advancing the ID to the IESG.
I recommend that you join the next iGov call and we can hash out your concerns.
John B,
> On Sep 11, 2017, at 1:12 PM, Phil Hunt <phil.hunt at oracle.com> wrote:
>
> John,
>
> Since you mention it, this quote from RFC2026 is why I think iGov cannot move forward as written with a normative requirement on VoT:
>> 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.
>
> From the iGov specification:
>> 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> Vectors of Trust <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#vot>
>> Servers MUST check for the presence of the vtr parameter before acr in Requests. If both parameters are present the server will default to vtr as the request to respond to. acr MUST then be ignored.
>>
>> OpenID Providers MAY provide the vot and contain valid values from the Vectors of Trust <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#I-D.richer-vectors-of-trust> standard.
>>
>> The vtr and contain valid values from the Vectors of Trust <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#I-D.richer-vectors-of-trust> standard.
>>
>> It is out of scope of this document to determine how an organization maps their digital identity practices to valid VOT component values.
>>
>
> Curious that the language “Vectors of Trust standard” is used.
>
> Regarding the last sentence quoted above, I wonder what the point of section 3.4 and VoT is then. John, you mentioned that it was strongly profiled and mapped into the new 800-63-3 vectors (IAL, AAL, FAL). Where is this language?
>
> The resolution is one of the following:
> A. Under the IETF, see if the track can be changed back to standards with a WG (new or existing)
> B. Develop an OIDF specification and publish it under this WG.
>
> Finally I am not aware of any formal BoF announcements in either organization. I recall Justin’s presentation years ago at the OAuth WG and supported it in general. I was curious and still waiting to see how we achieve interop on LoA or the modern IAl, AAL, FAL. For example, does a federated assertion contain individual attribute IAL values as well as an authentication AAL?
>
> —> FWIW — the new 800-63-3 has a much simpler model that is fairly easy to map. The fundamental problem with 800-63 is that there is no methodology for exchanging that information. It can only be used in policy based fixed relationships. IOW, without VoT, a single IDP cannot vary IAL or AAL values per person.
>
> Phil
>
> Oracle Corporation, Identity Cloud Services Architect
> @independentid
> www.independentid.com <http://www.independentid.com/>phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>
>> On Sep 11, 2017, at 9:43 AM, John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>> wrote:
>>
>> I think Phil is referring to the IETF track that VOT is currently on per RFC2026
>> https://tools.ietf.org/html/rfc2026 <https://tools.ietf.org/html/rfc2026>
>>
>> VOT did have several BOFs as I recall but for whatever reason couldn’t justify a working group and no other working group was a good fit. The internet society was interested in it and a security AD agreed to sponsor it.
>>
>> The guidelines for AD sponsors drafts are https://www.ietf.org/iesg/statement/ad-sponsoring-docs.html <https://www.ietf.org/iesg/statement/ad-sponsoring-docs.html>
>>
>> The experimental status theoretically impacts the amount of review the IESG will do. In reality they all go through last call and IESG review.
>>
>> AD sponsors docs can be standards track.
>>
>> If I parse Phill correctly he would like the document to be standards track to provide the appropriate gravitas.
>>
>> This is not a group that can make those sorts of decisions but this group can provide feedback to the document shepherd and responsible AD.
>>
>> The current track is the fastest to get a RFC though makes as experimental.
>> Leif and I did discuss the Working group opption at the last IETF in Prague.
>> Doing that would slow things down perhaps by a year or more.
>>
>> I suppose the middle road would be to get out an experimental one, and then take that to a WG for refinement on the standards track.
>>
>> In Any event I get the feeling that Oracle would like more input.
>>
>> John B.
>>
>>> On Sep 11, 2017, at 12:00 PM, Grassi, Paul A. (Fed) <paul.grassi at nist.gov <mailto:paul.grassi at nist.gov>> wrote:
>>>
>>> iGov, among many goals, will serve as a single interop baseline for cross-border federation. It can do that without VOT. What it can’t do, is carry an interoperable assertion of assurance in it’s payload WITHOUT VOT. So, since iGov is not experimental, and needs VOT, I assert that VOT has graduated from experimental.
>>>
>>> From: Openid-specs-igov <openid-specs-igov-bounces at lists.openid.net <mailto:openid-specs-igov-bounces at lists.openid.net>> on behalf of "Phil Hunt (IDM) via Openid-specs-igov" <openid-specs-igov at lists.openid.net <mailto:openid-specs-igov at lists.openid.net>>
>>> Reply-To: "Phil Hunt (IDM)" <phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>>
>>> Date: Monday, September 11, 2017 at 11:07 AM
>>> To: John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>>
>>> Cc: "openid-specs-igov at lists.openid.net <mailto:openid-specs-igov at lists.openid.net>" <openid-specs-igov at lists.openid.net <mailto:openid-specs-igov at lists.openid.net>>
>>> Subject: Re: [Openid-specs-igov] Fwd: Regarding the vote on Implementer’s Drafts of Two iGov Specifications
>>>
>>> The VoT spec is also experimental.
>>>
>>> Having a normative dependence on an experimental spec creates instability and devalues this spec. Or is the intent that igov be experimental?
>>>
>>> Phil
>>>
>>> On Sep 11, 2017, at 4:48 AM, John Bradley via Openid-specs-igov <openid-specs-igov at lists.openid.net <mailto:openid-specs-igov at lists.openid.net>> wrote:
>>>
>>>> Forwarding a comment on the vote.
>>>>
>>>> It is not uncommon for OIDF implimentors drafts to have dependencies on ID. As it is not uncommon for IETF WG specs to reference other drafts.
>>>>
>>>> Strictly speaking vot is a AD sponsors draft so not the same status as a Individual Draft. Yes the IETF has mysterious ways.
>>>>
>>>> To discuss the IETF process and that document the SAG list is best.
>>>>
>>>> The iGov WG has had extensive conversations with NIST and the UK and included VOT at there request. NIST is working on a profile of VOT.
>>>>
>>>> People interested in the iGov discussion with NIST should join the WG.
>>>>
>>>> As document Sheppard I have been talking to NIST and others about there ability to profile VOT. Getting feedback on that is one of the reasons vot has not been progressed to the IESG yet. That will however happening soon, unless more feedback is received in the IETF process.
>>>>
>>>> Honestly the more feedback the better. Sometimes it takes specs referencing important work like VOT before people become aware of them.
>>>>
>>>> I don't think we have a issue with the iGov implimentors draft, but others can differ.
>>>>
>>>> Regards
>>>> John B.
>>>> ---------- Forwarded message ----------
>>>> From: "Prateek Mishra" <Prateek.Mishra at oracle.com <mailto:Prateek.Mishra at oracle.com>>
>>>> Date: Sep 11, 2017 00:44
>>>> Subject: Fwd: Regarding the vote on Implementer’s Drafts of Two iGov Specifications
>>>> To: "John Bradley" <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>>, "Phil Hunt (IDM)" <phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>>
>>>> Cc:
>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Begin forwarded message:
>>>>>>
>>>>>> From: Prateek Mishra <Prateek.Mishra at oracle.com <mailto:Prateek.Mishra at oracle.com>>
>>>>>> Subject: Regarding the vote on Implementer’s Drafts of Two iGov Specifications
>>>>>> Date: September 10, 2017 at 10:42:35 PM PDT
>>>>>> To: openid-specs-igov at lists.openid.net <mailto:openid-specs-igov at lists.openid.net>
>>>>>>
>>>>>> The document has a normative reference to a Vectors of Trust “standard”. The so called normative reference is an individual draft and has no standing at this time.
>>>>>>
>>>>>> The draft https://tools.ietf.org/html/draft-richer-vectors-of-trust-05 <https://tools.ietf.org/html/draft-richer-vectors-of-trust-05> has been somewhat updated to reflect NIST 800-63-3’s new components, but does not align.
>>>>>>
>>>>>> We have voted “OBJECT” on this draft and would like to see this worked through first.
>>>>>>
>>>>>> — prateek
>>>>>>
>>>>>
>>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-igov/attachments/20170911/6feca898/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4383 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-igov/attachments/20170911/6feca898/attachment-0001.p7s>
More information about the Openid-specs-igov
mailing list