Subject: [VoT] Three things...

From: Robin Wilton <[email-masked]>
Date: Wed, 12 Nov 2014 12:16:03 +0000

> 
> From: Joanne Knight <[email-masked]>
> Subject: Re: [VoT] vot Digest, Vol 3, Issue 3
> Date: 12 November 2014 04:04:29 GMT
> To: 'Jim Fenton' <[email-masked]>, 'Peter Alterman' <[email-masked]>, 'Nat Sakimura' <[email-masked]>
> Cc: "[email-masked]'" <[email-masked]>
> 
> 
> Greetings All
>  
> I am new to this group so for the benefit of those who do not know me…
>  
> I am Joanne Knight (probably the real me but not what you will find on any official register) ;-)

Hi Joanne, and welcome. Unless “Joanne Knight” is actually another of Colin Wallis’ personas, in which case, nice try and welcome back.

> 
>  
>  
>  
> From: Jim Fenton [mailto:[email-masked]] 
> Sent: Wednesday, 12 November 2014 1:01 p.m.
> To: Peter Alterman; Nat Sakimura
> Cc: [email-masked]
> Subject: Re: [VoT] vot Digest, Vol 3, Issue 3
>  
> Peter,
> 
> 
> Finally, it sounds like we're talking past each other on the word "vector". We're using the word in the mathematical sense, and it appears you're using it in the epidemiological sense. If there's a word here I have a quibble about, it's "trust”.

IIRC, Leif has already made the point that “vector” was chosen more or less on the spur of the moment during the Utrecht workshop; looking at the kinds of thing people are grouping under that term, it feels to me (as to Peter) that “factor” would serve as well. I know that’s not very helpful now that the mailing list already has a V in it, sorry.

Unless I misunderstand it, we are talking about “the things that contribute, positively or negatively, to the trustworthiness of an identity assertion”. This also relates partly to a further comment, below, on something Peter said.

> 
> On 11/11/14 3:09 PM, Peter Alterman wrote:
> Nat et. al.
>  
> Let's not reason backwards from use cases but forwards from expertise. There are a zillion use cases out there that can be generated for any model (sort of like a cost/benefit analysis - just tell the analyst what answer you want and let him/her crank out the sausage). Rather, what are the legitimate components of an identity assertion; what's the nature of the relationship among them? Nothing I've seen so far changes my opinion that there are four variables: strength of identity proofing (measured against a benchmark that incorporates *both* 800-63 and 29115); intrinsic resistance of credential type to attack (see prior benchmarking comment); credential management (how well it addresses the threat vectors in 29115 and aligns with 800-63 processes, and exchange, which incorporates mitigation of data in motion threat vectors listed in 29115 relevant to AuthN. 
>  
>  Also agree that the AuthN process is not part of determining the trustworthiness (rat hole warning) of an online identity assertion but the process of making such a determination.

I mostly agree, but I think that the lifecycle of a credential gives us a good basis for drawing up a shortlist of the things that make the resulting assertions of identity trustworthy. If you do, you get a very similar list to the one Nat mentions, and phases that reflect Joanne’s comments too.

the initial registration/verification/enrolment phase ("proofing")
the issue of credentials (encapsulating attributes and binding the result to the individual somehow)
presentation of the credentials over time
validation of the credentials (a.k.a. Authentication) 
other lifecycle bits like revocation/amendment/destruction

(Nat makes the point, below, that most RPs don’t care about identity proofing. I’m sure he is right, but since we’re trying to tease out all the things that underpin the reliability of an identity assertion, I think we need to be more explicit; RPs don’t care because they will assume either that proofing has been done adequately, or that if they rely on a valid credential that has been incorrectly issued, the liability will rest with the issuer. But I’d argue that those are trust factors too.)

Last: I’m worried that Peter’s final sentence above is open to misinterpretation. If any of the phases I’ve just listed is not reliable, it undermines trust in the outcome (which is, ideally, justified reliance on an assertion of identity). If the authentication step is trivial, cursory, superficial, spoofable, insecure, call it what you will - then someone relying on its outcome could be mistaken.

