Subject: [VoT] Foundational questions of principle

From: [email-masked]
Date: Fri, 10 Oct 2014 07:18:55 +1100 (EST)

First, to introduce myself, I am an identity and privacy researcher, analyst and consultant.  I've been involved in this since 1995, when I cut my teeth in PKI and smartcards (with the early companies that became Baltimore Technologies). Since then I've worked on identity management frameworks, regulations and standards.  
 
I subscribe to the old Italian proverb: "it's nice to trust but better not to".  Words matter and I wonder if we shouldn't be using the word trust so much.  
 
More pragmatically, I note the very strong "Attributes" push of the past 18 months.  Andrew Nash, Anil John, myself and others have written about this.  The FIDO Alliance is all about authentication and attributes, and they purposefully leave "identity" as a matter for others to work out further up the stack. The OID Foundation is promoting an Attributes Exchange Network "AXN" architecture.  New entrants like id.me (an NSTIC pilot participant) talk about attributes and avoid "identity". 
 
I mention all of this as a prelude to suggest that "vector of trust" is synonymous with "attribute". I wonder if it would be clearer to use plain and current language rather than carry forward the fuzzy and I think overly ambitious idea of "trust"? 
 
Finally, I'd like to throw in my abiding concern that LOAs have foundered simply because it's difficult to pigeonhole risk. One party's idea of "medium" risk for instance will rarely map precisely to another's. I think people have been misled into thinking that an "LOA 3" identity should be be able to be used on its face (i.e. will "interoperate") at any "LOA 3" RP. Risk management is not so simple. 
 
The LOA paradigm borrows from Risk Management standards like ISO 31000 which organisations use to plot their own risks internally typically on a five scale (eg Negligible / Low / Medium / High / Grave). But risk management standards require that each organisation calibrates risk in its own business context and according to its own risk appetite. The risk of a firewall breach for example at a startup social media company will be assessed differently by a big listed healthcare company. So organisation A can say the risk of event X is Low but B can say the risk of the same event is Medium.  As a result, LOAs do not inter-operate. They are based on standards meant for intra-organisation risk management, not inter-organisation communication of risk assessments. 
 
So far with VoT we are adding more dimensions to the RPs' generic risk management decision making, and that's great.  But we are still pigeonholing the dimensions.
 
I'm afraid the reality is that risk management will always be done locally.  And so it should be.  When an RP is making the decision to accept or reject a given subject, they will evaluate a range of attributes or signals.  The set of attributes that matters varies from one RP to the next.  I think it's a great idea indeed to create guidance for evaluating attributes, and to coach RPs to look at all sorts of dimensions.  I just don't think it helps anyone to pigeonhole the risk ratings, because across organisations, arguments about the boundaries between LOA 1/2/3/4 (that is, policy mapping) will undo any efficiencies gained from the categorization.  
 
Cheers, 
 
Steve.

Stephen Wilson
Managing Director
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.

---

From: Rainer Hoerbe <[email-masked]>
Date: Thu, 9 Oct 2014 23:33:24 +0200

> I'm afraid the reality is that risk management will always be done locally.  And so it should be.  When an RP is making the decision to accept or reject a given subject, they will evaluate a range…

I agree in principle, but do not follow your conclusion that risk management is only local. Risk assessment is local only, but treatment has non-local properties. 

I agree that the current system of LoAs is broken if used beyond a specific sector, because it is mostly an attempt to manage risk by controlling mitigation across organizations. The detailed obligation of controls between RPs and IDPs has too many permutations and VoT won't radically improve this.

However, a combination of risk transfer and risk mitigation can drastically reduce the number of controls contained in a LoA policy. This is straightforward in a plain commercial environment, less so in highly regulated areas. Laws will always require prescriptive controls, like anti-money laundry rules. The point is to tag a figure to the risk, and leave the details of risk mitigation to the IDP ("You are liable for this login with 100$").

So I am proposing a 3-step approach to resolve the LoA problem:
1. Replace controls by liability where possible
2. Standardize controls and their categories into a catalogue (something like the Kantara IAF service criteria)
3. Define sector-specific policies based on these standardized controls to match additional requirements (e.g. Payment Services Directive, HIPPA, Qualified Signature, you name it). These policies may be subdivided into  levels and vectors. While the policies will not match between sectors, their building block do, thus reducing the effort to map them.

Cheers, Rainer

---

From: [email-masked]
Date: Fri, 10 Oct 2014 10:16:57 +1100 (EST)

Rainer, 
 
I like your approach.  But I think we should review what the objective is of LOAs in general, and question whether or not labeling things by "level" is a useful idea. Yes we need to help organisations better understand and manage authentication risk, but is "LOA" is a necessary output of that process?  Doesn't a four level label over simplify things? I find it's a misleading shorthand that leads people to believe that a given identity can be used at a given RP without any further analysis.  
 
We can do all the things you say below, but stop short of attaching the "level". 
 
Cheers, 
 
Steve.

 
-----Original Message-----
From: "Rainer Hoerbe" <[email-masked]>
Sent: Friday, 10 October, 2014 8:24am
To: "Wilson Stephen" <[email-masked]>
Cc: [email-masked]
Subject: Re: [VoT] Foundational questions of principle

Am 09.10.2014 um 22:18 schrieb [ [email-masked] ]( mailto:[email-masked] ):

 
 
I'm afraid the reality is that risk management will always be done locally.  And so it should be.  When an RP is making the decision to accept or reject a given subject, they will evaluate a range of attributes or signals.  The set of attributes that matters varies from one RP to the next.  I think it's a great idea indeed to create guidance for evaluating attributes, and to coach RPs to look at all sorts of dimensions.  I just don't think it helps anyone to pigeonhole the risk ratings, because across organisations, arguments about the boundaries between LOA 1/2/3/4 (that is, policy mapping) will undo any efficiencies gained from the categorization.  
I agree in principle, but do not follow your conclusion that risk management is only local. Risk assessment is local only, but treatment has non-local properties. 
Yes, the current system of LoAs is broken if used beyond a specific sector, because it is mostly an attempt to manage risk by mitigation. The detailed obligation of controls between RPs and IDPs has too many permutations and VoT won't radically improve this.
However, a combination of risk transfer and risk mitigation can drastically reduce the number of controls contained in a LoA policy, more in a common commercial environment, less so in highly regulated areas. Laws will always require prescriptive controls, like anti-money laundry rules. The point is to tag a figure to the risk, and leave the details of risk mitigation to the IDP. 
So I am proposing a 3-step approach to resolve the LoA problem:
1. Replace controls by liability where possible
2. Standardize controls and their categories into a catalogue (something like the Kantara IAF service criteria)
3. Define sector-specific policies to match additional requirements (e.g. Payment Services Directive, HIPPA, Qualified Signature, you name it). These policies may be subdivided into  levels and vectors.
Cheers, Rainer

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 10 Oct 2014 01:05:01 +0000

