Subject: Re: [VoT] Vectors of Trust I-D feedback

From: Nat Sakimura <[email-masked]>
Date: Sun, 2 Aug 2015 18:59:49 +0900

I agree that we should split out the credential management and the
credential usage.
Each should have different "grades".

Right now, -00 has:

3.1. Identity Proofing
3.2. Credential Management
3.3. Assertion Presentation

Instead, it could be

3.1 Identity Proofing
3.2 Credential Management
3.3 Credential Usage
3.4 Assertion Presentation

Then, 3.1 - 3.3 aligns with X.1254 and ISO/IEC 29115, which is good.
Note: they are missing 3.4.

We also need to define vtm.
I imagine that vtm uri would point to the policy documents of the trust
framework,
but that is not explicitly there.

Best,

Nat

2015-07-31 17:44 GMT+09:00 Rainer Hoerbe <[email-masked]>:

> See my proposed changes in the attached word document.
>
> Another point:  I wonder if there is consistent understanding wrt.
> Credential Management  levels. How do people grade strong credentials that
> rely on a weak recovery mechanisms like eMail and KBA? When multiple
> C-levels are asserted, they are reducing the risk, but joining session
> authentication and credential recovery is increasing the risk. I think that
> VoT should be include a rule how to handle this.
>
> - Rainer
>
>
> Am 30.07.2015 um 14:12 schrieb Justin Richer <[email-masked]>:
>
> Rainer,
>
> Thanks for this input, this is helpful. When Leif and I picked the term
> "Vectors of Trust" we knew that each part of that phrase was problematic in
> some fashion, but we've yet to hear something that's more serviceable. This
> is the reasoning behind the explanatory section at the beginning, actually.
> Can you suggest some text for a better way to situate the terms?
>
>  -- Justin
>
> On 7/30/2015 7:20 AM, Rainer Hoerbe wrote:
>
> The term vector seems to stick since Bob Morgan’s visualization some years
> ago despite some resistance. However its connotation in „2.2 Component
> Architecture“ is misleading, because all the language about „mathematical
> construct“, „coordinate system“ and „must be orthogonal“ is not properly
> put into context by "need for simplicity“ and "somewhat elided model“.
>
> I suggest to use stronger wording to make it clear to the newcomer that
> this kind of taxonomy is by its nature an oversimplification. Fitting a
> square peg into a round hole is the only option to reduce the complexity of
> trust frameworks. There should be an emphasis that the number of vectors,
> their orthogonality and composition will never be a clean and undisputed
> derivation from real trust models, but an extension and improvement from
> current practices like 800-63. VoT is taking facts that are measurable out
> of the trust framework leaving the amorphous rest to TLDR risk assessments.
>
> - Rainer
>
> Am 30.07.2015 um 06:28 schrieb Joanne Knight <[email-masked]>:
>
> Hi All
>
>
> Due to workloads it has taken me a while to catch-up and I am sorry I was
> unable to make the Bar BoF.
>
>
> I have attached a paper with my thoughts on the drafty draft as well as
> where my own framework has evolved to so far. I have recently latched on to
> a resource to aid me in progressing the Identity-related risk assessment so
> let me know if anyone is interested in the out-comes as not directly VoT
> related.
>
>
> Thoughts only, take them at your whim.
>
>
> Cheers
>
>
> Joanne
>
>
>
>
> *From:* Justin Richer [ <[email-masked]>mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Saturday, 27 June 2015 3:15 p.m.
> *To:* [email-masked]
> *Subject:* [VoT] Vectors of Trust I-D
>
>
>
> Hi Everyone,
>
>
>
> I have taken the initial strawman proposal along with a substantial number
> of edits and inputs from several folks and have created an initial I-D of
> the document:
>
>
>
> https://tools.ietf.org/id/draft-richer-vectors-of-trust-00
>
>
>
> It’s still a very drafty draft, but hopefully it’s starting to make this a
> concrete thing. Please read it over and discuss it here on the list.
>
>
>
> I would like to propose a bar-BoF in Prague for VoT for anyone who would
> like to discuss this. If you’re interested (and will be there in person),
> let me know!
>
>
>
>  — Justin
> <VoT Feedback.docx>_______________________________________________
> 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
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Jim Fenton <[email-masked]>
Date: Mon, 3 Aug 2015 15:31:30 -0700

To be entirely consistent with ISO/IEC 29115, we would need to rename
Identity Proofing as Enrolment, and Credential Usage as Authentication.

But ISO/IEC 29115 refers to these as phases: they occur at different
times (or, in the case of Credential Management, over a long period of
time) and have different threat models. But I would like to ask under
which circumstances a Relying Party would act differently to an
indication of less secure Credential Management vs. less secure
Authentication. There are credential management practices that would
make a credential unsuitable for highly secure authentication, but why
not just represent that as less secure authentication? VoT should be
only as complex as required; it should not represent aspects of the
process that the relying party does not need.

Also, Enrolment includes aspects of the credentialing process that go
far beyond identity proofing and the binding of those attributes in a
credential. It's the reliability of that attribute assertion that's
orthogonal to authentication strength, and not all of the other aspects
of enrolment.

Finally, I'll repeat my comment that's buried in my review of the I-D
the other day that Assertion Presentation should be visible to the RP
already. For example, if the assertion is encrypted in transit, the RP
will know that without being told. There may be need for the RP to
specify how it wants assertions to be presented to it, but that seems
like more of a general option to me and not part of the Vector.

-Jim

On 8/2/15 2:59 AM, Nat Sakimura wrote:
> I imagine that vtm uri would point to the policy documents of the
> trust framework,

---

From: Ira McDonald <[email-masked]>
Date: Mon, 3 Aug 2015 19:22:43 -0400

Hi,

And for those who forgot (I did), ISO 29115 is technically equivalent to
ITU-T X.1254 (and the latter's available online for free download in PDF).

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Mon, Aug 3, 2015 at 6:31 PM, Jim Fenton <[email-masked]> wrote:

> But ISO/IEC 29115 refers to these as phases: they occur at different times
> (or, in the case of Credential Management, over a long period of time) and
> have different threat models. But I would like to ask under which
> circumstances a Relying Party would act differently to an indication of
> less secure Credential Management vs. less secure Authentication. There are
> credential management practices that would make a credential unsuitable for
> highly secure authentication, but why not just represent that as less
> secure authentication? VoT should be only as complex as required; it should
> not represent aspects of the process that the relying party does not need.
>
> Also, Enrolment includes aspects of the credentialing process that go far
> beyond identity proofing and the binding of those attributes in a
> orthogonal to authentication strength, and not all of the other aspects of
> enrolment.
>
> Finally, I'll repeat my comment that's buried in my review of the I-D the
> other day that Assertion Presentation should be visible to the RP already.
> For example, if the assertion is encrypted in transit, the RP will know
> that without being told. There may be need for the RP to specify how it
> wants assertions to be presented to it, but that seems like more of a
> general option to me and not part of the Vector.
>
> -Jim
>

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 4 Aug 2015 08:45:21 +0900

Yup. If I remember correctly, only three words are different between X.1254
and ISO/IEC 29115. X.1254 can be downloaded from here:
https://www.itu.int/rec/T-REC-X.1254-201209-I/en

2015-08-04 8:22 GMT+09:00 Ira McDonald <[email-masked]>:

>> time) and have different threat models. But I would like to ask under which

---

From: Joanne Knight <[email-masked]>
Date: Tue, 4 Aug 2015 00:05:17 +0000

ISO/IEC 29115 has been nothing but a headache for me for a number of years.

If we want to be evolutionary I would not constrain myself to trying to be consistent with it - especially since it is currently being reviewed. I have also suggested that it look this way ;-) rather than the other way around.

