[Openid-specs-igov] Vectors of Trust - where to discuss?

Mon Sep 11 22:52:50 UTC 2017

Phll this wasn't sent to is not the iGov WG list.so I added the list to get it into the record.

Phil many of your comments about business logic applies both to VOT and ACR.  Yes that needs to be specified.
Glad you are interested in working on it.

FYI there is a IETF VOT mailing list. https://www.ietf.org/mailman/listinfo/vot <https://www.ietf.org/mailman/listinfo/vot> 
It could be used more but there is some traffic.

VOT uses the “vim” claim value for a URI to define what the trust framework is and if the IdP is registered to make assertions using that trust framework.

If a given RP doesn’t support VOT or a given trust mark then it should ent include that in its request and fall beck to ACR.
If a RP/client dosen't specify VOT in its request then it can ignore VOT in the response.
If a IdP doesn’t support VOT then it can ignore it and fall back to ACR.

Now for some federations the ACR values may or may not be defined or be defined for some subset of VOT combinations.
Your milage may very in that case.

Yes the business logic needs to be specified around if a hard error is returned or a lower or different value can be returned etc.  All the same issues we have with ACR.

So yes it needs to be fleshed out more.

iGov should not define the trust frameworks only the processing rules around how to deal with the requests and responses from the protocol perspective.  

The implementors draft vote was a trick to get you to read it, and not the final version.

John B.