On 10/9/14, 7:16 PM, "[email-masked]" <[email-masked]>
wrote:

>
> 
>I like your approach.  But I think we should review what the objective is
>of LOAs in general, and question whether or not labeling things by
>"level" is a useful idea. Yes we need to help organisations better
>understand and manage authentication risk, but is "LOA" is a necessary
>output of that process?  Doesn't a four level label over simplify things?
>I find it's a misleading shorthand that leads people to believe that a
>given identity can be used at a given RP without any further analysis.

I think that taking complex ideas and reducing them to levels is overly
simplifying, and it would be better to just define a schema for attribute
data to express in each area.

But my personal *experience* is that applications won't do the work of
building and enforcing polices around that fine-grained a way of
expressing the information. They don't do it well with user attributes, so
there's even less chance they'd do it with data that isn't even core to
their purpose.

Reducing to levels is a way of splitting the work and pushing more of it
to other parties that care enough to do the work.

Perhaps some of the "vectors" are more amenable to reduction to levels
than others. I tend to agree with others' comments that things like
incident response and the operational maturity issues probably don't
reduce well to levels. So maybe both approaches are needed if there are
concrete justifications for them.

And to be honest, I have a lot more concrete evidence that those
non-linear concepts are of interest to applications than I do most of the
traditional assurance-related vectors. And I think they're *more*
well-defined, not less. Most of the easily linear concepts seem like
solutions looking for a problem to me, with the exception of
authentication quality.

-- Scott

---

From: Ken Dagg <[email-masked]>
Date: Thu, 9 Oct 2014 21:41:48 -0400

Steve,

As we have communicated in the past, I am a strong believer the an LOA
designation is an indication of the processes/mechanisms that an IdP has
undertaken. In other words, it is a communication tool. The choice is the
RPs. That is, an assertion at a specific LOA by an IdP/CSP/AP is one of the
mechanisms a RP should use to offset the authentication risk it has
identified for the service it wants to deliver. In other words, it is the
risk of the RP that is paramount not the claims of
an identity/credential/attribute/token provider.

Like you, I am a strong believer that the determination of whether or not
an identity is good enough is the responsibility of the RP. In my
experience, they make that determination based upon a set of attributes
they believe are necessary. If they trust that an IdP's assertion of
identity covers the attributes they believe are required them they can
accept the assertion. If it doesn't then that have to implement additional
mechanisms to offset the residual risk.

With respect to vectors of trust, I am interested in exploring what they
are and how they can be applied.

Ken

On Thursday, October 9, 2014, <[email-masked]> wrote:

>
>
> First, to introduce myself, I am an identity and privacy researcher,
> analyst and consultant.  I've been involved in this since 1995, when I cut
> my teeth in PKI and smartcards (with the early companies that became
> Baltimore Technologies). Since then I've worked on identity management
> frameworks, regulations and standards.
>
>
>
> I subscribe to the old Italian proverb: "it's nice to trust but better not
> to".  Words matter and I wonder if we shouldn't be using the word trust so
> much.
>
>
>
> More pragmatically, I note the very strong "Attributes" push of the past
> 18 months.  Andrew Nash, Anil John, myself and others have written about
> this.  The FIDO Alliance is all about authentication and attributes, and
> they purposefully leave "identity" as a matter for others to work out
> further up the stack. The OID Foundation is promoting an Attributes
> Exchange Network "AXN" architecture.  New entrants like id.me (an NSTIC
> pilot participant) talk about attributes and avoid "identity".
>
>
>
> I mention all of this as a prelude to suggest that "vector of trust" is
> synonymous with "attribute". I wonder if it would be clearer to use plain
> and current language rather than carry forward the fuzzy and I think overly
> ambitious idea of "trust"?
>
>
>
> Finally, I'd like to throw in my abiding concern that LOAs have foundered
> simply because it's difficult to pigeonhole risk. One party's idea of
> "medium" risk for instance will rarely map precisely to another's. I think
> people have been misled into thinking that an "LOA 3" identity should be be
> able to be used on its face (i.e. will "interoperate") at any "LOA 3" RP.
> Risk management is not so simple.
>
>
>
> The LOA paradigm borrows from Risk Management standards like ISO 31000
> which organisations use to plot their own risks internally typically on a
> five scale (eg Negligible / Low / Medium / High / Grave). But risk
> management standards require that each organisation calibrates risk in its
> own business context and according to its own risk appetite. The risk of a
> firewall breach for example at a startup social media company will be
> assessed differently by a big listed healthcare company. So organisation
> A can say the risk of event X is Low but B can say the risk of the same
> event is Medium.  As a result, LOAs do not inter-operate. They are based on
> standards meant for intra-organisation risk management, not
> inter-organisation communication of risk assessments.
>
>
>
> So far with VoT we are adding more dimensions to the RPs' generic risk
> management decision making, and that's great.  But we are still
> pigeonholing the dimensions.
>
>
>
> I'm afraid the reality is that risk management will always be done
> locally.  And so it should be.  When an RP is making the decision to accept
> or reject a given subject, they will evaluate a range of attributes
> or signals.  The set of attributes that matters varies from one RP to the
> next.  I think it's a great idea indeed to create guidance for evaluating
> attributes, and to coach RPs to look at all sorts of dimensions.  I just
> don't think it helps anyone to pigeonhole the risk ratings, because across
> organisations, arguments about the boundaries between LOA 1/2/3/4 (that is,
> policy mapping) will undo any efficiencies gained from the categorization.
>
>
>
> Cheers,
>
>
>
> Steve.
>
>
>
>
>
> Stephen Wilson
> Managing Director
> Lockstep Group
> http://lockstep.com.au