I am still out to lunch on Assertion Presentation. Just because it exists in my framework and has (thanks to Justin) got a label, I have not had time to think through exactly what it is and means. It may be that it is a series of aspects that must be added to the other Vectors. They may not be measurable, in which case they become guidance.

As it was Nat who lit the spark that there is this other 'thing' in the mix, I am hoping for a flu free ISO meeting to have an academic brainstorm. Jim, I seem to have missed your review of I-D, so would appreciate if you can send me your thoughts on Assertion Presentation.

Cheers

Joanne

From: Jim Fenton [mailto:[email-masked]]
Sent: Tuesday, 4 August 2015 10:32 a.m.
To: Nat Sakimura; Rainer Hoerbe
Cc: [email-masked]; Justin Richer
Subject: Re: [VoT] Vectors of Trust I-D feedback

To be entirely consistent with ISO/IEC 29115, we would need to rename Identity Proofing as Enrolment, and Credential Usage as Authentication.

But ISO/IEC 29115 refers to these as phases: they occur at different times (or, in the case of Credential Management, over a long period of time) and have different threat models. But I would like to ask under which circumstances a Relying Party would act differently to an indication of less secure Credential Management vs. less secure Authentication. There are credential management practices that would make a credential unsuitable for highly secure authentication, but why not just represent that as less secure authentication? VoT should be only as complex as required; it should not represent aspects of the process that the relying party does not need.

