[VoT] Credential usage, presentation and verification

[Robin Wilton <[e-mail]>]

Apologies for top-posting, but I wanted to make some comments which refer partly to both Joanne’s and Jim’s preceding posts, and there wasn’t a neat way to do so inline.

If you look at the whole credential lifecycle, there are trust factors (not vectors!) throughout it. VoT looks at a subset of them:
- how reliably the issuing party establishes the identity of the applicant;
- how strongly the credential is bound to the applicant;
- how reliably the credential is presented.

However, there are significant trust factors at other stages in the lifecycle:

- how reliably the credential is verified when it is presented (by analogy, think of the cursory check a retail clerk gives your “signature” compared to the one on your credit card)
- how robust the processes are for amending, revoking and/or destroying a credential.

Of these two, the second could be put neatly under the heading of “credential management” and represented by the same vector.

The first (reliability of the credential verification process upon presentation) is harder to account for, and I think this is because it is generally partly or wholly outside the control of the IDP. (Again, by analogy, think of Point of Sale terminals; these are, essentially, an attempt by the IDP [card issuer] to retain control over the verification step, essentially taking the RP out of the loop. But they do so at the cost of significant effort, and the ‘remote’ part of the process is still susceptible to subversion.)

I am not yet sure it can be sensibly formalised in a vector - but I think it’s worth considering, because it’s a significant trust factor in the over-all lifecycle.

Here’s a straw-man use case, just to kick around…

An IDP issues electronic credentials, and offers RPs a range of verification alternatives:

when one of our credentials is presented,

3 - you will verify it using a black box that we require you to install at your premises, and which not only checks the credential itself, it also “phones home” to do a real-time revocation check
or

2 - there’s no black box; we will provide you with a software verification module that you run, to verify the credential and do a revocation check
or

1 - we’ll expose a web services API at our end, for credential verification and revocation status
or

0 - we just issue the credentials; how you verify them on presentation is up to you


The IDP’s liability model would vary accordingly.

One issue with this straw-man is that the IDP is telling the RP stuff that they both already know…
On the other hand, exchanging a message to that effect does create an audit trail, which might be useful for compliance purposes.


Any thoughts?


R


> 
> From: Joanne Knight <[e-mail]>
> Subject: Re: [VoT] Vectors of Trust I-D feedback
> Date: 4 August 2015 01:05:17 BST
> To: 'Jim Fenton' <[e-mail]>, Nat Sakimura <[e-mail]>, Rainer Hoerbe <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, Justin Richer <[e-mail]>
> 
> 
> 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:[e-mail]]
> Sent: Tuesday, 4 August 2015 10:32 a.m.
> To: Nat Sakimura; Rainer Hoerbe
> Cc: [e-mail]; 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
> 
> 
> 
> 
> 
> 
> From: Nat Sakimura <[e-mail]>
> Subject: Re: [VoT] Vectors of Trust I-D feedback
> Date: 4 August 2015 01:53:44 BST
> To: Jim Fenton <[e-mail]>
> Cc: Rainer Hoerbe <[e-mail]>, Justin Richer <[e-mail]>, "[e-mail]" <[e-mail]>
> 
> 
> Right, X.1254 | ISO/IEC 29115 says:
> 8.1  Enrolment phase
> 
> 8.2  Credential management phase
> 
> 8.3  Entity authentication phase
> 
> It also has
> 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.)
> 
> 2015-08-04 7:31 GMT+09:00 Jim Fenton <[e-mail]>:
> 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
> 
> 
> 
> From: Nat Sakimura <[e-mail]>
> Subject: Re: [VoT] Vectors of Trust I-D feedback
> Date: 4 August 2015 02:14:11 BST
> To: Joanne Knight <[e-mail]>
> Cc: Jim Fenton <[e-mail]>, Rainer Hoerbe <[e-mail]>, Justin Richer <[e-mail]>, "[e-mail]" <[e-mail]>
> 
> 
> 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 <[e-mail]>:
> 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:[e-mail]]
> Sent: Tuesday, 4 August 2015 10:32 a.m.
> To: Nat Sakimura; Rainer Hoerbe
> Cc: [e-mail]; 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vot