Subject: Re: [VoT] vot Digest, Vol 3, Issue 11

From: Peter Alterman <[email-masked]>
Date: Wed, 12 Nov 2014 10:55:37 -0500

Hi Joanne. Thanks for the shout out.

Here are a few thoughts on the various comments I read over morning coffee:
first, I use vector in the Physics 101 sense, Nat, but I will now leave
this annoyance behind and allow you the terminology you feel comfortable
using. (Yes, before I got all these pesky literature degrees I majored in
physics and even attended lectures on chirality by C.N. Yang.)

Next, before addressing the quite legitimate question of what we mean by
extended attributes, etc., we must resist reinventing/re-conceiving
operational models. In principle the set of attributes required by a RP may
vary from case to case but there already exists a vast operating ecosystem
that has already determined what that set of attributes is and how to deal
with it. I resist any attempt to fiddle with that, while I am open to new,
useful, practical ways to measure identity attributes and to express them.
Many use cases care not a whit for this set, many will want others, as Nat
has described (I agree we are in that strange window of argumentative
mutual agreement). Currently, this is handled on a
relationship-by-relationship basis with attributes that are not included in
the generic identity attribute set or which are included but ignored by a
general-purpose AuthN process. Extended attributes are the kitchen sink of
online AuthN + AuthZ and they can consist of any unit of data about a
natural person or a thing. To avoid the rat hole, simply accept the fact
that there is a widely-used set of personal (or machine or code) attributes
generally accepted as identity-asserting attributes and move on. Other
attributes simply add to the utility of the online identity assertion and
beg a universal method of expression.

+1 on the comment that RPs may have little or no interest in an online
identity assertion reliability rating of {3:1:2:4}. This is, to me, the
place where the theoretical crosses the line to useless. The social domain
cares less than nothing about any of this, the e-commerce domain cares
about the history of my credit card account paying for things bought
online, governments and financial institutions need high assurances of
identity addressed by ETSI QCP and Fed PKI and FICAM. While I do appreciate
the work that GTRI has done under grant from NSTIC to decompose AuthN, I
think it results in a conceptual model that doesn't align with the needs of
the real world. Now, show me a way to collapse {3:1:2:4} into something an
e-commerce or e-gov RP can use and I'm all on board. Preferably using
existing tools such as SAML, XACML, WS-Fed, etc.

Finally, regarding use cases: I thank you Jim for your desire to simplify
all this. I believe that use cases are valuable to test models, not to
build them. Too often they are misused for the latter, not the former, IMO,
and that leads to destructive stuff like a health care group lobbying NIST
to define an LOA of 2.5 to satisfy the use cases they created. That's all I
am saying.

regards,

Peter

------------------------------------------------------------
Peter Alterman, Ph.D.
Chief Operating Officer
SAFE-BioPharma Association
cell: 301-943-7452