Also, Enrolment includes aspects of the credentialing process that go far beyond identity proofing and the binding of those attributes in a credential. It's the reliability of that attribute assertion that's orthogonal to authentication strength, and not all of the other aspects of enrolment.

Finally, I'll repeat my comment that's buried in my review of the I-D the other day that Assertion Presentation should be visible to the RP already. For example, if the assertion is encrypted in transit, the RP will know that without being told. There may be need for the RP to specify how it wants assertions to be presented to it, but that seems like more of a general option to me and not part of the Vector.

-Jim

On 8/2/15 2:59 AM, Nat Sakimura wrote:
I agree that we should split out the credential management and the credential usage.
Each should have different "grades".

Right now, -00 has:

3.1. Identity Proofing

Instead, it could be

3.1 Identity Proofing

We also need to define vtm.
I imagine that vtm uri would point to the policy documents of the trust framework,
but that is not explicitly there.

Best,

Nat

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 4 Aug 2015 09:53:44 +0900

Right, X.1254 | ISO/IEC 29115 says:

   1.

   8.1  Enrolment phase
   2.

   8.2  Credential management phase
   3.

   8.3  Entity authentication phase

It also has

   1.

   9  Management and organizational considerations.

My point is that this I-D seems to use "Credential Management" for "Entity
Authentication" (BTW, at one point of the draft, it was called "Credential
Usage", or at least, JP NB proposed the name because this entire framework
is "Entity Authentication" and not this specific phase.)

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 4 Aug 2015 10:14:11 +0900

Hi.

I think X.1254 | ISO/IEC 29115 is actually quite good if you read deeply
into it especially from private sector point of view. It has departed from
the government centric approach as it should be as an industry standard,
and the applicability was widened considerably.

What's really good about it is its departure from the notion that identity
is {name, dob, address + some other attributes}. It is policy based so that
the policy in the framework should decide what needs to be verified to
achieve "identity proofing." In the private sector usage, it may just be a
validity of payment instrument and contact method.

29115 is not being reviewed at this time. There is an SP but it is just an
SP (study period) and not review. Review is supposed to start in December
2016.

Sort of assertion presentation has been in SP800-63 for sometime.
In the most recent one [SP800-63], it is clause 9.

[SP800-63]
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf,

2015-08-04 9:05 GMT+09:00 Joanne Knight <[email-masked]>:

> If we want to be evolutionary I would not constrain myself to trying to be
> consistent with it – especially since it is currently being reviewed. I
> have also suggested that it look this way ;-) rather than the other way
> around.
>
>
>
> I am still out to lunch on Assertion Presentation. Just because it exists
> in my framework and has (thanks to Justin) got a label, I have not had time
> to think through exactly what it is and means. It may be that it is a
> series of aspects that must be added to the other Vectors. They may not be
> measurable, in which case they become guidance.
>
>
>
> As it was Nat who lit the spark that there is this other ‘thing’ in the
> mix, I am hoping for a flu free ISO meeting to have an academic brainstorm.
> Jim, I seem to have missed your review of I-D, so would appreciate if you
> can send me your thoughts on Assertion Presentation.
>
>
>
> Cheers
>
>
>
> Joanne
>
>
>
> *From:* Jim Fenton [mailto:[email-masked]]
> *Sent:* Tuesday, 4 August 2015 10:32 a.m.
> *To:* Nat Sakimura; Rainer Hoerbe
> *Cc:* [email-masked]; Justin Richer
> *Subject:* Re: [VoT] Vectors of Trust I-D feedback
>
>
>

---

From: "Salvatore D'Agostino" <[email-masked]>
Date: Mon, 3 Aug 2015 21:24:29 -0400

+1

From: vot [mailto:[email-masked]] On Behalf Of Nat Sakimura
Sent: Monday, August 03, 2015 9:14 PM
To: Joanne Knight
Cc: Jim Fenton; Rainer Hoerbe; Justin Richer; [email-masked]
Subject: Re: [VoT] Vectors of Trust I-D feedback

Hi. 

I think X.1254 | ISO/IEC 29115 is actually quite good if you read deeply into it especially from private sector point of view. It has departed from the government centric approach as it should be as an industry standard, and the applicability was widened considerably. 