---

From: Rainer Hoerbe <[email-masked]>
Date: Fri, 10 Oct 2014 09:07:58 +0200

> We can do all the things you say below, but stop short of attaching the "level". 

We shouldn't condemn levels altogether. They do work reasonably well within sectors, such as specific supply chains, payment industry or government-to-government. It is the idea of a cross-sector interoperable LoA that does not scale. My experience from AT e-gov tells me that a larger part of RPs struggles with policies that are more complex than a few pages describing LoA 1-4. 

- Rainer

---

From: "Bouma, Tim" <[email-masked]>
Date: Fri, 10 Oct 2014 10:51:32 -0400

I agree with Ken,

When we developed levels of assurance (here in Canada) we did several things:

·         We defined them as levels of confidence required (Levels 1 through 4)

·         We mapped these levels of confidence to a range of degree of impacts.

·         We then specified separately identity assurance levels and credential assurance levels (and focused on credential first)

·         We also factored out likelihood in the assurance level assessment process. That made the assessments much less subjective.

At the end of the day, as Ken states,  it’s the job the RP to understand their risk (along with likelihood) and to communicate a standardized requirement back to a provider (AP)
The AP is  accountable for providing a very prescribed component that fits into a larger system and a risk environment that they might not have a full view into. The RP may put in provisions to share the risk with the AP, or not but that entirely depends on the arrangement, but at least the RP and AP understand what’s on the table as a starting point.

In Canada, we did that with the credential first, and are now figuring out identity (much harder).

I also agree that ‘identity’ is just a set of attributes –and  these identity attributes can vary between organizations or jurisdictions,

As for the term ‘vectors’, I get the idea, but I think the community will think it’s too technical or esoteric. I like to think of a ‘digital identity’ (or whatever you call it), when it shows up at your digital front door, it is the product of a very long, complex supply chain, fraught with many risks and compromises. I may have confidence in certain pieces of, but other I might not trust at all.

Tim

From: vot [mailto:[email-masked]] On Behalf Of Ken Dagg
Sent: October-09-14 9:42 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [VoT] Foundational questions of principle

Steve,

As we have communicated in the past, I am a strong believer the an LOA designation is an indication of the processes/mechanisms that an IdP has undertaken. In other words, it is a communication tool. The choice is the RPs. That is, an assertion at a specific LOA by an IdP/CSP/AP is one of the mechanisms a RP should use to offset the authentication risk it has identified for the service it wants to deliver. In other words, it is the risk of the RP that is paramount not the claims of an identity/credential/attribute/token provider.

Like you, I am a strong believer that the determination of whether or not an identity is good enough is the responsibility of the RP. In my experience, they make that determination based upon a set of attributes they believe are necessary. If they trust that an IdP's assertion of identity covers the attributes they believe are required them they can accept the assertion. If it doesn't then that have to implement additional mechanisms to offset the residual risk.

With respect to vectors of trust, I am interested in exploring what they are and how they can be applied.

Ken

On Thursday, October 9, 2014, <[email-masked]<mailto:[email-masked]>> wrote:

More pragmatically, I note the very strong "Attributes" push of the past 18 months.  Andrew Nash, Anil John, myself and others have written about this.  The FIDO Alliance is all about authentication and attributes, and they purposefully leave "identity" as a matter for others to work out further up the stack. The OID Foundation is promoting an Attributes Exchange Network "AXN" architecture.  New entrants like id.me<http://id.me> (an NSTIC pilot participant) talk about attributes and avoid "identity".

Cheers,

Steve.

Stephen Wilson
Managing Director
Lockstep Group
http://lockstep.com.au

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 10 Oct 2014 17:28:30 +0000

What we're trying to do with the "Vectors" approach here is to strike a balance between the overly-simplistic "single set of linear levels" approach that LoA gives us (that nobody on this list likes but all agree that apps can actually do some level of processing with it) and the overly-complex "very long complex set of attributes" approach that Tim, Scott, and others have brought up (that seems more expressive and ideal but no app is ever going to make sense of, or even try to). I think it's safe to say that neither extreme works and that a right answer probably lies in the middle.

So that's what this strawman is -- it's simultaneously less complex and more complex than the alternatives. Is it the right cut? Probably not, but it's at least a cutting point that we can push to either side. What I think we need to dutifully avoid is pushing it hard to either end. I really like the notion that even if the combinations of the vector values aren't directly compatible (as Steve says), then the building blocks would at least be comparable, giving a hope of defining a policy to translate between them when needed.

Also, I wanted to key into the fact that there are several independent and orthogonal components here. Maybe it's not a set of levels that are tied together, but I think it is in someway a set of independent *things* that are tied together.

 -- Justin

On Oct 10, 2014, at 10:51 AM, Bouma, Tim <[email-masked]<mailto:[email-masked]>> wrote:

I agree with Ken,

Tim

From: vot [mailto:[email-masked]] On Behalf Of Ken Dagg
Sent: October-09-14 9:42 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [VoT] Foundational questions of principle

Steve,

Ken

More pragmatically, I note the very strong "Attributes" push of the past 18 months.  Andrew Nash, Anil John, myself and others have written about this.  The FIDO Alliance is all about authentication and attributes, and they purposefully leave "identity" as a matter for others to work out further up the stack. The OID Foundation is promoting an Attributes Exchange Network "AXN" architecture.  New entrants like id.me<http://id.me/> (an NSTIC pilot participant) talk about attributes and avoid "identity".

Cheers,

Steve.

Stephen Wilson
Managing Director
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.

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

---

From: [email-masked]
Date: Sat, 11 Oct 2014 14:02:38 +1100 (EST)

We are all agreed of course that RPs need to understand their risks, determine what's needed from any external process of identification or attribute attestation, communicate those needs to candidate APs, and from there, contract an acceptable provider. 

My question is whether or not a pigeonholed LOA helps at any point in this process.  

