Subject: Re: [VoT] discussion of 800-63, below

From: Robin Wilton <[email-masked]>
Date: Sun, 18 Jan 2015 01:28:45 +0000

Folks, 

Just a quick "weekend" thought... in the sense that I want to float something for you to think about, rather than try to hammer home a specific opinion.

800-63 is good as far as it goes, but I think we'd all acknowledge that it is an attempt to systematise a subset of trust factors relating to a specific, relatively simple model of how credentials and authentication are meant to work. 

I think the value that VoT can bring is 

(i) looking at how to systematise more trust factors, and/or more complex models of how credentials and authentication are meant to work (and I think much of the discussion below goes towards that);

(ii) looking at emerging trust models (for instance, in Open Data contexts, where data controllers just publish an API and say "have at it"...). I think emerging trust models challenge some of the fundamental assumptions in the current discussion. For instance:

- there's an implication, below, that trust is binary. You either trust the source of an attribute to be authoritative/accurate/reliable/timely or you don't. But the more dynamic online relationships are, the more likely it is that their trust status might be partial (you trust them to a certain extent) or indeterminate (you don't know whether this specific feed of data is trustworthy or not, but if you compare it with others, you might form a view). There are examples of this in, for example, privacy-preserving monitoring of vehicle traffic flows.

As I say, I'm not trying to lobby for a specific solution here, just trying to see if there are areas where VoT can add value that is unlikely to come from groups less intelligent and well-informed than this one.

R 

Robin Wilton

Technical Outreach Director - Identity and Privacy

On 18 Jan 2015, at 07:00, "[email-masked]" <[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: A modest proposal to replace LOA (Jones, Mark B)
>   2. Re: A modest proposal to replace LOA (Cantor, Scott)
>   3. Re: A modest proposal to replace LOA (Natale, Bob)
>> -----Original Message-----
>> From: vot [mailto:[email-masked]] On Behalf Of Eric Goodman
>> Sent: Friday, January 16, 2015 12:00 PM
>> To: [email-masked]
>> Subject: Re: [VoT] A modest proposal to replace LOA
>> 
>>>> I believe that relying parties must trust 'attribute providers'
>>>> as opposed to trusting specific attribute assertions.  It is my
>>>> opinion that relying parties should only request attributes from
>>>> providers they consider to be (or accept as) authoritative for the
>>>> attributes requested.  So in my view attributes have little to do with
> LOA
>> discussion.
>> 
>>> But there may be circumstances where attribute providers have different
>>> levels of confidence (do differing levels of diligence) on attributes
>>> and therefore may need to assert something at a lower level of trust
>>> than they hold. There may also be business drivers, such as attribute
>>> providers charging more for higher-confidence assertions.
>> 
>> Asserting Silver or NIST LOA 2 *is* an "attribute assertion", even though
> it's
>> applied globally to the attributes in that assertion (and not
> per-attribute).
>> Whether you codify this with NIST-style LoA profiles or via
> "attribute-specific
>> vector" measures doesn't change the fact that you are making per-user
>> attribute assertions.
>> 
>> --- Eric
> 
> [Jones, Mark B] 
> Eric,
> 800-63 is very clear in stating that its scope only applies to
> authentication.  Your statement above is a perfect example of why levels of
> assurance should only apply to the authentication and not the attributes.
> It is circular logic to say:  I told you to trust me, so now you trust me.
> How can the assertion of an attribute establish trust in itself?  If you are
> trusting the attribute provider when it self asserts LOA haven't you simply
> decided to trust any attribute it provides?  Isn't it reasonable to assume
> that an attribute provider that you trust will supply any attribute
> assertion in good faith?
> 
> Under what circumstances would you not trust a provider that you have
> requested attributes from, and if such a circumstance exists why are you
> requesting anything from them?  Note that I'm not expecting trusted
> attribute providers to be perfect, but it is my opinion that you should
> expect providers to assert the best information they have or nothing.  
> 
> The purpose of LOA is not to tell you how much to trust the attribute
> provider, it is to tell you how much to trust the user at the other end of
> the transaction (in my opinion).
>> Eric,
>> 800-63 is very clear in stating that its scope only applies to
>> authentication. 
> 
> Which is why it's nonsensical to start with, because there is no way to communicate an "identity" without an attribute digitally. It's defining its own scope as zero.
> 
>> Your statement above is a perfect example of why levels of
>> assurance should only apply to the authentication and not the attributes.
> 
> The other way around, in my personal opinion. Authentication means nothing to an app. The "truth" and risk in accepting the data being consumed is what matters to any RP.
> 
>> Under what circumstances would you not trust a provider that you have
>> requested attributes from, and if such a circumstance exists why are you
>> requesting anything from them?
> 
> Replace attributes with authentication in that sentence and it's the same question. The answer of course is that not all authentication is equal, just as not all assertions of data are equal in their confidence level. Why is authentication a transactional consideration but attributes are exactly consistent across the provider? Both are transactional considerations.
> 
>> The purpose of LOA is not to tell you how much to trust the attribute
>> provider, it is to tell you how much to trust the user at the other end of
>> the transaction (in my opinion).
> 
> Disagree strenuously. LOA is about the trust placed in an assertion of data by somebody in terms of risk mitigation. It's all data and all attributes. Identity is irelevant except as a consequence of how particular data might be applied and used.
> 
> -- Scott
> 
> 
> Hi Mark,
> 
> I realize that this is a relatively small point in the context of the thread at this stage, but I believe that your comment below that "authentication establishes trust in the PERSON on the other end of a transaction" needs to be expanded to read "authentication establishes trust [i.e., level of confidence] in the ENTITY on the other end of a transaction" since we have to account for non-person entities as well as human users and authentication is only one link in the chain of establishing trust in the entity for a particular transaction in a particular context.
> 
> Avanti,
> BobN
> 
> -----Original Message-----
> From: vot [mailto:[email-masked]] On Behalf Of Jones, Mark B
> Sent: Sunday, January 11, 2015 9:24 PM
> To: Jim Fenton; [email-masked]
> Subject: Re: [VoT] A modest proposal to replace LOA
> 
> It is my opinion that the levels of assurance in 800-63 are meant to describe specific sets of threats that should be addressed at specific, common risk levels and to describe how to mitigate those threats.  It is not clear what specific threats your proposed levels are meant to address.  (I think the VoT discussion in general is also lacking in references to what specific threats are meant to be addressed by specific vectors.)
> 
> Though 800-63 has language that talks about including verified attributes in credentials and assertions it makes it clear that inclusion of attributes is optional.  I feel that 800-63 works just fine in a model where authentication and attribute providers are separate because it does not specify any limits on how attributes can be communicated.  It is my opinion that 'authentication' and the communication of attributes must be conceptualized as very separate processes and that your concept of "Attribute Reliability" inappropriately conflates 'Registration and Credential Issuance' with attribute assertions.  The threats associated with inappropriate registration and credential issuance are very different from those associated with receiving inaccurate attribute assertions.
> 
> Though some have reasonable arguments for assigning levels of assurance to attributes, I believe that relying parties must trust 'attribute providers'
> as opposed to trusting specific attribute assertions.  It is my opinion that relying parties should only request attributes from providers they consider to be (or accept as) authoritative for the attributes requested.  So in my view attributes have little to do with LOA discussion.
> 
> In summary I feel that any scheme for expressing LOA needs to describe the threats that are mitigated, the strength of those mitigations, and trust of authentication should be kept separate from trust of attribute assertions.
> After all, authentication establishes trust in the PERSON on the other end of a transaction while trust in an attribute assertion represents trust in the PROVIDER to collect and assert good attributes.  
> 
>> -----Original Message-----
>> From: vot [mailto:[email-masked]] On Behalf Of Jim Fenton
>> Sent: Friday, January 09, 2015 2:50 PM
>> To: [email-masked]
>> Subject: [VoT] A modest proposal to replace LOA
>> 
>> I posted some ideas yesterday on a somewhat constrained possible 
>> replacement for Levels of Assurance:
>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__altmode.wordpress.com_2015_01_08_level-2Dof-2Dassurance-
>> 2Dalternatives-2Da-2Dmodest-
>> 2Dproposal_&d=AwICAg&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH
>> 1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=2E_n-
>> hMMZrra2XwK7mj_KrpU8b-c3PcCa45FsWVh0bE&s=Af4ObdyoFr4e6yoEMT-
>> aIfNHcCZsmGzZZMyr1LnD5Oo&e=
>> 
>> tl;dr: One dimension (LOA) isn't enough, but we don't want too many 
>> dimensions or levels because that gets unwieldy. I'm proposing 3 
>> levels
> each
>> of two dimensions: Level of Strength (authentication) and Level of
> Reliability
>> (attribute binding/proofing).
>> 
>> Any thoughts would be appreciated.
>> 
>> -Jim
>> 
>> _______________________________________________
>> vot mailing list
>> [email-masked]
>> https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mailman_listinfo_vot&d=AwICAg&c=6vgNTiRn9_pqCD9h
>> Kx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5
>> _Zpblz7C5LhM&m=2E_n-hMMZrra2XwK7mj_KrpU8b-
>> c3PcCa45FsWVh0bE&s=M7Gbma252T4WErXbcfD-
>> 69cOz3ZwOSUUCxEP2QIPklg&e=
> 
> 
> _______________________________________________
> vot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vot