[Openid-specs-igov] Regarding the vote on Implementer’s Drafts of Two iGov Specifications

[John Bradley]

The section of iGov that refers to VOT basically provides a processing rule that if you receive it then it overrides the ACR value.  The values are defined in external profiles such as the one NIST is working on:
https://github.com/usnistgov/800-63-3/blob/volume-d/sp800-63d/vot_mapping.md

In the NIST case it is string with three elements like a scopes in OAuth 2.

I do think we need to expand the processing rules for that.  What happens if you ask for IAL2 with AAL2 and FAL1, but the IdP can has only proofed the user to IAL 1?  Do you error or return the best you can do. 

If we use the VOT encoding or something else we should still address those issues.

John B.

> On Sep 11, 2017, at 12:24 PM, Mike Jones <michael.jones at microsoft.com> wrote:
> 
> Vectors of Trust (VoT) has always seemed like an unnecessarily complicated approach to me.  Multi-dimensional attributes reminds me of some the worst and least-used features of SAML.  If there’s a normative dependency upon it in iGov, in my view, it should be removed.
>  
>                                                        -- Mike
>   <>
> From: Openid-specs-igov [mailto:openid-specs-igov-bounces at lists.openid.net] On Behalf Of Grassi, Paul A. (Fed) via Openid-specs-igov
> Sent: Monday, September 11, 2017 9:01 AM
> To: Phil Hunt (IDM) <phil.hunt at oracle.com>; John Bradley <ve7jtb at ve7jtb.com>
> Cc: openid-specs-igov at lists.openid.net
> Subject: Re: [Openid-specs-igov] Fwd: Regarding the vote on Implementer’s Drafts of Two iGov Specifications
>  
> 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/36912121/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/36912121/attachment-0001.p7s>