Subject: Re: [VoT] vot Digest, Vol 10, Issue 4

From: Peter Alterman <[email-masked]>
Date: Tue, 4 Aug 2015 09:26:23 -0400

+1
Any document that links assurance to risk mitigation is valuable whether it
comes from ISO, ITU-T, NIST or the Songmasters of Tuvalu.
P

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

On Mon, Aug 3, 2015 at 9:24 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. Re: Vectors of Trust I-D feedback (Salvatore D'Agostino)
>
>
> ---------- Forwarded message ----------
> From: "Salvatore D'Agostino" <[email-masked]>
> To: "'Nat Sakimura'" <[email-masked]>, "'Joanne Knight'" <
> [email-masked]>
> Cc: "'Jim Fenton'" <[email-masked]>, "'Rainer Hoerbe'" <
> [email-masked]>, "'Justin Richer'" <[email-masked]>, [email-masked]
> Date: Mon, 3 Aug 2015 21:24:29 -0400
> Subject: Re: [VoT] Vectors of Trust I-D feedback
>
> +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.
>
>
>
> 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]>:
>
> 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
> 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
>
>
>
>
>
>
>
>
>
>
>
> --
>
> Nat Sakimura (=nat)
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
> _______________________________________________
> vot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vot
>
>