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

From: Peter Alterman <[email-masked]>
Date: Tue, 11 Nov 2014 15:25:30 -0500

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
>
>

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 11 Nov 2014 21:34:59 +0000

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:

>> 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:
>>
>>

---

From: Jim Fenton <[email-masked]>
Date: Tue, 11 Nov 2014 13:53:08 -0800

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:
> 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
> As to the "vector" is concerned, it indeed seem to be a vector to me
> in the sense that: 
>
> *v* = (e, c, a, t) 
> 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. 
> 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] <mailto:[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
>
>     On Tue, Nov 11, 2014 at 3:02 PM, <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>                 [email-masked] <mailto:[email-masked]>
>
>                 [email-masked] <mailto:[email-masked]>
>
>                 [email-masked] <mailto:[email-masked]>
>
>         From: "Richer, Justin P." <[email-masked]
>         <mailto:[email-masked]>>
>         To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
>         <mailto:[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] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 11 Nov 2014 22:28:30 +0000

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:

> authorization decision. Otherwise, the model is more complex than it needs
> to be.
>
> 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.
>
> pseudonymous authentication with a trustable assertion of an attribute like
> age. I don't have any good examples for more than 2.
>
>
> -Jim
>
>
>  As to the "vector" is concerned, it indeed seem to be a vector to me in
> the sense that:
>
>  *v* = (e, c, a, t)
>> credential technology because some credential types are inherently less
>> secure - or risk mitigating - than others.
>>
>> elements are called vectors. Vectors are expressions of quantities in
>>  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,
> vot mailing [email-masked]://www.ietf.org/mailman/listinfo/vot
>
>
>

---

From: Peter Alterman <[email-masked]>
Date: Tue, 11 Nov 2014 18:09:29 -0500

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.

I fear there is a fair amount of rat hole diving in process, and I'm urging
a pragmatic eye here. Strongly support putting off any discussion of
extended attributes until this particular effort has been completed. No
further work on attributes should go forward without benchmarking the
myriad efforts in that arena in the past 3 years so we don't reinvent any
wheels or redefine the meaning of "round." 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.

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

On Tue, Nov 11, 2014 at 5:28 PM, Nat Sakimura <[email-masked]> wrote:

> 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
> 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:
>> were expressed. This seem to be the quality which should be transmitted not
>> per authentication transaction but separately, perhaps from .well-known
>> resource.
>>
>> On Wed Nov 12 2014 at 5:25:56 Peter Alterman <
>> [email-masked]> wrote:
>>

---

From: Anil John <[email-masked]>
Date: Tue, 11 Nov 2014 18:08:57 -0500

>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.

An interesting perspective Nat.

So the focus of the VoT appears to be about Authentication and Token
Assurance and to make it easier for developers to consume the results (per
earlier conversational threads).

If that is indeed so, given the work that the Trust Elevation TC at OASIS
had done / is doing and the work that FIDO is doing, I am unsure of the
value add here.

Regards,

- Anil

:- Anil John
:- *Making Digital Services Secure and Trustworthy*
:- https://blog.aniljohn.com

---

From: Leif Johansson <[email-masked]>
Date: Wed, 12 Nov 2014 00:50:46 +0100

On 2014-11-12 00:08, Anil John wrote:
>>In many cases, people do not care about Identity Proofing. As long as
> the credential management 
> Assurance and to make it easier for developers to consume the results
> (per earlier conversational threads).
> 
> If that is indeed so, given the work that the Trust Elevation TC at
> OASIS had done / is doing and the work that FIDO is doing, I am unsure
> of the value add here.
> 

No that is an oversimplification.

---

From: Jim Fenton <[email-masked]>
Date: Tue, 11 Nov 2014 16:01:27 -0800

Peter,

My point in suggesting use cases is that I have a sense that the model
is already too complex. Maybe an analyst can turn the crank and come up
with use cases that utilize all four of these factors independently, but
if they're too obscure that tells us something too.

I'm not clear on what you mean about extended attributes. When you talk
about identity proofing, you're already talking about establishing a
binding between an attribute (e.g., name) and an authentication token.

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".

Nat,

In using the word "reliability" I intentionally avoided the word
"quality". I would include identity proofing as one aspect of attribute
reliability, and since that's part of enrollment (per 29115) that must
not be out of scope.

-Jim

On 11/11/14 3:09 PM, Peter Alterman wrote:
> 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. 
>
> I fear there is a fair amount of rat hole diving in process, and I'm
> urging a pragmatic eye here. Strongly support putting off any
> discussion of extended attributes until this particular effort has
> been completed. No further work on attributes should go forward
> without benchmarking the myriad efforts in that arena in the past 3
> years so we don't reinvent any wheels or redefine the meaning of
> "round." 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.
>
> 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
>
>
> On Tue, Nov 11, 2014 at 5:28 PM, Nat Sakimura <[email-masked]
> <mailto:[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]
>     <mailto:[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
>         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
>
>
>>         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) 
>>         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
>>
>>
>>
>>
>>         <[email-masked]
>>         <mailto:[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
>>
>>             cell: 301-943-7452 <tel:301-943-7452>
>>
>>
>>                 <mailto:[email-masked]>
>>
>>                 To: "[email-masked] <mailto:[email-masked]>"
>>                 <[email-masked] <mailto:[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:
>>
>>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 12 Nov 2014 03:50:08 +0000

Hi Jim,

The scope of attribute assurance/reliability/quality that is needed for
particular purpose identity proofing is fairly limited compared to the case
of general purpose attribute proofing. Specifically, it would be policy
bound for the purpose of identity proofing. The set of attributes needed to
be verified/validated will be different from one case to another, and
that's where policy comes in. Many people believe that identity proofing is
about checking the name, dob, etc., but that is just one specific case. In
general, identity proofing is nothing but corroborating the presented
attribute value against the master database. In government use case, it
happens to be name, dob, etc, since that is acting as a part of identifier.
Suppose a case where the master database was set up around the retina
patter on the person who paid for the service. Then, asking name, dob, etc.
has no significance. In this case, the identity proofing is checking the
person's retina pattern against the data stored in the database, perhaps
after templating.

Cheers,

Nat

On Wed Nov 12 2014 at 9:01:36 Jim Fenton <[email-masked]> wrote:

>  Peter,
>
> My point in suggesting use cases is that I have a sense that the model is
> already too complex. Maybe an analyst can turn the crank and come up with
> use cases that utilize all four of these factors independently, but if
> they're too obscure that tells us something too.
>
> you're using it in the epidemiological sense. If there's a word here I have
> a quibble about, it's "trust".
>
> Nat,
>
> reliability, and since that's part of enrollment (per 29115) that must not
> be out of scope.
>
>
> -Jim
>
>
> urging a pragmatic eye here. Strongly support putting off any discussion of
> 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
>
>
>>  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.
>>
>>> 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.
>>>

---

From: Joanne Knight <[email-masked]>
Date: Wed, 12 Nov 2014 04:04:29 +0000

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) ;-)
Currently working for the Department of Internal Affairs - New Zealand
My role is to look after New Zealand's Evidence of Identity Standard, carrying out Identity-related risk assessments on government services and generally providing advice on the practice of Identity Management.
Lately I have become entwined with the writing of ISO/IEC 29003 - Identity Proofing.

As life has emerged in the [email-masked]<mailto:[email-masked]> group the last couple of days and I have started to see content on which I am encouraged to comment, here goes my initial thoughts - from a very non-technical approach.

I read Justin Richer's strawman and noted that he has identified a different number of levels in each dimension. My thinking so far is that this may very well be the case and that will have an interesting impact on the ability to have 4 (or any number) LoAs.

The identity subject (aka user) is associated with an identity provider which acts as a trusted 3rd party on behalf of the user wrt to a relying party by making identity assertions about the user to the relying party. The first time I have registered a clear indication that the context is limited to the creation of an (electronic) identity credential. Thank you. In my world I have a wider scope that encompasses identity and authentication in all contexts and channels and I have had trouble understanding all the bits that (to me) are missing. When considering who the audience is for LoA this context is the only time I have calculated that it is relevant. i.e. if you are not in the business of providing identity assertion services to other parties, you do not care what your resulting LoA might be. And no one else will really care either.  See comment on VoT below.

The dimensions I have noted are 4: identity proofing, credential management(which includes credential issuance, credential strength etc) and authentication (the use of the credential). For the purposes of assessing LoA I am inclined to want to split credential strength from the other aspects of credential management. I disagree that identity proofing should be expanded to Enrolment as this often begins to introduce elements of eligibility (outside of identity) for a service and the danger is that this then adds elements into credential management that could see a credential revoked for reasons other than user choice, death (or destruction) and fraud detection.

I agree with Nat that we must be able to accept the scenario that identity may not matter to a relying party but that the persistence of an identity entity credential binding may require a high level of assurance. This is required for single or binary assertions based on identity such as 'entity is over 18 years' or 'entity is a citizen'. Depending of course on the breadth of attributes in the identity service.

In regards to Identity proofing, which is my current focus, I am currently writing a paper that extends the 0-3 introduced by Justin. It has 4 levels including the zero level described, however level 3 has an A and B. I will forward for your opinion as soon as I can.

VoT - this is a complex way to express the factual outcome of each dimension. In the real world I would say 'who is the audience for this value?' The (business people in a) relying party probably do not care which individual element is at what level. However if the scales for each dimension are likely to be different then this may be the only realistic way to express an overarching  LoA.

Thanks for listening (reading).

PS. Peter loved your blog ' Why LOA for Attributes Don't Really Exist'

Joanne Knight | Evidence of Identity (EOI) Standard Custodian | Digital Transformation | Result 10 | RealMe
The Department of Internal Affairs Te Tari Taiwhenua
Direct Dial: +64 4 382 3596 | Extn: 4596
120 Victoria St | PO Box 10-526, Wellington 6143, New Zealand |  www.dia.govt.nz<http://www.dia.govt.nz>

[http://www.dia.govt.nz/diawebsite.nsf/Files/DIAlogo/$file/DIAlogo.png]

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,

My point in suggesting use cases is that I have a sense that the model is already too complex. Maybe an analyst can turn the crank and come up with use cases that utilize all four of these factors independently, but if they're too obscure that tells us something too.

I'm not clear on what you mean about extended attributes. When you talk about identity proofing, you're already talking about establishing a binding between an attribute (e.g., name) and an authentication token.

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".

Nat,

In using the word "reliability" I intentionally avoided the word "quality". I would include identity proofing as one aspect of attribute reliability, and since that's part of enrollment (per 29115) that must not be out of scope.

-Jim

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.

I fear there is a fair amount of rat hole diving in process, and I'm urging a pragmatic eye here. Strongly support putting off any discussion of extended attributes until this particular effort has been completed. No further work on attributes should go forward without benchmarking the myriad efforts in that arena in the past 3 years so we don't reinvent any wheels or redefine the meaning of "round." 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.

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

On Tue, Nov 11, 2014 at 5:28 PM, Nat Sakimura <[email-masked]<mailto:[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]<mailto:[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)

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]<mailto:[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<tel:301-943-7452>

On Tue, Nov 11, 2014 at 3:02 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Send vot mailing list submissions to
        [email-masked]<mailto:[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]<mailto:[email-masked]>

You can reach the person managing the list at
        [email-masked]<mailto:[email-masked]>

Today's Topics:

---------- Forwarded message ----------
From: "Richer, Justin P." <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[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:

Clone and fork away!

 -- Justin

_______________________________________________
vot mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/vot

_______________________________________________
vot mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/vot

vot mailing list

[email-masked]<mailto:[email-masked]>

vot mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Jones, Mark B" <[email-masked]>
Date: Wed, 12 Nov 2014 07:34:22 +0000

After attending Lief’s session on VoT in Indianapolis I was left with the idea that the foundation for this effort should be threats (or groups of threats).  It was my impression that a ‘Vector of Trust’ would get its direction from a specific threat or group of threats and its magnitude from how these threats are mitigated.  For example, I would propose that the ‘vector’ that Peter identified as missing would be the set of ‘authentication phase’ threats and the credential technology used to mitigate these threats.  Visually, the use of different credential technologies would move you along this vector where use of simple passwords would be a magnitude near the origin and use of cryptographic hard tokens would be a magnitude far from the origin.

All of the frameworks I have seen that are comparable to 800-63 have similar sections that outline threats and define levels of assurance by grouping these threats and prescribing methods for mitigating them in order to address predefined risk profiles.  If the goal is to improve interoperability between these frameworks and remove the assumption of predefined risk profiles, I suggest that this effort needs to look at how the various frameworks group threats, and then standardize these groupings and mitigation methods.

---

From: "Jones, Mark B" <[email-masked]>
Date: Wed, 12 Nov 2014 07:38:24 +0000

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.

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 12 Nov 2014 07:59:42 +0000

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:

> *[Jones, Mark B] *
> *Isn’t ‘authorization’ out of scope here?  The strawman document does not
> mention authorization.*
>