Subject: [VoT] A modest proposal to replace LOA

From: Jim Fenton <[email-masked]>
Date: Fri, 09 Jan 2015 12:49:40 -0800

I posted some ideas yesterday on a somewhat constrained possible
replacement for Levels of Assurance:

https://altmode.wordpress.com/2015/01/08/level-of-assurance-alternatives-a-modest-proposal/

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

---

From: Andrew Hughes <[email-masked]>
Date: Fri, 9 Jan 2015 13:02:57 -0800

Hey Jim - have you seen the Government of Canada (GC) Standard on Identity
and Credential Assurance?

http://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=26776

It is architected with the concept of decoupling Identification assurance
and Authentication assurance (among other design factors).

The significant material here is that GC didn't just issue a standard on
assurance levels, they also developed guidance on how to evaluate and treat
risks related to those assurance levels. That's the magic part.

IMO The problem with 'Assurance Levels' is that they tend to be discussed
separately from the acceptable risk/impact related to receiving those
assured levels of assertion. That's why the LOA's appear strange - they are
only half (or less) of the story. Also, FWIW, since the OMB M04-04 LOAs are
predicated on the US Federal risk management requirements and profile,
attempting to apply them to other 'vertical's is problematic. Which is
often overlooked. But I know that you know all of this :-)

Andrew Hughes

*Andrew Hughes *CISM CISSP
Independent Consultant
*In Turn Information Management Consulting*

+1 250.888.9474
1249 Palmer Road,
Victoria, BC V8P 2H8
[email-masked]
ca.linkedin.com/pub/andrew-hughes/a/58/682/
*Identity Management | IT Governance | Information Security *

On Fri, Jan 9, 2015 at 12:49 PM, Jim Fenton <[email-masked]> wrote:

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

---

From: [email-masked]
Date: Sat, 10 Jan 2015 09:19:56 +1100 (EST)

If we're going to improve upon LOAs, then may I suggest the first thing to do is set out the objectives? 
 
- What is something like LOA really for? 
- Who uses a simplified "Risk Gauge", and how exactly? 
- How much original risk analysis is an RP expected to do before they bin their situation into Risk Gauge
- Is using a Risk Gauge supposed to save time in risk analysis?
- When an IdP claims a certain Risk Gauge, what does that really mean - contractually?
- If an RP at Gauge X finds an IdP at Gauge X (or higher), what's next? How much further analysis is needed before the RP can sign up the IdP? 
- If an IdP claims Risk Gauge X, how is that assured?
 
I suggest that LOAs were intended, net-net, to save time.  It was thought that by binning risk, RPs would be able to short list and then contract with suitable IdPs more quickly.  If there is any time saved in using LOAs then I suspect it gets gobbled up by the negotiating the fine print when signing up an IdP.  The very fact that RPs have asked for "LOA 2 and a half" tells us that the RP-IdP negotiation tends to be customised.  Than it, LOAs are difficult to standardise. 
 
Before we add dimensions, can we look at what its trying to achieve?
 
Cheers, 
 
Steve.

Stephen Wilson
Lockstep Group 
http://lockstep.com.au
Lockstep Consulting provides independent specialist advice and analysis 
on digital identity and privacy.  Lockstep Technologies develops unique 
new smart ID solutions that enhance privacy and prevent identity theft.

-----Original Message-----
From: "Jim Fenton" <[email-masked]>
Sent: Saturday, 10 January, 2015 7:49am
To: [email-masked]
Subject: [VoT] A modest proposal to replace LOA

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Fri, 09 Jan 2015 14:26:39 -0800

On 1/9/15 1:02 PM, Andrew Hughes wrote:
> Hey Jim - have you seen the Government of Canada (GC) Standard on
> Identity and Credential Assurance?
>
> It is architected with the concept of decoupling Identification
> assurance and Authentication assurance (among other design factors).

Thanks; I hadn't seen this particular standard. It looks like it slices
things up a little differently and uses a little different terminology,
such as the emphasis on "maintaining control over a credential". And it
uses 4 levels rather than 3. I came up with 3 by looking at the
authentication and attribute aspects of the current 4-level LOA
separately, and finding really only 3 meaningful levels of each. LOA 1
and 2 aren't all that different in authentication (both single-factor),
and LOA 2 and 3 aren't all that different in identity proofing
requirements (small differences in remote identity proofing
requirements). But if 4 levels are useful, and we can establish
meaningful distinctions between each of the levels, that can be done.
>
> The significant material here is that GC didn't just issue a standard
> on assurance levels, they also developed guidance on how to evaluate
> and treat risks related to those assurance levels. That's the magic part.
>
> IMO The problem with 'Assurance Levels' is that they tend to be
> discussed separately from the acceptable risk/impact related to
> receiving those assured levels of assertion. That's why the LOA's
> appear strange - they are only half (or less) of the story. Also,
> FWIW, since the OMB M04-04 LOAs are predicated on the US Federal risk
> management requirements and profile, attempting to apply them to other
> 'vertical's is problematic. Which is often overlooked. But I know that
> you know all of this :-)