What's really good about it is its departure from the notion that identity is {name, dob, address + some other attributes}. It is policy based so that the policy in the framework should decide what needs to be verified to achieve "identity proofing." In the private sector usage, it may just be a validity of payment instrument and contact method. 

29115 is not being reviewed at this time. There is an SP but it is just an SP (study period) and not review. Review is supposed to start in December 2016. 

 

[SP800-63]  http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf, 

If we want to be evolutionary I would not constrain myself to trying to be consistent with it – especially since it is currently being reviewed. I have also suggested that it look this way ;-) rather than the other way around.

As it was Nat who lit the spark that there is this other ‘thing’ in the mix, I am hoping for a flu free ISO meeting to have an academic brainstorm. Jim, I seem to have missed your review of I-D, so would appreciate if you can send me your thoughts on Assertion Presentation.

Cheers

Joanne

-Jim

Right now, -00 has: 

3.1. Identity Proofing 

Instead, it could be

3.1 Identity Proofing

3.3 Credential Usage

Best, 

Nat

 

-- 

Nat Sakimura (=nat)

---

From: Rainer Hoerbe <[email-masked]>
Date: Tue, 4 Aug 2015 08:12:29 +0200

Am 04.08.2015 um 00:31 schrieb Jim Fenton <[email-masked]>:
> But ISO/IEC 29115 refers to these as phases: they occur at different times (or, in the case of Credential Management, over a long period of time) and have different threat models. But I would like to ask under which circumstances a Relying Party would act differently to an indication of less secure Credential Management vs. less secure Authentication.
For a targeted attack the weak credential recovery will lower the adversary’s effort significantly, whereas in large numbers a 2F AuthN combined will still reduce the overall risk.

> There are credential management practices that would make a credential unsuitable for highly secure authentication, but why not just represent that as less secure authentication? VoT should be only as complex as required; it should not represent aspects of the process that the relying party does not need.

+1. However, I remember a discussion at IIW where someone argued that an important use case for VoT is the combination of C4 (U2F) with  P1 (self-asserted) for social ids. But social networks are prioritizing usability over security with a weak recovery mechanism.

- Rainer

---

From: sakimura <[email-masked]>
Date: Tue, 04 Aug 2015 15:39:57 +0900

>> Identity Proofing as Enrolment, and Credential Usage as 

Actually, renaming it as Enrollment may have some merit. Identity 
Proofing is only a process within Enrollment.
There are whole bunch of other stuff that has to happen then.
Even if the Identity Proofing was done perfectly, if the act of creating 
the record to the identity register is broken, it is broken.

>> Authentication.
> For a targeted attack the weak credential recovery will lower the
> adversary’s effort significantly, whereas in large numbers a 2F AuthN
> combined will still reduce the overall risk.

+1. That is one of the reason I feel it is worthwhile to differentiate 
them.

> 
>> There are credential management practices that would make a credential 
>> unsuitable for highly secure authentication, but why not just 
>> represent that as less secure authentication? VoT should be only as 
>> complex as required; it should not represent aspects of the process 
>> that the relying party does not need.
> 
> +1. However, I remember a discussion at IIW where someone argued that
> an important use case for VoT is the combination of C4 (U2F) with  P1
> (self-asserted) for social ids. But social networks are prioritizing
> usability over security with a weak recovery mechanism.

In private sector, there are lots of cases where identity proofing in 
the traditional sense does not
matter but the secure authentication matters. I actually co-authored a 
paper on it last month.

---

From: sakimura <[email-masked]>
Date: Tue, 04 Aug 2015 15:44:19 +0900

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 4 Aug 2015 16:07:05 +0900

Sorry, I have been experiencing network problems that the signal went up /
down many times.
Apparently, the web mail was reloading each time that happened and somehow
sending out the message each time.

I sincerely apologize it.

Nat

2015-08-04 15:44 GMT+09:00 sakimura <[email-masked]>:

> Actually, renaming it as Enrollment may have some merit. Identity Proofing
> is only a process within Enrollment.
>>> less secure Credential Management vs. less secure Authentication.
>>>
>>> unsuitable for highly secure authentication, but why not just represent
>>> that as less secure authentication? VoT should be only as complex as
>>> required; it should not represent aspects of the process that the relying
>>> party does not need.
>>>
>>
> In private sector, there are lots of cases where identity proofing in the
> traditional sense does not

---

From: Patrick Curry <[email-masked]>
Date: Tue, 4 Aug 2015 09:26:17 +0100

