Subject: [VoT] Feedback on new Draft

From: Joanne Knight <[email-masked]>
Date: Wed, 9 Sep 2015 04:38:50 +0000

Hi Justin

The document is looking great. I picked up some things that might be hiccups or just me needing more explanation.

Last 2 sentences in introduction – ‘… while the vector itself can be folded into an assurance category. As such the vectors of trust seeks to complement, not replace, these other identity and trust mechanisms.’  Given the problems we are having with ISO/IEC29115 and the fact that I think this model solves many of them, I would like to see that a technology agnostic version of this does in fact replace LoA.

Federated Credential – as yet this is not used in the document. If it were I am unsure that based on the description that the credential is necessarily federated. I am thinking of a privacy centric system where the assertion is unique every instance. Colin may be able to clarify this better than I can. I am pretty sure in our product RealMe our Primary Credential is federatable but not the Assertion….but I may have the wrong end of the stick.

2.1 Identity proofing – in 1.3 it is stated that no aspect of a component should overlap. Given the last sentence of the first para of 2.1 is from my view the correct statement, is the use of ‘..a particular credential set’ out of place? If this refers to a leveraged credential then this may need further explanation.

3 P0-P3 align nicely with thinking in ISO/IEC 29003, many thanks. The others C0-A3 have been written explicitly from the aspect of the Internet, which is understandable given the scope of this document – nicely stated up front. I am interested to see what impact lifting these up to a technology agnostic level will have on the number and description of the component descriptions. This would be a highly valuable exercise that I would dearly like to be involved in ;-)

You have nicely given me confidence that my FRAGGLE is not wingy and can be applied. Great read.

On a totally random (or not) note, I have been playing with an idea I think someone in the VoT mailing group started. I can’t remember who it was but when I remember, I will be in touch. Anywho I replaced ‘identity’ throughout the document with ‘attribute’ and barring a few grammar issues everything still works. Makes me now question what I do for a living ;-)

Cheers

Joanne

From: Justin Richer [mailto:[email-masked]]
Sent: Saturday, 5 September 2015 12:50 p.m.
To: [email-masked]
Subject: [VoT] New Draft

Hi All,

I’ve just published a new draft of VoT, incorporating many of the comments that have come in so far. The basic structure and premise is still there, but hopefully a bit clearer this time around. I’ve added the shell of an IANA registry for vector components. I’ve also added a “credential management” vector component, which is separated out from the “credential strength” component.

The new draft is here:

https://tools.ietf.org/html/draft-richer-vectors-of-trust-01

 — Justin

---

From: [email-masked]
Date: Wed, 9 Sep 2015 15:18:24 +1000 (EST)

Joanne Knight, 9 September, 2015 2:38pm wrote:

> I replaced ‘identity’ throughout the document with ‘attribute’ and
> barring a few grammar issues everything still works.
> Makes me now question what I do for a living ;-)
 
Ok, seriously, when will we come round and do just that - in technical descriptions, dispense with the word "identity"?  We don't need to change our job descriptions or re-badge the "identity management" sector in its entirety but I do think we need to stop saying things like "federate identity" or "provide identity". 
 
The writing is on the wall.  We know "attributes are more interesting than identity" (HT Andrew Nash). The same goes for relationships (witness IRM).  The FIDO Alliance is deliberately not doing identity but only attribute authentication.  There is an identity stack emerging where relationships and abstract identities layered on top of concrete attributes and signals. The problem we're trying to solve is shifting sharply from "Who are you?" to "What are you?". One of my elaborated contributions to this mix is the idea of dropping down a level and federating attributes (see [ http://lockstep.com.au/blog/2012/11/10/forget-identity ]( http://lockstep.com.au/blog/2012/11/10/forget-identity )). 
 
We could resurrect the excellent old APEC definition of Authentication: "the means by which a receiver of an electronic transaction or message makes a decision to accept or reject that transaction or message".  
 
"Identity" is a macro for how a Relying Party knows each Subject. Identification is what an RP does to reach a state where it is comfortable transacting with a Subject.  Identification is just the surface of the relationship between Subject and RP.  The risks of getting identification wrong are ultimately borne by the RP, even if they can be mitigated to some extent through contracts with third parties that have helped the RP do the identification. 
 
All of the most interesting work in IDAM (including VoT, especially VoT) is now about better management of the signals/claims/attributes that go into authentication and identification. 
 
We really should now go the whole way and replace "identity" with "attributes". In particular, there are no "Identity Providers"! They're all just Attribute Providers.  No third party ever actually "provides" a Subject with their identity.  It is the RP that "identifies" a Subject for their (the RP's) purposes.  "Identity" is always provided by the RP. There is a mixed metaphor in the idea of "Identity Provider" and I think it has contaminated IDAM models for a decade.  Just think how much easier it would be to get banks, DMVs, social networks,employers et al to set up modest and pluralist Attribute Providers instead of grandiose and monopolistic Identity Providers!
 