In many ways, the LOA framework is a victim of its own success, because
it was just designed for US Federal requirements.  The part of the risk
structure that I don't see in this Canadian standard is some more detail
about what constitutes, for example, "moderate to serious harm." M-04-04
breaks that down more specifically by category and defines risks by
category, e.g. by treating personal safety risks as more sensitive than
financial losses.  Is there a companion document somewhere that has the
corresponding definitions for the Canadian risk levels?

-Jim

---

From: Joni Brennan <[email-masked]>
Date: Fri, 9 Jan 2015 14:26:20 -0800

+1 to the suggestions so far and the comments around defining objectives.

Apologies if this comment has already been made.  It may also be of use to
pop up in the stack as well regarding objectives.  One layer abstraction
removed from Steve's well pointed examples... I don't believe we need
specific architecture for each but rather simply to be aware of the varying
communities / priorities.

LoAs (or something like VoTs)
- Security
- Risk Management
- Interoperability (policy and tech)
- Commercial (regulated / non)
- Government (public service - and what is a public services varies
nationally)

Best Regards,

Joni Brennan
Kantara Initiative | Executive Director
email: joni @ kantarainitiative.org

Connecting Identity for a more trustworthy Internet - Overview
<http://www.slideshare.net/kantarainitiative/kantara-overview2014-37969351>

On Fri, Jan 9, 2015 at 2:19 PM, <[email-masked]> wrote:

> - If an RP at Gauge X finds an IdP at Gauge X (or higher), what's next?
> How much further analysis is needed before the RP can sign up the IdP?
>
> I suggest that LOAs were intended, net-net, to save time.  It was thought
> that by binning risk, RPs would be able to short list and then contract
> with suitable IdPs more quickly.  If there is any time saved in using
> LOAs then I suspect it gets gobbled up by the negotiating the fine print
> when signing up an IdP.  The very fact that RPs have asked for "LOA 2 and a
> half" tells us that the RP-IdP negotiation tends to be customised.  Than
> it, LOAs are difficult to standardise.
>
>
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 9 Jan 2015 22:59:56 +0000

To me, a lot of it comes down to helping the RPs answer one question:

"Someone just logged in. Now what?"

I think that binning risk is part of the issue (as Steve states), but it's also (as a corollary) a matter of setting the context of an authentication. It's not just about "do I trust the display name" or whatever other attribute, but also about communicating to the RP what just happened. This can give the RP a chance at correctly deciding what to do about it.

There are really two parts of the whole conversation that I think getting wound up in each other:
 - Things the RP needs to know about the IdP (i.e.: do I trust this IdP? what risk do I have in doing so?)
 - Things the RP needs to know about the authentication transaction (i.e.: do I trust this log in?)

The VoT proposal tries to address this with the two different parts of the protocol: the vector as conveyed by the protocol, and the "trust mark provider" discovery portion.

To me, everything else is an aspect of answering these fundamental questions.

 -- Justin

On Jan 9, 2015, at 5:26 PM, Joni Brennan <[email-masked]<mailto:[email-masked]>> wrote:

Apologies if this comment has already been made.  It may also be of use to pop up in the stack as well regarding objectives.  One layer abstraction removed from Steve's well pointed examples... I don't believe we need specific architecture for each but rather simply to be aware of the varying communities / priorities.

LoAs (or something like VoTs)
- Security
- Risk Management
- Interoperability (policy and tech)
- Commercial (regulated / non)
- Government (public service - and what is a public services varies nationally)

Best Regards,

Joni Brennan
Kantara Initiative | Executive Director
email: joni @ kantarainitiative.org<http://kantarainitiative.org/>

Connecting Identity for a more trustworthy Internet - Overview<http://www.slideshare.net/kantarainitiative/kantara-overview2014-37969351>

On Fri, Jan 9, 2015 at 2:19 PM, <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,

Steve.

Stephen Wilson
Lockstep Group
http://lockstep.com.au<http://lockstep.com.au/>
Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy.  Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft.

-----Original Message-----
From: "Jim Fenton" <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, 10 January, 2015 7:49am
To: [email-masked]<mailto:[email-masked]>
Subject: [VoT] A modest proposal to replace LOA