29115 kept things at a pretty high level and approximated with its use of language, which is understandable given that we don’t have enough nouns and verbs, in particular, to describe the increasing & changing complexity of all things identity.  SC27 WG5 agreed that other standards that are going into more detail than 29115 cannot be constrained by 29115’s imprecision.  There is a pressing requirement, articulated also in EU, US SSCA and ITU-T for more precision, consistency and interoperability in these standards.  As rapporteur for the ISO Study Period on Anonymous Attribute Assurance and co-editor 29003, I see this as vital.

So, to help… in most industries and governments these days, enrolment is the process that starts with or after application, going right through to registration of identity attributes into an authoritative register (if the identity proofing is successful and the application is approved).  That register is then used to start the credential issuance phase, which is also part of/linked to credential production; production starts much earlier with the secure procurement of the physical, logical and cryptographic components that eventually comprise the credential container that is bound to the identity and entity. The end of the issuance phase is the issuance (and account provisioning) to the end-user, the authenticated activation of the credential/token/cryptography, a functional check and the transfer of legal liability and ownership.  The credential/token etc is now ready for use. The usage phase may include updates and suspensions, but ultimately it will end in revocation and, depending on policy, destruction and data purging & archiving.   Credential management occurs from the register forward and is linked to, but not the same as, card management or card operations (Card Ops) which are other common terms.  All this said, some of these terms will continue to mean other things to other people.  The important point is that we are able to describe the processes and functional breakdown in a way that can be described and used in a standard.

Without wishing to upset VoT thinking, there are developments in the mobile and blockchain worlds that are adding further options to the proofing process, some of which is about big data use and links back to antecedent data.  One aspect of this is exploring how to use online credentials to support offline credentials, consequently, your birth certificate and passport (for example) may no longer be primary identity documents unless they are supported by an online credential held in a trusted & secure device and capable of a secure end-to-end connection to the Authoritative Source, where “end” is the user interface, not the (vulnerable) operating system.  There is work to do, but discussion has begun on how this alters/improves/enables Chains of Trust and Derived Credentials.  Given that some of the technology will go live at scale in the next few months, might these developments be of interest to VoT?

The UK government has committed to introduce legislation for online age verification for adult media content.  This requires an unspecified degree of anonymity at each point in the access control process.  The debate continues on how much strength there should be in the anonymous AV attribute being asserted to the RP.  Two of the several different views seek a strong and a weak solution.  One wants a LoA2+ AV attribute bound to a compliant identity at LoA 2+; in this case they see the strength of the attribute deriving from the authentication strength.  The second is based on scraping the use of a LoA 1 ID attribute e.g. email address, to derive a behaviour profile that would give confidence that a person is over 18; whilst cheap, this raises a load of legal issues.  I mention this because attribute orthogonality may be the norm but it isn’t always so, depending on the context.

I agree about the attribute presentation to the RP.

Finally, does anyone know how VoT fits with the emerging US ANSI IDPV standard?

Patrick

Patrick Curry
Director

British Business Federation Authority - BBFA Ltd
M: +44 786 024 9074
T:   +44 1980 620606
[email-masked]
www.bbfa.info – a not-for-profit, self-regulating body 

On 3 Aug 2015, at 23:31, Jim Fenton <[email-masked]> wrote:

-Jim

---

From: Justin Richer <[email-masked]>
Date: Tue, 4 Aug 2015 10:22:00 -0400

Just a quick note: I’ve come to agree that the Assertion Presentation component is most useful in the client’s request, where other protocols don’t always have such mechanisms. This raises an interesting question: should each component have a “target”? That is, either the response (vot) or the request (vtr), or both. This would be an indicator of the intent of the component, not so much its use in practice.

 — Justin

> On Aug 3, 2015, at 6:31 PM, Jim Fenton <[email-masked]> wrote:
>

---

From: Jim Fenton <[email-masked]>
Date: Tue, 4 Aug 2015 07:25:13 -0700

> For a targeted attack the weak credential recovery will lower the adversary’s effort significantly, whereas in large numbers a 2F AuthN combined will still reduce the overall risk.

I have trouble understanding how an authentication with weak credential
recovery could ever be called two-factor.
> +1. However, I remember a discussion at IIW where someone argued that an important use case for VoT is the combination of C4 (U2F) with  P1 (self-asserted) for social ids. But social networks are p…

We need to make sure that it's clear to everyone that a recovery
mechanism is just another way of logging in, and if it's weaker than the
primary login method the authentication is weaker overall.

-Jim