>  
> Finally, scalar is not vector. C'mon guys, give an old man a break. We're talking factors, not vectors. As an example, a threat vector is an identity assertion threat aimed at someone or some process: it has strength and it has direction.
>  
> regards,
>  
> Peter
>  
> 
> ------------------------------------------------------------
> Peter Alterman, Ph.D.
> Chief Operating Officer
> SAFE-BioPharma Association
> cell: 301-943-7452
> 
>  
> On Tue, Nov 11, 2014 at 5:28 PM, Nat Sakimura <[email-masked]> wrote:
> In many cases, people do not care about Identity Proofing. As long as the credential management and after is done right, it should not matter in many commercial use case. So, in the previous expression, to some of my use cases, I am indifferent with (1, 2, 2, 2) and (4, 2, 2, 2). In the traditional SP800-63 case, however, the former is 0 and later is 2, making (1, 2, 2, 2) and (1, 1, 1, 1) indifferent, losing the information I was interested in. Also, I may want to accept (1,2,2,1) on a intranet while I am only willing to accept (1,2,2,2) over the internet. Justin was arguing to collapse the middle two, and that may well be a good simplification. In this case, I still care those three dimensions instead of four. 
>  
> As to the attribute reliability is concerned, the room concluded that it is out of scope for VoT for now, that we should only concentrate on entity authentication assurance. The quality of attribute should be treated more like a metadata about each attribute instead. 
>  
> For the Enrollment, Credential Management, Authentication, refer to ISO/IEC 29115 or ITU-T X.1254, which are almost identical apart from the formatting and 3 words. X.1254 is freely available. You can find them here: https://www.itu.int/rec/T-REC-X.1254-201209-I/en
>  
> Nat
>  
>  
> On Wed Nov 12 2014 at 6:53:11 Jim Fenton <[email-masked]> wrote:
> One of the requirements should be that there be only as many dimensions to the vector as would be actionable by a Relying Party to make an authorization decision. Otherwise, the model is more complex than it needs to be.
> 
> I'm not sure I understand how Enrollment, Credential Management, Authentication, and Assertion Transmission are defined (if that was discussed on the list, I'd appreciate a pointer to it). But as a relying party, if the quality of an attribute I receive is limited by something, I probably don't care whether it was because the credential management or the assertion transmission was the cause.
> 
> So if this retains 4 dimensions, there should be use cases that justify the need for 4. I can do that for 2 dimensions (authentication strength/attribute reliability) by considering uses like strong pseudonymous authentication with a trustable assertion of an attribute like age. I don't have any good examples for more than 2.
> 
> 
> -Jim
> 
> 
> On 11/11/14 1:34 PM, Nat Sakimura wrote:
> We had a bar-bof last night at IETF 91. 
> 
> There was a discussion that perhaps instead of three dimension "Identity Proofing / Credential Binding / Assertion Transmission", perhaps 4 dimension "Enrollment/Credential management/Authentication/Assertion Transmission" is more appropriate. The reason was that Identity Proofing is only a step in Enrollment, Credential Binding is only a step in Credential Management, and the use of credential, i.e., Authentication, is important enough to separate out from Credential Management. Then, there followed a lengthy discussion about whether to pull Authentication out. 
>  
> As to the "vector" is concerned, it indeed seem to be a vector to me in the sense that: 
>  
> v = (e, c, a, t) 
>  where e:=scalar value for expressing Enrollment quality
>  c:=scalar value for expressing Credential Management quality
>  a:=scalar value for expressing Authentication quality
>  t:=scalar value for expressing Assertion Transmission quality. 
>  
> There was discussion on how to obtain these values as well. The room opinion was that we should define the response format and then use it to define the request format. 
>  
> Also, there was a discussion around the nature of the value of each scalar above, and the granularity desired. 
> We were not even sure if the values are going to be an ordered set. Everybody agreed that simplicity is a requirement for widespread adoption. If granularity were sought, then it should be defined as a subset of parent value so that implementation that do not care about these can safely ignore them. 
>  
> Apart from the above, importance of the operational quality of IdPs were expressed. This seem to be the quality which should be transmitted not per authentication transaction but separately, perhaps from .well-known resource. 
>  
> FYI, the room also had the opinion that we should not get into the "quality of attributes" in general but focus only to the entity authentication, at least for this round. 
>  
> Cheers, 
>  
> Nat
>  
>  
>  
>  
> On Wed Nov 12 2014 at 5:25:56 Peter Alterman <[email-masked]> wrote:
> Pardon me not diddling with the strawman. A quick read generated the comments following. Hope they are helpful in evolving the document.
>  
> What is immediately missing is a value for the quality of the credential technology because some credential types are inherently less secure - or risk mitigating - than others. 
>  
> My second observation is that it is not yet clear to me why these elements are called vectors. Vectors are expressions of quantities in spacio-temporal directions. So far I see three (and the fourth I recommend here) factors. In order to consider them vectors, please show me a plot on a graph and label the axes and the measurement units.
>  
> My third observation is that I do not see any straightforward way for the factors to be collapsed. There are no approaches to do so presented, either. First question to ask here is whether the ecosystem will need to deploy both a transmission protocol and a receiving protocol? If the methodology requires broad uptake of RP software in order to decode the transmitted factors, the Hydra is unleashed.
>  
> thanks,
>  
> Peter
> 
> ------------------------------------------------------------
> Peter Alterman, Ph.D.
> Chief Operating Officer
> SAFE-BioPharma Association
> cell: 301-943-7452
> 
>  
> On Tue, Nov 11, 2014 at 3:02 PM, <[email-masked]> wrote:
> Send vot mailing list submissions to
>         [email-masked]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/vot
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
> 
> You can reach the person managing the list at
>         [email-masked]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of vot digest..."
> 
> Today's Topics:
> 
>    1. Document in GitHub (Richer, Justin P.)
> 
> 
> ---------- Forwarded message ----------
> From: "Richer, Justin P." <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: 
> Date: Mon, 10 Nov 2014 21:07:53 +0000
> Subject: [VoT] Document in GitHub
> I've started the work of translating much of my original strawman document to Markdown and pushing it to GitHub so that we can start taking edits via pull request:
> 
>   https://github.com/vectorsoftrust/strawman/blob/master/VectorsOfTrust.md
> 
> Clone and fork away!
> 
>  -- Justin
> 
> 
> _______________________________________________
> vot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vot
> 
>  
> _______________________________________________
> vot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vot
> 
> 
> _______________________________________________
> vot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vot
>  
>  
> 
> 
> 
> _______________________________________________
> vot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vot
>  
> 
> 
> _______________________________________________
> vot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vot