-Jim

_______________________________________________
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]>
https://www.ietf.org/mailman/listinfo/vot

---

From: Ken Dagg <[email-masked]>
Date: Fri, 9 Jan 2015 20:38:01 -0500

Justin,

IMO you have hit the nail on the head with those questions. At the end of
the day, it is the RP's decision because, IMO, it is ultimately the RP that
bears the consequences of something going wrong.

The interesting direction taken in the GC approach is the RP decides, based
upon the GC standard and its supporting guidance, on their risk tolerance
and categorizes it into a LOA bucket. The standard and guidance
then identifies, based on that categorization, what the RP needs to do to
mitigate that risk. Part of that mitigation could include accepting
assertions from external organizations, such as authoritative parties, who
provide assertions about something. It does not presume that any
authoritative party will provide the "total" assertion. An important part
of the standard is that it does not specify specific authoritative
sources. Rather, it identifies what types of sources and how many of
those sources should be used.

In this context, the answers to Steve's questions are, IMO, rather simple:
- What is something like LOA really for? [[KD: IMO: LOAs are a simple means
of communicating / characterizing a RP's identity assurance risk tolerance.
>From an IdP's perspective, it is a mechanism for
specifying/communicating what mechanisms they have undertaken.]]
- Who uses a simplified "Risk Gauge", and how exactly? [[see above]]
- How much original risk analysis is an RP expected to do before they bin
their situation into Risk Gauge [[KD: IMO a RP should not do any "original"
risk analysis beyond the risk analysis they currently do to identify the
risk of something going wrong based on an incorrect identity. It should be
noted, the GC does not take into account the probability of something going
wrong - they assume it is going to go wrong and identify the consequences
of that happening.]]
- Is using a Risk Gauge supposed to save time in risk analysis? [[KD: No.
Risk analysis still takes the same  amount of time. And it still must be
done.]]
- When an IdP claims a certain Risk Gauge, what does that really mean -
contractually? [[KD: IMO, it means that if an IdP can be shown not to have
done everything that is specified to provide an assertion then they are
liable for all damages. Otherwise, the RP is liable.]]
- If an RP at Gauge X finds an IdP at Gauge X (or higher), what's next? How
much further analysis is needed before the RP can sign up the IdP? [[KD: no
further analysis should be required if the RP can trust that the IdP is
telling the truth. An independent certification by an organization such as
Kantara Initiative could provide that assurance. That being said, the RP
should NOT be expected to use that assertion as the only thing required to
mitigate their identity assurance risk. The RP needs to be in control of
how much they need to do.]]
- If an IdP claims Risk Gauge X, how is that assured? [[KD: as I said
above, a certification by an independent third party could provide
assurance to a RP.]]

What is important, IMO, about the Government of Canada's approach is that
they have looked at the whole situation from the RP's perspective ... From
the RP being in control of their destiny. It is their problem if something
goes wrong. That, and they assume something will go wrong without taking
into account the probability of it occuring - it is of little comfort to
users to have an RP say, after a break, "we considered that risk but did
not think it was too likely to occur."

Ken

On Friday, January 9, 2015, Richer, Justin P. <[email-masked]> wrote:

>  I think that binning risk is part of the issue (as Steve states), but
> it's also (as a corollary) a matter of setting the context of an
> authentication. It's not just about "do I trust the display name" or
> whatever other attribute, but also about communicating to the RP what just
> happened. This can give the RP a chance at correctly deciding what to do
> about it.
>
>  The VoT proposal tries to address this with the two different parts of
> the protocol: the vector as conveyed by the protocol, and the "trust mark
> provider" discovery portion.
>
>  On Jan 9, 2015, at 5:26 PM, Joni Brennan <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>  Apologies if this comment has already been made.  It may also be of use
> to pop up in the stack as well regarding objectives.  One layer abstraction
> On Fri, Jan 9, 2015 at 2:19 PM, <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>>
>>  I suggest that LOAs were intended, net-net, to save time.  It was
>> thought that by binning risk, RPs would be able to short list and then
>> contract with suitable IdPs more quickly.  If there is any time saved in
>> using LOAs then I suspect it gets gobbled up by the negotiating the fine
>> print when signing up an IdP.  The very fact that RPs have asked for "LOA 2
>> and a half" tells us that the RP-IdP negotiation tends to be customised.
>> Than it, LOAs are difficult to standardise.
>>
>>
>> From: "Jim Fenton" <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> To: [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: "Jones, Mark B" <[email-masked]>
Date: Mon, 12 Jan 2015 02:23:57 +0000

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.  

> From: vot [mailto:[email-masked]] On Behalf Of Jim Fenton
> Sent: Friday, January 09, 2015 2:50 PM
> To: [email-masked]
> 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=
> 
each
> of two dimensions: Level of Strength (authentication) and Level of
Reliability
> (attribute binding/proofing).
> 
> 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=

---

From: Jim Fenton <[email-masked]>
Date: Mon, 12 Jan 2015 13:20:36 -0800

Mark,

> specific threats are meant to be addressed by specific vectors.)