On Wed, Nov 12, 2014 at 7:16 AM, <[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. Re: vot Digest, Vol 3, Issue 3 (Nat Sakimura)
>    2. Three things... (Robin Wilton)
>
>
> ---------- Forwarded message ----------
> From: Nat Sakimura <[email-masked]>
> To: "Jones, Mark B" <[email-masked]>, Jim Fenton <
> [email-masked]>, Peter Alterman <[email-masked]>, "
> [email-masked]" <[email-masked]>
> Cc:
> Date: Wed, 12 Nov 2014 07:59:42 +0000
> Subject: Re: [VoT] vot Digest, Vol 3, Issue 3
> IMHO, everybody here should read X.1254 - ISO/IEC 29115 as a starting
> point. It has got problems, but it still is a good starting point and we do
> not have to repeat arguing what are there without knowing them.
>
> In it, clause 10 lays out threats and controls. One of the biggest problem
> about the 29115 is that it is too prescriptive as to the controls are
> concerned. There can be multiple ways of implementing controls and there
> always are going to be new and more shiny ones. It should have been
> constructed like 27002 that everything is optional but has to achieve the
> objectives.
>
> (In fact, we did so for authentication phase, but other phases remained
> pretty prescriptive.)
>
> Nat
>
> On Wed Nov 12 2014 at 16:38:34 Jones, Mark B <[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.
>>
>> *[Jones, Mark B] *
>>
>> *Isn’t ‘authorization’ out of scope here?  The strawman document does not
>> mention authorization.*
>>
>
>
> ---------- Forwarded message ----------
> From: Robin Wilton <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc:
> Date: Wed, 12 Nov 2014 12:16:03 +0000
> Subject: [VoT] Three things...
>
>
> *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] <[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
>
>
>
> _______________________________________________
> vot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vot
>
>

---

From: Ken Dagg <[email-masked]>
Date: Wed, 12 Nov 2014 13:55:43 -0500

My thoughts on Peter's thoughts inline [[KD: thought]]. I agree fully with
what you said Peter. Ken

On Wednesday, November 12, 2014, Peter Alterman <
[email-masked]> wrote:

> [[KD: Here, here Peter. I am also not comfortable with the word but I too
> want to move beyond what it is called and focus on what it is trying to
> accomplish]] Here are a few thoughts on the various comments I read over
> morning coffee: first, I use vector in the Physics 101 sense, Nat, but I
> will now leave this annoyance behind and allow you the terminology you feel
> comfortable using. (Yes, before I got all these pesky literature degrees I
> majored in physics and even attended lectures on chirality by C.N. Yang.)
>
> [[KD: Again here, here. There are several operational environments that
> need to be accommodated ... rather than revolutionized. The RPs in those
> environments have already made their decisions regarding what attributes
> they need to mitigate their identity authentication requirements.]] Next,
> before addressing the quite legitimate question of what we mean by extended
> attributes, etc., we must resist reinventing/re-conceiving operational
> models. In principle the set of attributes required by a RP may vary from
> case to case but there already exists a vast operating ecosystem that has
> already determined what that set of attributes is and how to deal with it.
> I resist any attempt to fiddle with that, while I am open to new, useful,
> practical ways to measure identity attributes and to express them. Many use
> cases care not a whit for this set, many will want others, as Nat has
> described (I agree we are in that strange window of argumentative mutual
> agreement). Currently, this is handled on a relationship-by-relationship
> basis with attributes that are not included in the generic identity
> attribute set or which are included but ignored by a general-purpose AuthN
> process. Extended attributes are the kitchen sink of online AuthN + AuthZ
> and they can consist of any unit of data about a natural person or a thing.
> To avoid the rat hole, simply accept the fact that there is a widely-used
> set of personal (or machine or code) attributes generally accepted as
> identity-asserting attributes and move on. Other attributes simply add to
> the utility of the online identity assertion and beg a universal method of
> expression.
>
> [[KD: I too want to see a way to collapse {3:1:2:4} into something an
> existing tools such as SAML, XACML, WS-Fed, etc. this is in line with my
> "let's evolve rather than revolutionize. ]] +1 on the comment that RPs may
> have little or no interest in an online identity assertion reliability
> rating of {3:1:2:4}. This is, to me, the place where the theoretical
> crosses the line to useless. The social domain cares less than nothing
> about any of this, the e-commerce domain cares about the history of my
> credit card account paying for things bought online, governments and
> financial institutions need high assurances of identity addressed by ETSI
> QCP and Fed PKI and FICAM. While I do appreciate the work that GTRI has
> done under grant from NSTIC to decompose AuthN, I think it results in a
> conceptual model that doesn't align with the needs of the real world. Now,
> show me a way to collapse {3:1:2:4} into something an e-commerce or e-gov
> RP can use and I'm all on board. Preferably using existing tools such as
> SAML, XACML, WS-Fed, etc.
>
> [[KD: I agree fully Peter. Use cases have a place in testing models.
> ]] Finally, regarding use cases: I thank you Jim for your desire to
> simplify all this. I believe that use cases are valuable to test models,
> not to build them. Too often they are misused for the latter, not the
> former, IMO, and that leads to destructive stuff like a health care group
> lobbying NIST to define an LOA of 2.5 to satisfy the use cases they
> created. That's all I am saying.
>
> regards,
>
> Peter
>
>
> On Wed, Nov 12, 2014 at 7:16 AM, <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>>         [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>
>> From: Nat Sakimura <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> To: "Jones, Mark B" <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>, Jim Fenton <
>> [email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>, Peter
>> Alterman <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>, "
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>" <
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> Cc:
>> In it, clause 10 lays out threats and controls. One of the biggest
>> problem about the 29115 is that it is too prescriptive as to the controls
>> are concerned. There can be multiple ways of implementing controls and
>> there always are going to be new and more shiny ones. It should have been
>> On Wed Nov 12 2014 at 16:38:34 Jones, Mark B <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>
>>> *Isn’t ‘authorization’ out of scope here?  The strawman document does
>>> not mention authorization.*
>>>
>>
>>
>> From: Robin Wilton <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> To: "[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>" <
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> Cc:
>> *From: *Joanne Knight <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> *To: *'Jim Fenton' <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>, 'Peter
>> Alterman' <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>, 'Nat
>> Sakimura' <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> *Cc: *"[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>'" <
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>>
>>
>> Greetings All
>>
>> I am Joanne Knight (probably the real me but not what you will find on
>> any official register) ;-)
>>
>>
>> *From:* Jim Fenton [mailto:[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>]
>> *Cc:* [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> On Tue, Nov 11, 2014 at 5:28 PM, Nat Sakimura <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>> On Wed Nov 12 2014 at 6:53:11 Jim Fenton <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>> Also, there was a discussion around the nature of the value of each
>> scalar above, and the granularity desired.
>> On Wed Nov 12 2014 at 5:25:56 Peter Alterman <
>> [email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>> My second observation is that it is not yet clear to me why these
>> elements are called vectors. Vectors are expressions of quantities in
>> On Tue, Nov 11, 2014 at 3:02 PM, <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>
>>         [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>
>> From: "Richer, Justin P." <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> To: "[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>" <
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> Cc:
>> 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:
>>
>>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 12 Nov 2014 20:00:32 +0000

On 11/12/14, 3:55 PM, "Peter Alterman" <[email-masked]> 
wrote:
>build them. Too often they are misused for the latter, not the
> former, IMO, and that leads to destructive stuff like a health care 
>group lobbying NIST to define an LOA of 2.5 to satisfy the use cases they 

That's not destructive, that's just evidence that 800-63 is not the right 
basis for an assurance framework, because pretty much every group I've 
ever met with has reached the conclusion that their needs are met by none 
of the existing levels. Primarily because it hides important details and 
combines unrelated factors.

If people don't agree 800-63 is inadequate, they likely won't agree with 
any output of this conversation, whatever the result might be.

Use cases are where you generalize from. I am more of a generalizer than a 
lot of people are, but I don't go so far as to say that I don't start 
there.

-- Scott

---

From: Colin Wallis <[email-masked]>
Date: Wed, 12 Nov 2014 21:29:33 +0000

<<From Scott:  If people don't agree 800-63 is inadequate, they likely won't agree with any output of this conversation, whatever the result might be.>>

<<From Peter: ..... while I am open to new, useful, practical ways to measure identity attributes and to express them.>>

And that folks, was why this list was started.
I appreciate that that would be much clearer to people in the room in Utrecht than others who joined in later.
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.
Cheers
Colin

-----Original Message-----
From: vot [mailto:[email-masked]] On Behalf Of Cantor, Scott
Sent: Thursday, 13 November 2014 9:01 a.m.
To: Peter Alterman; [email-masked]
Subject: Re: [VoT] vot Digest, Vol 3, Issue 11

On 11/12/14, 3:55 PM, "Peter Alterman" <[email-masked]>
wrote:
>
>Finally, regarding use cases: I thank you Jim for your desire to 
>simplify all this. I believe that use cases are valuable to test 
>models, not to build them. Too often they are misused for the latter, 
>not the  former, IMO, and that leads to destructive stuff like a health 
>care group lobbying NIST to define an LOA of 2.5 to satisfy the use 
>cases they created. That's all I am saying.

That's not destructive, that's just evidence that 800-63 is not the right basis for an assurance framework, because pretty much every group I've ever met with has reached the conclusion that their needs are met by none of the existing levels. Primarily because it hides important details and combines unrelated factors.

If people don't agree 800-63 is inadequate, they likely won't agree with any output of this conversation, whatever the result might be.

Use cases are where you generalize from. I am more of a generalizer than a lot of people are, but I don't go so far as to say that I don't start there.

-- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 12 Nov 2014 21:47:09 +0000

>The intention was to brainstorm some ideas on alternative constructs to 

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

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 17 Nov 2014 19:34:27 +0000

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