[VoT] Replace Identity [was: Feedback on new Draft]

[[e-mail]]

 
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" <[e-mail]>
Sent: Wednesday, 9 September, 2015 2:38pm
To: "'Justin Richer'" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: [VoT] Feedback on new Draft




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:[e-mail]] 
Sent: Saturday, 5 September 2015 12:50 p.m.
To: [e-mail]
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 ]( https://tools.ietf.org/html/draft-richer-vectors-of-trust-01 )

 

 — Justin