The devil is in the detail.  To my mind, LOA is an intermediate step that takes a detailed risk analysis, squeezes it into a bin (losing lots of information as a result), which is then used to shortlist candidate providers, before going into detailed due diligence where all those details need to be put back on the table. 

I think we all know by now of cases where RPs have looked at candidate IdPs at a given LOA, and have come up with the request of "LOA two and a half" (this was mentioned at CIS 2014 more than once, and I have seen it first hand in the UK IDAP). 

Clearly what's going on here is an RP's idea of say "LOA 2" differs from a given IdP's idea of LOA 2.  Moreover, the idea of LOA 2 must differ from one IdP to another IdP.  When people ask for "LOA 2.5" what they're asking for is a customised identification.  If LOA 2 isn't what it seems, then there cannot possibly be any such thing as a *standardised* LOA 2.5.  All we will get is fresh calls for "LOA 2.75 please". 

If RPs need to do detailed analysis of authentication needs, and get detailed verification of the actual ID proofing done by IdPs and APs, then I just don't see any point attaching the LOA label along the way.  It's misleading. 

Cheers, 

Steve.

Stephen Wilson
Lockstep 
http://lockstep.com.au

-----Original Message-----
From: "Bouma, Tim" <[email-masked]>
Sent: Saturday, 11 October, 2014 1:51am
To: "Ken Dagg" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [VoT] Foundational questions of principle

I agree with Ken,

Tim

Steve,

Ken

Cheers,

Steve.

Stephen Wilson
Managing Director
Lockstep Group
http://lockstep.com.au

---

From: Anil John <[email-masked]>
Date: Fri, 10 Oct 2014 23:32:03 -0400

It may make sense to look at LOAs as something that is "coarse-grained" and
a starting point.

We all think it is not enough, but in the absence of the Borg showing up to
enforce a collective hive-mind across organizational boundaries, we can
live with it and use it as a starting point for the discussion "What more
do we need in order to let this person in the door?"

And that is where RP implemented compensating controls can play a part. The
challenge is that folks seem to conflate "things needed to ensure
confidence in an identity" with "things needed to mitigate risk in the
transaction" and who is (CSP or RP) responsible for what.

Regards,

- Anil

:- Anil John
:- Making Digital Services Secure and Trustworthy
:- https://blog.aniljohn.com

On Fri, Oct 10, 2014 at 11:02 PM, <[email-masked]> wrote:

>
> We are all agreed of course that RPs need to understand their risks,
> determine what's needed from any external process of identification or
> attribute attestation, communicate those needs to candidate APs, and from
> there, contract an acceptable provider.
>
> The devil is in the detail.  To my mind, LOA is an intermediate step that
> takes a detailed risk analysis, squeezes it into a bin (losing lots of
> information as a result), which is then used to shortlist candidate
> providers, before going into detailed due diligence where all those details
> need to be put back on the table.
>
> I think we all know by now of cases where RPs have looked at candidate
> IdPs at a given LOA, and have come up with the request of "LOA two and a
> half" (this was mentioned at CIS 2014 more than once, and I have seen it
> first hand in the UK IDAP).
>
> Clearly what's going on here is an RP's idea of say "LOA 2" differs from a
> given IdP's idea of LOA 2.  Moreover, the idea of LOA 2 must differ from
> one IdP to another IdP.  When people ask for "LOA 2.5" what they're asking
> for is a customised identification.  If LOA 2 isn't what it seems, then
> there cannot possibly be any such thing as a *standardised* LOA 2.5.  All
> we will get is fresh calls for "LOA 2.75 please".
>
> If RPs need to do detailed analysis of authentication needs, and get
> detailed verification of the actual ID proofing done by IdPs and APs, then
> I just don't see any point attaching the LOA label along the way.  It's
> misleading.
>
> Cheers,
>
> Steve.
>
> Stephen Wilson
> Lockstep
> http://lockstep.com.au
> ·         We then specified separately identity assurance levels and
> credential assurance levels (and focused on credential first)
> ·         We also factored out likelihood in the assurance level
> assessment process. That made the assessments much less subjective.
>
> At the end of the day, as Ken states,  it’s the job the RP to understand
> their risk (along with likelihood) and to communicate a standardized
> requirement back to a provider (AP)
> The AP is  accountable for providing a very prescribed component that fits
> into a larger system and a risk environment that they might not have a full
> view into. The RP may put in provisions to share the risk with the AP, or
> not but that entirely depends on the arrangement, but at least the RP and
> AP understand what’s on the table as a starting point.
>
> I also agree that ‘identity’ is just a set of attributes –and  these
> identity attributes can vary between organizations or jurisdictions,
>
> As for the term ‘vectors’, I get the idea, but I think the community will
> think it’s too technical or esoteric. I like to think of a ‘digital
> identity’ (or whatever you call it), when it shows up at your digital front
> door, it is the product of a very long, complex supply chain, fraught with
> many risks and compromises. I may have confidence in certain pieces of, but
> other I might not trust at all.
>
>
> Tim
>
>
> risk of the RP that is paramount not the claims of an
> identity/credential/attribute/token provider.
>
> Exchange Network "AXN" architecture.  New entrants like id.me<http://id.me>
> (an NSTIC pilot participant) talk about attributes and avoid "identity".
>
>
>
> assessed differently by a big listed healthcare company. So organisation A
> can say the risk of event X is Low but B can say the risk of the same event
> is Medium.  As a result, LOAs do not inter-operate. They are based on
> or reject a given subject, they will evaluate a range of attributes or
> signals.  The set of attributes that matters varies from one RP to the
> [email-masked]

---

From: Colin Wallis <[email-masked]>
Date: Sun, 12 Oct 2014 19:16:46 +0000

Putting this split, back into one thread..
…  and pleading to folks to focus back on the vectors, or aspects, or ‘things’ - whatever we call them – that the RP has an interest in.
Justin is valiantly trying to re-state the purpose of his opening ‘vectors’ strawman – always useful to refresh one’s memory by going back to look at them...
His starting list of vectors was:
Identity Proofing
Credential Strength
Assertion Presentation
Operational Management