You're right, what I wrote doesn't address specific threats at all. But
before doing that, a structure is needed -- that's what I was trying to
address in my proposal. Similarly, M-04-04, the OMB specification that
800-63 responds to, doesn't address specific threats. If this (or any
other) structure looks promising, it will need to be fleshed out in a
document like 800-63 with specific requirements at each level, and an
analysis of what threats are addressed at each.
> those associated with receiving inaccurate attribute assertions.

Perhaps the disconnect here is what is included in the definition of
"attributes" -- I include identifying attributes (name, address, etc.)
as attributes, while others focus on descriptive attributes (student at
some school, veteran status, employment, etc.).  Yes, the threats
associated with credential issuance, etc. are different from those
associated with receiving inaccurate assertions, but the end result is
the same: the transaction is in error. At this level of abstraction, I'm
focused on the result, not (yet) the threats that we need to prevent.
Believe me, I'm not forgetting that.
> 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.
> the PROVIDER to collect and assert good attributes.  

Agree, we will need to describe the threats, but we need to agree on a
direction first.

-Jim

---

From: Eric Goodman <[email-masked]>
Date: Fri, 16 Jan 2015 18:00:20 +0000

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

>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

---

From: "Jones, Mark B" <[email-masked]>
Date: Fri, 16 Jan 2015 20:32:01 +0000

> 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
> 
> >>attributes requested.  So in my view attributes have little to do with
LOA
> discussion.
> 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).

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 16 Jan 2015 20:47:07 +0000

> 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

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.

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

---

From: "Natale, Bob" <[email-masked]>
Date: Sat, 17 Jan 2015 07:10:12 +0000

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.  

each
Reliability

---

From: "Jones, Mark B" <[email-masked]>
Date: Mon, 19 Jan 2015 01:20:56 +0000

> 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.
[Jones, Mark B] 
Communicating an identity (attributes) is not the goal of 800-63.  I think
it makes perfect sense to consider authentication and the communication of
attributes very separately.  I'm not saying that communication of the
'identity' is optional or not important, but that it should be
conceptualized as a very separate process even if it occurs alongside
authentication.  800-63 is not nonsensical, it is just concerned with only
one of two distinct processes.

> > 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.
> 
[Jones, Mark B] 
We just disagree here.  I concede that attributes are essential for
personalization and authorization decisions at the RP, but RPs (especially
those that deal with PHI or other sensitive data) care very much about
authentication.  The fact that an attribute provider has well vetted
attributes about a real, natural person means nothing if that identity is
not strongly bound to the authentication credential.

> > 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.
> 
[Jones, Mark B] 
Though you could make similar statements about authentication, I was talking
about the communication of attributes.  But in both cases, if a RP decides
to accept either an authentication or an attribute, the RP has made a binary
decision to trust that provider.  It does not matter if the authentication
is LOA 1 or LOA 4, the RP has decided to trust the authentication provider
to authenticate the user.  When you say that "not all authentication is
equal" I assume you are talking about LOA.  It is true that after a RP has
trusted an authentication provider to authenticate a user, and after that RP
has trusted the authentication provider to communicate an appropriate
expression of the LOA for that authentication, the RP can use this to decide
if the LOA is sufficient for the access requested.  So even if the user is
turned away by the RP, the RP made that decision based on trust in the
provider.  But if an RP requests attributes that are to be used to make
authorization decisions, the RP should only request such attributes from
providers it trusts and considers to be authoritative.  It does not make any
sense for an attribute provider to offer the same attribute at varying
levels of assurance.  Even if an attribute provider has better vetting
procedures for one attribute over another, it is reasonable to believe that
provider will communicate the best data it has.  I also think that if a RP
has requested the attribute, it has already decided to trust the provider
and decided that the provider's vetting procedures (known or unknown) are
'good enough'.