Cheers, 
 
Steve.

Stephen Wilson
Lockstep 
W: http://lockstep.com.au
T: @steve_lockstep
 
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: "Joanne Knight" <[email-masked]>
Sent: Wednesday, 9 September, 2015 2:38pm
To: "'Justin Richer'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [VoT] Feedback on new Draft

Hi Justin

 

 

Cheers
 
Joanne

Hi All,

The new draft is here:

[ https://tools.ietf.org/html/draft-richer-vectors-of-trust-01 ]( https://tools.ietf.org/html/draft-richer-vectors-of-trust-01 )

 — Justin

---

From: Justin Richer <[email-masked]>
Date: Wed, 9 Sep 2015 13:40:39 -0400

Joanne, thanks for the comments. Replies inline.

> On Sep 9, 2015, at 12:38 AM, Joanne Knight <[email-masked]> wrote:
> 
> Hi Justin
>  

I agree that it might replace the way that LoA is getting used in many places, and that’s a good thing indeed. It won’t, however, replace every need for LoA, which does have use in some circumstances. 

> Federated Credential – as yet this is not used in the document. If it were I am unsure that based on the description that the credential is necessarily federated. I am thinking of a privacy centric…

The terminology does need to be better aligned, thanks for that. We’re trying to differentiate between the primary credential — what the user presents to the IdP — and the federated credential — the assertion carried across the network to the RP. 

> 2.1 Identity proofing – in 1.3 it is stated that no aspect of a component should overlap. Given the last sentence of the first para of 2.1 is from my view the correct statement, is the use of ‘..a…

I think you’re right in that seems to have been subsumed by the new credential management (M) component. 

> 3 P0-P3 align nicely with thinking in ISO/IEC 29003, many thanks. The others C0-A3 have been written explicitly from the aspect of the Internet, which is understandable given the scope of this docu…

Definitely interesting work! I think that VoT really does sit in the middle as something that’s technology-focused and sitting between higher descriptive frameworks and detailed attribute-set descriptions.

> On a totally random (or not) note, I have been playing with an idea I think someone in the VoT mailing group started. I can’t remember who it was but when I remember, I will be in touch. Anywho I r…

The problem that I have with that is that it works best if the attributes are clearly bundled, and without that it tends to be extremely difficult to cross security domain boundaries. Basically, it’s not wrong but it can lead to the wrong extremes very quickly.

 — Justin

> https://tools.ietf.org/html/draft-richer-vectors-of-trust-01 <https://tools.ietf.org/html/draft-richer-vectors-of-trust-01>
>  
>  — Justin

---

From: Joanne Knight <[email-masked]>
Date: Wed, 9 Sep 2015 22:00:13 +0000

Some added comments, in line

From: Justin Richer [mailto:[email-masked]]
Sent: Thursday, 10 September 2015 5:41 a.m.
To: Joanne Knight
Cc: [email-masked]
Subject: Re: Feedback on new Draft

On Sep 9, 2015, at 12:38 AM, Joanne Knight <[email-masked]<mailto:[email-masked]>> wrote:

Hi Justin

Could we word it so that it allows replacement rather than excluding it, as it does now.

Yes we definitely need to separate the two. The fact that the term is not used means it has already been described elsewhere in the document as something different. In 2.4 the words ‘Assertion presentation’ and ‘digital identity’ are used.
I toyed with ‘Attribute credential’ but I think the key is the assertion and so ‘Attribute assertion’ or ‘Attribute presentation’ which you used is better. This moves away from any connotation that the ‘thing’ asserted is always the same.

I use the attached diagram (Attributes) a lot. If we are working with the definition of identity being – the minimum set of attributes the uniquely separate one entity from another in a context, and a privacy centric stance where we only collect what we need, then all identity attributes collected also have a secondary purpose.
Identity becomes the just the cognisant understanding that there is a predetermined selection of attributes, otherwise required for the delivery of a service to a customer, that when combined provide a unique reference (ideally without the assigned administrative reference).
Persistent identity – the use of an identical attribute set (or bundle) across contexts is only needed when an RP has to get or verify authoritative attributes from multiple sources. Once RPs are able to access more Ubber Attribute Providers (Intermediaries that federate attributes) their reliance on persistent identity reduces. The Ubber AP is the only one who may need persistent identity). I have attached a table and flow that show this that I have found helpful in dampening the extremes issue. In saying that, for most of the people I am educating that is extreme. Probably preaching to the converted ;-)

Loving your work

Jo

 — Justin

Cheers

Joanne

From: Justin Richer [mailto:[email-masked]]
Sent: Saturday, 5 September 2015 12:50 p.m.
To: [email-masked]<mailto:[email-masked]>
Subject: [VoT] New Draft

Hi All,

The new draft is here:

 — Justin