> On Sep 11, 2017, at 4:39 PM, Phil Hunt <phil.hunt at oracle.com> wrote:
> 
> Paul,
> 
> In response to your comment (and this is really iGov related)….
> The iGov spec says…
>> 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.
> 
> Optionality for the OP/IDP is not optional for the RP/Client.
> 
> This text is unclear as to what the client is supposed to do if it gets a “vtr”.  What does “default” mean? It is clear that “acr” MUST be ignored.
> 
> The spec is unclear about what an iGov compliant client that does not support “vtr" can proceed. It does not say why it must ignore the acr if vtr is present.  Remember, in the absence of NIST, a server can easily understand both “acr” and “vtr” through it cannot attach meaning to the “vtr” without the NIST guidelines. What does a server in europe or any other jurisdiction do?
> 
> On VoT itself, is it true that *all* claims must be proofed to the same level?  From the VoT draft:
>>    The Identity Proofing dimension defines, overall, how strongly the
>>    set of identity attributes have been verified and vetted.  In other
>>    words, this dimension describes how likely it is that a given digital
>>    identity transaction corresponds to a particular (real-world)
>>    identity subject.
> 
> What if eye-color or a professional qualification is self asserted(P1) but the name and identifier is P3?   What does the OP do, must it:
> * only assert claims that meet P3?
> * assert P1 as the lowest quality denominator
> 
> It may be perfectly reasonable to accept an unverified claim of post-secondary education as good enough (e.g. for employment purposes), but if that claim then gets exported as P3 as evidence that the person is qualified (e.g. as a doctor) then that would be a mistake.  
> —> I see no guidances on how to handle varying quality of claims.  This seems important because almost no system that gathers claims does so to the same degree regarding every claim.
> 
> I don’t see any guidance on this in the VoT draft.
> 
> 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 12:49 PM, Grassi, Paul A. (Fed) <paul.grassi at nist.gov <mailto:paul.grassi at nist.gov>> wrote:
>> 
>> No it's not. We allow good old fashion acr. 
>> 
>> Sent from my iPhone
>> 
>> On Sep 11, 2017, at 3:33 PM, Phil Hunt (IDM) <phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>> wrote:
>> 
>>> But then igov is not implementable without regional profiling such as from NIST because VoT is mandatory. 
>>> 
>>> Phil
>>> 
>>> On Sep 11, 2017, at 12:30 PM, Anthony Nadalin <tonynad at microsoft.com <mailto:tonynad at microsoft.com>> wrote:
>>> 
>>>> I totally agree with John, these need to be separated and iGov not cover VOT
>>>>   <>
>>>> From: John Bradley [mailto:ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>] 
>>>> Sent: Monday, September 11, 2017 11:01 AM
>>>> To: Phil Hunt <phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>>
>>>> Cc: Kathleen Moriarty <kathleen.moriarty.ietf at gmail.com <mailto:kathleen.moriarty.ietf at gmail.com>>; PRATEEK MISHRA <prateek.mishra at oracle.com <mailto:prateek.mishra at oracle.com>>; Anthony Nadalin <tonynad at microsoft.com <mailto:tonynad at microsoft.com>>; Justin Richer <ietf at justin.richer.org <mailto:ietf at justin.richer.org>>; Paul Grassi <paul.grassi at nist.gov <mailto:paul.grassi at nist.gov>>; leif Johansson <leifj at sunet.se <mailto:leifj at sunet.se>>
>>>> Subject: Re: Vectors of Trust - where to discuss?
>>>>  
>>>> Adding PAul Grassi from NIST.  Because I like to spread the joy.
>>>>  
>>>> To be clear I atleast intended to say NIST is profiling VOT for SP800-63-3 not iGov.   
>>>> I believe that will be section D of SP800-63-3.
>>>>  
>>>> The particular VOT values would be defined there.   I don’t think they belong in the generic iGov doc.   
>>>>  
>>>> France might have a different profile of VoT not that I encourage that, but the iGov docs should not be US specific.
>>>>  
>>>> The iGov spec is saying that if VOT is sent that should be used in preference to ACR if that is sent as well.
>>>>  
>>>> I agree the wording should be clearer about using VOT profiles defined by organizations like NIST or whoever else wants to define them as we have for ACR in the IANA registry.  We may need some sort of IANA registry for these like we have for ACR.
>>>>  
>>>> The iGov working group has already started on a new draft based on feedback during the vote (people wait to after the public review to comment for some reason).   Please get involved and contribute wording if you don’t like that section.
>>>>  
>>>> We should probably try and keep the iGov, NIST VOT profile, and IETF track discussions a bit separate.
>>>>  
>>>> John B.
>>>>  
>>>> On Sep 11, 2017, at 1:44 PM, Phil Hunt <phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>> wrote:
>>>>  
>>>> John,
>>>>  
>>>> Regarding your comment that the IGov group has profiled the mapping of 800-63 IAL,AAL,FAL  to VoT (which you suggested exists below).  I only find the one paragraph as follows:
>>>> 3.4. <https://urldefense.proofpoint.com/v2/url?u=https-3A__xml2rfc.tools.ietf.org_cgi-2Dbin_xml2rfc.cgi-3FSubmit-3DSubmit-26format-3Dascii-26mode-3Dhtml-26type-3Dascii-26url-3Dhttps-3A__bitbucket.org_openid_igov_raw_master_openid-2Digov-2Dprofile.xml-23rfc.section.3.4&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=I67W8OuE8UmEujfQMXuvjnuTNeHphioHLV2RQVoLRJo&s=eFp2OE8xktxoihGrhcWVJ7ErNqFsFDGFkYIhnzl1IGM&e=> Vectors of Trust <https://urldefense.proofpoint.com/v2/url?u=https-3A__xml2rfc.tools.ietf.org_cgi-2Dbin_xml2rfc.cgi-3FSubmit-3DSubmit-26format-3Dascii-26mode-3Dhtml-26type-3Dascii-26url-3Dhttps-3A__bitbucket.org_openid_igov_raw_master_openid-2Digov-2Dprofile.xml-23vot&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=I67W8OuE8UmEujfQMXuvjnuTNeHphioHLV2RQVoLRJo&s=AQD2AIkbYLlRnUd8e56hpzzkGTqTQ0Li3xUpijsvdWA&e=>
>>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__xml2rfc.tools.ietf.org_cgi-2Dbin_xml2rfc.cgi-3FSubmit-3DSubmit-26format-3Dascii-26mode-3Dhtml-26type-3Dascii-26url-3Dhttps-3A__bitbucket.org_openid_igov_raw_master_openid-2Digov-2Dprofile.xml-23I-2DD.richer-2Dvectors-2Dof-2Dtrust&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=I67W8OuE8UmEujfQMXuvjnuTNeHphioHLV2RQVoLRJo&s=LAUK3t8ZhiHqohhQsrlOOBKYmURp4rG9xVGfKEhjlmk&e=> standard. 
>>>> The vtr and contain valid values from the Vectors of Trust <https://urldefense.proofpoint.com/v2/url?u=https-3A__xml2rfc.tools.ietf.org_cgi-2Dbin_xml2rfc.cgi-3FSubmit-3DSubmit-26format-3Dascii-26mode-3Dhtml-26type-3Dascii-26url-3Dhttps-3A__bitbucket.org_openid_igov_raw_master_openid-2Digov-2Dprofile.xml-23I-2DD.richer-2Dvectors-2Dof-2Dtrust&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=I67W8OuE8UmEujfQMXuvjnuTNeHphioHLV2RQVoLRJo&s=LAUK3t8ZhiHqohhQsrlOOBKYmURp4rG9xVGfKEhjlmk&e=> standard. 
>>>> It is out of scope of this document to determine how an organization maps their digital identity practices to valid VOT component values.
>>>> This is not a research and development use of VoT.  Further the spec itself doesn’t give useful information to implementers to make use of or implement VoT. As such I have sent my feedback to the iGov list.
>>>>  
>>>> As written, neither spec is actually implementable unless customer orgs give specific one-off requirements.  Which is hardly the point of a standard is it?
>>>>  
>>>> Phil
>>>>  
>>>> Oracle Corporation, Identity Cloud Services Architect
>>>> @independentid
>>>> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=I67W8OuE8UmEujfQMXuvjnuTNeHphioHLV2RQVoLRJo&s=EZxGffxgFd1WyPV1_pqDnOqn1DbNccBDD2rcLe9MBHU&e=>
>>>> phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>
>>>>  
>>>> On Sep 10, 2017, at 2:44 PM, John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>> wrote:
>>>>  
>>>> There is discussion on mapping SP800-63 to Vectors of trust happening in the iGov working group at the OIDF and at NIST for section D of SP-800-63-3.  
>>>>  
>>>> It is not anticipated that changes are required to the spec.  The Vectors in the spec are examples.   
>>>>  
>>>> They are intended to apply to a assertion but someone could apply them to individual claims I suppose.   The NIST claim schema work is also going to iGov.  We haven't discussed the relationship between the two yet.  
>>>>  
>>>> Leif and I have talked about the possibility of a IETF operations WG that VOT might fit into.  
>>>>  
>>>> For the moment the VOT draft is AD sponsors as experimental.   For the moment comments should go to the authors and the document Sheppard.  
>>>>  
>>>> John B.  
>>>>  
>>>>  
>>>>  
>>>> On Sep 10, 2017 17:13, "Phil Hunt" <phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>> wrote:
>>>> Kathleen/Justin,
>>>>  
>>>> I see on the tracker (https://datatracker.ietf.org/doc/draft-richer-vectors-of-trust/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dricher-2Dvectors-2Dof-2Dtrust_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=I67W8OuE8UmEujfQMXuvjnuTNeHphioHLV2RQVoLRJo&s=HnX47aB7H65DDQ5ItuDtwI9fRf9R3qP8BtnNL3Tin04&e=>) this document is not part of any working group.
>>>>  
>>>> The OpenID Foundation is moving to implementation status on a spec that uses this as as “standard”.  Yet the tracker indicates the intent is “experimental” and it has not been reviewed. It remains an individual draft.
>>>>  
>>>> I have concerns that the document has not been updated to reflect new approaches published in NIST 800-63-3 and which are also being discussed for alignment in the ISO 29115.
>>>>  
>>>> General questions:
>>>>  
>>>> Do vectors apply to an assertion or an individual claim?  How in JWT should Identity Proofing Levels (IAL) be expressed?  On a per-claim basis?
>>>>  
>>>> If the vector is contained within a federated assertion (rated FAL1-3) should the vector include the containers rating?
>>>>  
>>>> What about composite cases where there are multiple layers of federation and attribute sources.
>>>>  
>>>> What is the appropriate way to comment and discuss here?
>>>>  
>>>> Are there special considerations for zero knowledge proof/privacy systems such as SOVRIN distributed ledgers?
>>>>  
>>>> Thanks,
>>>>  
>>>> Phil
>>>>  
>>>> Oracle Corporation, Identity Cloud Services Architect
>>>> @independentid
>>>> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=I67W8OuE8UmEujfQMXuvjnuTNeHphioHLV2RQVoLRJo&s=EZxGffxgFd1WyPV1_pqDnOqn1DbNccBDD2rcLe9MBHU&e=>
>>>> phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-igov/attachments/20170911/3fe6a72c/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/3fe6a72c/attachment-0001.p7s>