> > 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.
> 
[Jones, Mark B] 
The way I read this is that your definition of LOA is different than mine.
You seem to focus only on the communication of attributes (which is in line
with your stated view that "authentication means nothing to an app") where I
focus only on authentication.  But if you are concerned about risk
mitigation then I think that is an excellent place to start finding common
ground.  My question to you is, in what way does the communication of any
attribute address any of the threats itemized in 800-63?  It is my opinion
that these threats only apply to authentication and have nothing to do with
how attributes are communicated.   In your view of LOA, what threats are
being mitigated and how?

---

From: "Jones, Mark B" <[email-masked]>
Date: Mon, 19 Jan 2015 16:52:10 +0000

> 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
> 
[Jones, Mark B] 
Agreed.

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 19 Jan 2015 19:59:57 +0000

> attributes very separately.

Then please explain how to communicate the identity of an authenticated subject to somebody else without an attribute (of some kind) to identify them.  That's why they're not separate. The point of the authentication is to communicate an attribute (or more than one) with some assurance behind it. Same as any other attribute use case. They boil down to the same end goal.

> personalization and authorization decisions at the RP

Those are secondary. The primary use case of attributes is to *identify* the authenticated subject in the first place.

> But if an RP requests attributes that are to be used to make
> providers it trusts and considers to be authoritative.

And why does that same logic not hold for the attributes that communicate the identity?

>  It does not make any
> levels of assurance.

Sure it does. If not, it makes no more sense for an identity provider to offer authentication at different levels.

> with your stated view that "authentication means nothing to an app") where
> I focus only on authentication.

If you can tell me how the latter can be communicated without the former, I'll concede the point. If not, my argument is that one boils down to the other, so I don't see the point of treating it separately. What I'm arguing is that the "assurance" one has in identifiers and other "authentication-related" attributes is just a special case of assurance in any other attributes. Any given attribute has a set of risks associated with its promulgation and use. That's all I'm trying to say.

>  But if you are concerned about risk
> attribute address any of the threats itemized in 800-63?

800-63 is dealing with the threats to the accurate determination and communication of a specific set of unnamed attributes. That vagueness is why I have a problem with it.

-- Scott

---

From: "Jones, Mark B" <[email-masked]>
Date: Mon, 19 Jan 2015 23:34:55 +0000

> > Communicating an identity (attributes) is not the goal of 800-63.  I
> > think it makes perfect sense to consider authentication and the
> > communication of attributes very separately.
> 
> Then please explain how to communicate the identity of an authenticated
> subject to somebody else without an attribute (of some kind) to identify
> them.  That's why they're not separate. The point of the authentication is
to
> communicate an attribute (or more than one) with some assurance behind it.
> Same as any other attribute use case. They boil down to the same end goal.
> 
[Jones, Mark B] 
You can't communicate identity without one or more attributes.  
I disagree that the point of authentication is to communicate attributes.
The purpose of authentication, in my opinion, is to connect a remote entity
that is known to the authentication provider with a RP.  Then the
communication of attributes follows.

> > authorization decisions, the RP should only request such attributes
> > from providers it trusts and considers to be authoritative.
> 
[Jones, Mark B] 
If you are not making decisions based on the values then, authoritative or
not, whatever the provider has is likely good enough.

> Sure it does. If not, it makes no more sense for an identity provider to
offer
> authentication at different levels.
> 
[Jones, Mark B] 
We must be miscommunicating on this.  A provider is not going to provide
different RPs different values depending on the LOA requested.

> > You seem to focus only on the communication of attributes (which is in
> > line with your stated view that "authentication means nothing to an
> > app") where I focus only on authentication.
> 
> If you can tell me how the latter can be communicated without the former,
> I'll concede the point. If not, my argument is that one boils down to the
> other, so I don't see the point of treating it separately. What I'm
arguing is
> that the "assurance" one has in identifiers and other "authentication-
> related" attributes is just a special case of assurance in any other
attributes.
> Any given attribute has a set of risks associated with its promulgation
and
> use. That's all I'm trying to say.
> 
[Jones, Mark B] 
Isn't this the extreme privacy preserving use case for Shibboleth?  Isn't
this the library use case minus the affiliation attribute?

> > mitigation then I think that is an excellent place to start finding
> > common ground.  My question to you is, in what way does the
> > communication of any attribute address any of the threats itemized in
800-
> 63?
> 
> 800-63 is dealing with the threats to the accurate determination and
> communication of a specific set of unnamed attributes. That vagueness is
> why I have a problem with it.
> 
[Jones, Mark B] 
800-63 does not specify any requirements for communicating attributes to
RPs.  It specifies identity proofing for the purpose of registration only.
" The registration and identity proofing processes are designed based on the
required assurance level, to ensure that the RA/CSP knows the true identity
of the Applicant."