If the discussion on LoAs offers any value here, it would be to add some finer grained addition to the above (fairly coarse-grained) list.

There’s already an acknowledgment that Operational Management may be composed of a range of concerns – a mix of context dependent, temporal and static (more vectors?) – that influence the RP’s decision to accept or otherwise, an authenticated identity.

If we got to a point where we could agree on what these vectors are, then we can have the (separate) debate about whether combining them/delineating them in some way is useful/helpful, or not.

Cheers
Colin

From: vot [mailto:[email-masked]] On Behalf Of Richer, Justin P.
Sent: Saturday, 11 October 2014 6:29 a.m.
To: Bouma, Tim
Cc: Ken Dagg; [email-masked]; [email-masked]
Subject: Re: [VoT] Foundational questions of principle

 -- Justin
………………………………………………………….

It may make sense to look at LOAs as something that is "coarse-grained" and a starting point.

We all think it is not enough, but in the absence of the Borg showing up to enforce a collective hive-mind across organizational boundaries, we can live with it and use it as a starting point for the discussion "What more do we need in order to let this person in the door?"

And that is where RP implemented compensating controls can play a part. The challenge is that folks seem to conflate "things needed to ensure confidence in an identity" with "things needed to mitigate risk in the transaction" and who is (CSP or RP) responsible for what.

Regards,

- Anil

:- Anil John

On Fri, Oct 10, 2014 at 11:02 PM, <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,

Steve.

Stephen Wilson
Lockstep
http://lockstep.com.au

I agree with Ken,

Tim

Steve,

Ken

Cheers,

Steve.

Stephen Wilson
Managing Director
Lockstep Group

---

From: Ken Dagg <[email-masked]>
Date: Sun, 12 Oct 2014 17:40:42 -0400

Colin,

Good point to move the thread back to its original topic.

I would suggest that there is one more vector: token proofing. This vector
would be similar in nature to the identity proofing vector only focused on
the token rather than the identity.

I have not had a chance to review the original paper to know what it says
about the other vectors (I am supposed to be on holidays). I am assuming
that Identity Proofing deals with how an Identity is proofed, Credential
Strength deals with the binding of an identity to a token, and Assertion
Presentation deals with what the IdP goes through in order to issue an
assertion. What I believe is interesting is that these vectors are
applicable to any entity that does the work. What is of potential interest
is how they apply to the entity that is the recipient of the output of the
work.

I agree that Operational Management is an interesting, but extremely
important, vector that could have many sub-vectors.

While the LoA discussion seemed to be off track, I would suggest that it is
part of the discussion because LoA (regardless of how many levels) should
be a measure of and a means of communicating how much effort has undertaken
by the party doing the work to the entity that is receiving the output of
that work.

Ken

On Sunday, October 12, 2014, Colin Wallis <[email-masked]> wrote:

> …  and pleading to folks to focus back on the vectors, or aspects, or
> ‘things’ - whatever we call them – that the RP has an interest in.
>
> Justin is valiantly trying to re-state the purpose of his opening
> ‘vectors’ strawman – always useful to refresh one’s memory by going back to
> look at them...
>
> If the discussion on LoAs offers any value here, it would be to add some
> finer grained addition to the above (fairly coarse-grained) list.
>
>
>
> There’s already an acknowledgment that Operational Management may be
> composed of a range of concerns – a mix of context dependent, temporal and
> static (more vectors?) – that influence the RP’s decision to accept or
> otherwise, an authenticated identity.
>
>
>
> If we got to a point where we could agree on what these vectors are, then
> we can have the (separate) debate about whether combining them/delineating
> them in some way is useful/helpful, or not.
>
>
>
> Cheers
>
> Colin
>
>
>
> *From:* vot [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] *On Behalf Of *Richer,
> Justin P.
> *Sent:* Saturday, 11 October 2014 6:29 a.m.
> *To:* Bouma, Tim
> *Cc:* Ken Dagg; [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>; [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> *Subject:* Re: [VoT] Foundational questions of principle
>
>
>
> What we're trying to do with the "Vectors" approach here is to strike a
> balance between the overly-simplistic "single set of linear levels"
> approach that LoA gives us (that nobody on this list likes but all agree
> that apps can actually do some level of processing with it) and the
> overly-complex "very long complex set of attributes" approach that Tim,
> Scott, and others have brought up (that seems more expressive and ideal but
> no app is ever going to make sense of, or even try to). I think it's safe
> to say that neither extreme works and that a right answer probably lies in
> the middle.
>
>
>
> So that's what this strawman is -- it's simultaneously less complex and
> more complex than the alternatives. Is it the right cut? Probably not, but
> it's at least a cutting point that we can push to either side. What I think
> we need to dutifully avoid is pushing it hard to either end. I really like
> the notion that even if the combinations of the vector values aren't
> directly compatible (as Steve says), then the building blocks would at
> least be comparable, giving a hope of defining a policy to translate
> between them when needed.
>
>
>
> Also, I wanted to key into the fact that there are several independent and
> orthogonal components here. Maybe it's not a set of levels that are tied
> together, but I think it is in someway a set of independent *things* that
> are tied together.
>
>
>
>  -- Justin
>
> ………………………………………………………….
>
>
>
> We all think it is not enough, but in the absence of the Borg showing up
> to enforce a collective hive-mind across organizational boundaries, we can
> And that is where RP implemented compensating controls can play a part.
> The challenge is that folks seem to conflate "things needed to ensure
> On Fri, Oct 10, 2014 at 11:02 PM, <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>
> On Oct 10, 2014, at 10:51 AM, Bouma, Tim <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>
>
>  I agree with Ken,
>
>
>
> *From:* vot [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] *On Behalf Of *Ken
> Dagg
> *Sent:* October-09-14 9:42 PM
> *To:* [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> *Cc:* [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> *Subject:* Re: [VoT] Foundational questions of principle
>
>
>
> Steve,
>
>
>
> On Thursday, October 9, 2014, <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>
>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Anil John <[email-masked]>
Date: Sun, 12 Oct 2014 19:22:30 -0400

Thank you Colin for herding the cats (Including myself there)!

I would recommend splitting up the 'Identity Proofing' vector into its
component bits, rather than treating it like the current amorphous blob
that it is right now:

   1. *Identity Resolution* - Establishing the uniqueness of an individual
   within a population
   2. *Identity Validation* - Confirming the accuracy of identity
   information claimed by an individual
   3. *Identity Verification* - Confirming that the claimed identity
   information is linked to the individual making the claim

Regards,

- Anil

:- Anil John

On Sun, Oct 12, 2014 at 3:16 PM, Colin Wallis <[email-masked]>
wrote:

> *From:* vot [mailto:[email-masked]] *On Behalf Of *Richer, Justin P.
> *Cc:* Ken Dagg; [email-masked]; [email-masked]
> On Oct 10, 2014, at 10:51 AM, Bouma, Tim <[email-masked]> wrote:
>
>
>
>  I agree with Ken,
>
>
>
> *From:* vot [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Ken Dagg
> *Cc:* [email-masked]

---

From: Ken Dagg <[email-masked]>
Date: Sun, 12 Oct 2014 19:28:25 -0400

Anil,
Do you think that these could be sub vectors of the Identity Proofing
vector?
Ken

On Monday, October 13, 2014, Anil John <[email-masked]> wrote:

>    1. *Identity Resolution* - Establishing the uniqueness of an
>    individual within a population
> On Sun, Oct 12, 2014 at 3:16 PM, Colin Wallis <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> Also, I wanted to key into the fact that there are several independent
>> and orthogonal components here. Maybe it's not a set of levels that are
>> tied together, but I think it is in someway a set of independent *things*
>> that are tied together.
>>
>>
>>
>>  -- Justin
>>
>> ………………………………………………………….
>>
>>
>>
>> Clearly what's going on here is an RP's idea of say "LOA 2" differs from
>> a given IdP's idea of LOA 2.  Moreover, the idea of LOA 2 must differ from
>> The AP is  accountable for providing a very prescribed component that
>> fits into a larger system and a risk environment that they might not have a
>> full view into. The RP may put in provisions to share the risk with the AP,
>> or not but that entirely depends on the arrangement, but at least the RP
>> and AP understand what’s on the table as a starting point.
>>
>>
>>
>> I subscribe to the old Italian proverb: "it's nice to trust but better
>> not to".  Words matter and I wonder if we shouldn't be using the word trust
>> so much.
>>
>>
>>

---

From: Anil John <[email-masked]>
Date: Sun, 12 Oct 2014 19:36:20 -0400

Ken,

I think it depends on if the intention is to keep the 'vectors' flat or
they can have some sort of an hierarchy.  If the latter, sure.

Regards,

- Anil

Regards,

- Anil

:- Anil John

On Sun, Oct 12, 2014 at 7:28 PM, Ken Dagg <[email-masked]> wrote:

>>> If we got to a point where we could agree on what these vectors are,
>>> then we can have the (separate) debate about whether combining
>>> them/delineating them in some way is useful/helpful, or not.
>>>
>>>
>>>
>>> Cheers
>>>
>>> Colin
>>>
>>>
>>>
>>> The devil is in the detail.  To my mind, LOA is an intermediate step
>>> that takes a detailed risk analysis, squeezes it into a bin (losing lots of
>>> As for the term ‘vectors’, I get the idea, but I think the community
>>> will think it’s too technical or esoteric. I like to think of a ‘digital
>>> *From:* vot [mailto:[email-masked]] *On Behalf Of *Ken Dagg
>>> Like you, I am a strong believer that the determination of whether or
>>> not an identity is good enough is the responsibility of the RP. In my
>>> Finally, I'd like to throw in my abiding concern that LOAs have
>>> foundered simply because it's difficult to pigeonhole risk. One party's
>>> idea of "medium" risk for instance will rarely map precisely to another's.
>>> I think people have been misled into thinking that an "LOA 3" identity
>>> should be be able to be used on its face (i.e. will "interoperate") at any
>>> "LOA 3" RP. Risk management is not so simple.
>>>
>>>
>>>

---

From: Colin Wallis <[email-masked]>
Date: Mon, 13 Oct 2014 01:50:44 +0000

<<I think it depends on if the intention is to keep the 'vectors' flat or they can have some sort of an hierarchy>>.
I think that is a ‘tbd’ Anil.
We may have a better idea once the concept is developed a bit further.
Good fine graining on Identity Proofing there..  useful.

Looking below at Ken’s response:
To Ken’s suggestion qualified by his question/assumption..
<< Credential Strength deals with the binding of an identity to a token>>
.. is along the lines Justin described it IMHO, so yea, I think ‘token proofing’ could be another vector/sub vector.

To the comment about the value of/measurement of vectors and.
<<how they apply to the entity that is the recipient of the output of the work>>
..(typically the RP I guess) then we come back to some machine process-able way that the RP can express the vector values of the risk of that authentication instance/service/transaction which, as Steve indicates, might possibly be different for each and every transaction/location/context.

Justin offered up a kind of codified way of expressing specific vector values with a marker letter and category number (saml md iop has for some time now as Scott mentioned), but the trick would be  to make a distinction between what vector values the RP requires (a vector/sub vector), and what is ‘on offer’ from provider parties (another vector/sub vector), but still in a codified way consumable by all parties. Reducing this down from a complex set of values, to 3-5 Vectors, with multiple sub vectors *and* make it meaningful and process-able, is one mother of a challenge..

But already we have moved beyond the pretty blunt instrument that is LoA.. and have not yet gone to the other extreme end of the (‘all fine grained/de-composed’) spectrum, so that is good.

Who knows how much progress we could make if we keep thinking… ☺

Cheers
Colin

From: vot [mailto:[email-masked]] On Behalf Of Anil John
Sent: Monday, 13 October 2014 12:36 p.m.
To: Ken Dagg; [email-masked]
Subject: Re: [VoT] Foundational questions of principle

Ken,

I think it depends on if the intention is to keep the 'vectors' flat or they can have some sort of an hierarchy.  If the latter, sure.

Regards,

- Anil

Regards,

- Anil

:- Anil John

On Sun, Oct 12, 2014 at 7:28 PM, Ken Dagg <[email-masked]<mailto:[email-masked]>> wrote:
Anil,
Do you think that these could be sub vectors of the Identity Proofing vector?
Ken

On Monday, October 13, 2014, Anil John <[email-masked]<mailto:[email-masked]>> wrote:
Thank you Colin for herding the cats (Including myself there)!

I would recommend splitting up the 'Identity Proofing' vector into its component bits, rather than treating it like the current amorphous blob that it is right now:

  1.  Identity Resolution - Establishing the uniqueness of an individual within a population
  2.  Identity Validation - Confirming the accuracy of identity information claimed by an individual
  3.  Identity Verification - Confirming that the claimed identity information is linked to the individual making the claim

Regards,

- Anil

:- Anil John

Colin,

I would suggest that there is one more vector: token proofing. This vector would be similar in nature to the identity proofing vector only focused on the token rather than the identity.

I have not had a chance to review the original paper to know what it says about the other vectors (I am supposed to be on holidays). I am assuming that Identity Proofing deals with how an Identity is proofed, Credential Strength deals with the binding of an identity to a token, and Assertion Presentation deals with what the IdP goes through in order to issue an assertion. What I believe is interesting is that these vectors are applicable to any entity that does the work. What is of potential interest is how they apply to the entity that is the recipient of the output of the work.

I agree that Operational Management is an interesting, but extremely important, vector that could have many sub-vectors.

While the LoA discussion seemed to be off track, I would suggest that it is part of the discussion because LoA (regardless of how many levels) should be a measure of and a means of communicating how much effort has undertaken by the party doing the work to the entity that is receiving the output of that work.

Ken

On Sun, Oct 12, 2014 at 3:16 PM, Colin Wallis <[email-masked]<mailto:[email-masked]>> wrote:

Cheers
Colin

From: vot [mailto:[email-masked]] On Behalf Of Richer, Justin P.
Sent: Saturday, 11 October 2014 6:29 a.m.
To: Bouma, Tim
Cc: Ken Dagg; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [VoT] Foundational questions of principle

 -- Justin
………………………………………………………….

Regards,

- Anil

:- Anil John

Cheers,

Steve.

Stephen Wilson
Lockstep
http://lockstep.com.au

I agree with Ken,

•         We defined them as levels of confidence required (Levels 1 through 4)

•         We mapped these levels of confidence to a range of degree of impacts.

•         We then specified separately identity assurance levels and credential assurance levels (and focused on credential first)

•         We also factored out likelihood in the assurance level assessment process. That made the assessments much less subjective.

Tim

Steve,

Ken

Cheers,

Steve.

Stephen Wilson
Managing Director
Lockstep Group

---

From: Ken Dagg <[email-masked]>
Date: Mon, 13 Oct 2014 06:18:51 -0400

Colin,
See in line.
Ken

On Monday, October 13, 2014, Colin Wallis <[email-masked]> wrote:

>  <<I think it depends on if the intention is to keep the 'vectors' flat
> or they can have some sort of an hierarchy>>.
>
> .. is along the lines Justin described it IMHO, so yea, I think ‘token
> proofing’ could be another vector/sub vector.
>
>
>
> ..(typically the RP I guess) [[KD: my reason for using entity was that RP
> is often seen as the service delivery agent. I wanted to be sure that an
> IdP that is relying on an AP is also included.]] then we come back to some
> machine process-able way that the RP can express the vector values of the
> risk of that authentication instance/service/transaction which, as Steve
> indicates, might possibly be different for each and every
> transaction/location/context.
>
>
>
> Justin offered up a kind of codified way of expressing specific vector
> values with a marker letter and category number (saml md iop has for some
> time now as Scott mentioned), but the trick would be  to make a distinction
> between what vector values the RP requires (a vector/sub vector), and what
> is ‘on offer’ from provider parties (another vector/sub vector), but still
> in a codified way consumable by all parties. Reducing this down from a
> complex set of values, to 3-5 Vectors, with multiple sub vectors **and**
> make it meaningful and process-able, is one mother of a challenge..
>
>
>
> But already we have moved beyond the pretty blunt instrument that is LoA..
> and have not yet gone to the other extreme end of the (‘all fine
> grained/de-composed’) spectrum, so that is good.
>
>
>
> Who knows how much progress we could make if we keep thinking… J
>
>
>
> Cheers
>
> Colin
>
>
>
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] *On Behalf Of *Anil
> John
> *Sent:* Monday, 13 October 2014 12:36 p.m.
> *To:* Ken Dagg; [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> On Sun, Oct 12, 2014 at 7:28 PM, Ken Dagg <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> Anil,
>
> On Monday, October 13, 2014, Anil John <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> While the LoA discussion seemed to be off track, I would suggest that it
> is part of the discussion because LoA (regardless of how many
> levels) should be a measure of and a means of communicating how much effort
> has undertaken by the party doing the work to the entity that is receiving
> the output of that work.
>
>
>
> Ken
>
>
>

---

From: Anil John <[email-masked]>
Date: Sun, 19 Oct 2014 14:02:10 -0400

At the level of 'foundational principles' which should be delivery channel
and technology neutral while being relevant across jurisdictions, this
simple framework by Tim Bouma which focuses on 'What is a Trusted Identity
and What does it take to Federate it?' may be helpful:

https://blog.aniljohn.com/2014/10/a-simple-framework-for-trusted-identities.html

Regards,

- Anil

:- Anil John

On Mon, Oct 13, 2014 at 6:18 AM, Ken Dagg <[email-masked]> wrote:

>> But already we have moved beyond the pretty blunt instrument that is
>> LoA.. and have not yet gone to the other extreme end of the (‘all fine
>> *From:* vot [mailto:[email-masked]] *On Behalf Of *Anil John
>> I would suggest that there is one more vector: token proofing. This
>> vector would be similar in nature to the identity proofing vector only
>> focused on the token rather than the identity.
>>
>>
>>

---

From: Leif Johansson <[email-masked]>
Date: Sun, 26 Oct 2014 14:25:04 +0100

> We shouldn't condemn levels altogether. They do work reasonably well
> within sectors, such as specific supply chains, payment industry or
> government-to-government. It is the idea of a cross-sector interoperable
> LoA that does not scale. My experience from AT e-gov tells me that a
> larger part of RPs struggles with policies that are more complex than a
> few pages describing LoA 1-4. 

One of the many upsides of the Justin Richer proposal is that it allows
both aggregated "levels" as well as expressions of level-by-vector.

The name "vectors of trust" was chosen with a tip-o-the-hat to a part
of mathematics called linear algebra.

For those of you who remember your college math, a vector is the sum of
linear eigenvectors: v = t*x + s*y. In our world the x and y are Justins
base criteria (identity proofing, credential strength etc) and v becomes
the aggregate level.

Don't beat me up over the math now folks, its an analogy !

We should be thinking about this as a meta-model for assurance to be
extended both by organizations like Kantara and NIST who will craft
audit criteria to go with the eigenvectors but also probably by groups
that want to add additional *dimensions* to the algebra of trust.
	
	Cheers Leif

---

From: [email-masked]
Date: Tue, 28 Oct 2014 03:01:12 +1100 (EST)

I definitely agree that the things we need to know about someone in order to create an "identification" in a particular context are vector-like. That's a much better way of thinking about things than the old one dimensional (scalar) LOA. 

I have written about this previously, invoking spider diagrams to illustrate the "surface" created by a digital identity when composed of a set of attributes:

http://lockstep.com.au/blog/2012/08/25/surfacing-identity

I just don't think it's useful to label these things "vectors of trust" when they're attributes.  There is a strong push towards attributes thinking across the identity community.  I think "vectors of trust" is potentially confusing, when the great ideas under VoT could get even more traction if the words you used resonated with current developments in FIDO, AXN etc.   

Cheers, 

Steve.

Stephen Wilson
Managing Director
Lockstep Group
Phone +61 (0)414 488 851
http://lockstep.com.au

-----Original Message-----
From: "Leif Johansson" <[email-masked]>
Sent: Monday, 27 October, 2014 12:25am
To: [email-masked]
Subject: Re: [VoT] Foundational questions of principle

	
	Cheers Leif

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 27 Oct 2014 17:04:48 +0000

On 10/27/14, 12:01 PM, "[email-masked]" <[email-masked]>
wrote:
>
>I just don't think it's useful to label these things "vectors of trust"
>when they're attributes.  There is a strong push towards attributes
>thinking across the identity community.  I think "vectors of trust" is
>potentially confusing, when the great ideas under VoT could get even more
>traction if the words you used resonated with current developments in
>FIDO, AXN etc.   

Even a simple number or a simply-encoded set of scalars is an attribute in
the most general sense. But if you're saying that developers are
increasingly wanting and willing to consume very fine grained information
about people and context, I can't match that with my experiences dealing
with vendors and developers.

-- Scott

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 27 Oct 2014 17:25:05 +0000

I agree with Scott -- using the "attributes" language directly here makes it too easy to just throw bags of values around in a way that's completely overwhelming and not interoperable. I think we need something between the single scalar of LoA and the "anything goes here" world of ABAC-in-extremis. Something that developers can actually do some processing on.

 -- Justin

---

From: [email-masked]
Date: Tue, 28 Oct 2014 04:27:19 +1100 (EST)

Scott, 

I certainly wouldn't disagree with your experience, if you say you don't see developers wanting to consumer fine grained information about users. 

What developers *want* is simple signals, like "you can trust Alice because IdP A says she's been identified". 

But these determinations by IdPs are breaking down, because the fine grained information that the IdPs consumes in order to make an "identification" doesn't align with what RPs really need to know.  *Someone* needs to look at the fine grained information.  "Policy mapping" is the exercise that's been tried over and over through history, where typically an IdP tries to make a generic examination of fine grained information sufficient on behalf of a whole class of RPs and applications.  But the devil is in the detail, and for higher risk transactions (classically "LOA 3" or "LOA 4") generic Policy Mapping proves impossible. So LOA 4 RPs tend to issue and use identities themselves.  (if there is an example of an LOA 4 RP accepting an LOA 4 identity on its face, I have yet to see it).  The time it would take to painstakingly review an IdP's fine grained information and sign off that what the IdP does is fit for the RP's purpose is simply greater than the effort of the RP doing the identity checking for itself. 

I conclude that the only practical way to externalise Identity proofing for higher risk transactions will be to look at the fine grained attributes and federate them at a lower level (see my CIS 2014 talk http://lockstep.com.au/library/identity_authentication/authn-family-tree). 

All of which is to say I agree wholeheartedly with the thrust of the VoT work.  We do need to expose the fine grained information that goes into identity determinations.  I just wish we would all congregate around the idea of attributes.  It was one of the best things in the Laws of Identity - the definition of Identity as a set of attributes.  Let's stick to that concept. 

Cheers 

Steve.

-----Original Message-----
From: "Cantor, Scott" <[email-masked]>
Sent: Tuesday, 28 October, 2014 4:04am
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [VoT] Foundational questions of principle

-- Scott

---

From: [email-masked]
Date: Tue, 28 Oct 2014 04:35:25 +1100 (EST)

I wrote a long response to Scott's point while you were responding. 

I won't say much more except to observe that interoperability of what an IdP says about a Subject and what the RP needs to know about that Subject only occurs at the lower attribute level.  So somewhere in the attributes/identity supply chain, detailed examination does have to take place.  The idea of vectors shows that there are a great many things to look at.  That's goodness.  I get that developers don't want to do the examination but someone has to, and for high risk transactions, someone representing the RP needs to sign off at design time on the actual attribute choice (that is, the RP needs to sign off that the way "identification" is done by IdP A is okay). 

I wonder if perhaps "attributes" is loaded with meanings that I haven't come across myself.  The term as matter of plain English, and as used in the Laws of Identity, seems fine to me. 

I haven't had to work much in ABAC.  Justin, the way you refer to it suggests maybe it's become a problem?

Cheers, 

Steve.

Stephen Wilson
Lockstep 
http://lockstep.com.au

-----Original Message-----
From: "Richer, Justin P." <[email-masked]>
Sent: Tuesday, 28 October, 2014 4:25am
To: "Cantor, Scott" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [VoT] Foundational questions of principle

 -- Justin