Subject: [VoT] In support of Justin

From: Joanne Knight <[email-masked]>
Date: Mon, 17 Nov 2014 20:47:44 +0000

Thank you Justin for expressing so well the conclusion that I have also come to.

Rendering the {n:n:n:n} to a single scalar has very limited application and tells a somewhat misleading story.

I am also of a mind that each scale of values for each of the fields in {n:n:n:n} may potentially be different. The identity proofing field, which I am working on for ISO/IEC 29003 currently has 1,2,3a,3b and 4. Whether we will be able to produce a hierarchy between 3a and 3b is yet to be seen, but this would result in a scale of 5. Once I have refined it a little more I hope to be able to circulate it for your thoughts and debate. 

Presentation as  {n:n:n:n} will allow scales that are fit for purpose rather than shaped by the proverbial cookie cutter.

Vot digest is currently my favourite read - thanks all

Joanne

-----Original Message-----
From: Richer, Justin P. [mailto:[email-masked]] 
Sent: Tuesday, 18 November 2014 8:34 a.m.
To: Cantor, Scott
Cc: Colin Wallis; [email-masked]
Subject: Re: [VoT] vot Digest, Vol 3, Issue 11

One important note about the mapping, to either 800-63 or any other trust construction:

I think it's vitally important that we do *not* collapse the values before they hit the RP. It's up to the RP (and its attendant policy engines) to make sense of {1:3:4:1} in its own context. As nat points out, the RP might decide that {1:3:4:1} and {4:3:1:2} are equivalent because all it cares about, for its purposes, are the the "3" value in the second field. And maybe it doesn't want a "0" in the first column, but the other two don't matter. Or maybe it only believes a "4" in the first column from a single provider that it knows about through a contractual relationship. I don't think we're doing any favors of trying to prematurely project these vectors of values back into single scalars, which has been called for a few times. 

I think this is an artifact of thinking of this in terms of a "new way to define LOA". Instead, what we're looking at is an alternative expression mechanism. Something that's more expressive than LoA 1-4, but not at the complexity level of an arbitrary set of attributes being tossed about. 

Where the mapping does make sense is in the context of some kind of trust framework, which can determine which vectors map to which things within the trust framework. This would further simplify the processing for the RP, but it is important that the IdP would communicate to the RP in un-mapped format. This will, I believe, help us avoid "LoA 2.5" because now the definition of LoA or its equivalent are properly in the hands of the party making the final decision: the RP. 

But that said, I still don't want to necessarily define that mapping here in this group, as I think it's premature at best and a disservice without context at worst. I'm not going to try to stand in the way of people who want to do that, but it's not what we're after here. 

 -- Justin

On Nov 12, 2014, at 4:47 PM, Cantor, Scott <[email-masked]> wrote:

> On 11/12/14, 9:29 PM, "Colin Wallis" <[email-masked]> wrote:
> 
>> There was no intention to create something else that could map to 800-63.
>> The intention was to brainstorm some ideas on alternative constructs 
>> to 800-63.
> 
> I think some people feel there's value in being able to do that 
> mapping, and I won't try to dissuade them, though I'm not among them.
> 
> -- Scott
> 
> _______________________________________________
> vot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vot