[DG-IDoT] Common identity standard

Simon Moffatt simon.moffatt at forgerock.com
Tue Jul 28 07:11:43 CDT 2015


Hi Jeff

Comments inline.

Regards, Simon

On 28/07/15 12:22, j stollman wrote:
> Simon,
>
> I am uncomfortable with your assertion,
>
>     The interesting paradox here - which is often overlooked - is that
>     the more that the contextual information is made public, the less
>     likely it is to be faked.
>     For example, I "know" everything there is to know about Justin
>     Bieber - simply by Googling - which ironically makes it incredibly
>     difficult for me to "fake" his identity, as there are several
>     avenues to prove me wrong.
>
>
> I would argue that I could use the public information available for 
> Justin Bieber to begin setting up accounts using his name and identity 
> characteristics that would be under my control.  I could then use 
> these accounts to substantiate the creation of additional accounts and 
> masquerade as Mr. Bieber in various online venues.
On the contrary.  You would not be able to use that information for an 
identity assertion, simply as that information is public - therefore it 
wouldn't be used during verification, making that information 
"unfakeable" - opening a bank account in his name, would trigger more 
stringent checks.
>
> As for the value of relationships, I agree that there is value.  But 
> it can be very difficult to use.  In LinkedIn, for example, when I am 
> looking for a person, I can use relationships to try to narrow down my 
> search.  For example, I can filter based on location (within 50 miles 
> of London) or his current/former employer.  But in searching for 
> people with common names, I often find that this does not help me 
> because I don't know where the person lives or his employment history.
>
I don't think that is a relationship search though?  That is simply 
static assertion matching.  A relationship search would be were tuples 
of information came in play resulting in no search being required.  For 
example if searching LinkedIn, a reference to an unlinked person could 
be more tangible based on that person being previously linked to two 
people you have already linked in with.
> Furthermore, wouldn't using relationships require that we establish 
> database fields for the most common relationships in order to filter 
> on them?  But what fields need to be included?  If we just allow 
> device "owners" to add ten arbitrary fields that they consider most 
> important for their device, won't we be limited the search to exact 
> matches -- eliminating the ability to perform proximity searches.  For 
> example, if I enter the data "2015" would that be the year I deployed 
> the sensor, the altitude of the location of the sensor, or the serial 
> number of the sensor?  If I enter instead "Serial Number = 2015", what 
> will happen if someone seeking out my sensor searches for "Part Number 
> = 2015" of "S/N = 2015"?
Relationship matching is general done using Graphs, not static field 
storage. This can then move towards distributed analysis and identity 
building.
>
> When the sensor changes owners (e.g., company A which owns the sensor 
> is purchased by company B), will the owner be allowed to retain the 
> data fields of the previous owner to keep everyone using the sensor 
> from accessing it?
>
The relationship itself is a first-principal, not an attribute per-se.
> I don't claim that these issues won't have solutions.  But as things 
> get more complicated, the threat surface increases. So there are 
> consequences to this complexity -- whether through human error or evil 
> intent.
>
> Jeff
>
>
>
>
> ---------------------------------
> Jeff Stollman
> stollman.j at gmail.com <mailto:stollman.j at gmail.com>
> 1 202.683.8699
>
> Truth never triumphs — its opponents just die out.
> Science advances one funeral at a time.
>                                   Max Planck
>
> On Tue, Jul 28, 2015 at 4:06 AM, Simon Moffatt 
> <simon.moffatt at forgerock.com <mailto:simon.moffatt at forgerock.com>> wrote:
>
>     Hi Ingo
>
>     I think you make some subtly very powerful points here. Uniqueness
>     by static identifiers is difficult to uphold as you mention. 
>     However, the powerful aspect is the relative context being
>     applied, which results in local uniqueness.
>
>     That context information, such as where you work and your city,
>     not only helps reduce the noise and pollution of unrelated
>     identities, but it also reduces the scope of knowledge to those
>     who know what living in that city or working at that company
>     actually means.
>
>     The interesting paradox here - which is often overlooked - is that
>     the more that the contextual information is made public, the less
>     likely it is to be faked.
>
>     For example, I "know" everything there is to know about Justin
>     Bieber - simply by Googling - which ironically makes it incredibly
>     difficult for me to "fake" his identity, as there are several
>     avenues to prove me wrong.
>
>     The relationship aspect here is what helps not only identifier the
>     person/thing/object but also verify it's existence and thus
>     possible integrity.
>
>     Simon
>
>
>
>     On 27/07/15 19:54, Ingo.Friese at telekom.de
>     <mailto:Ingo.Friese at telekom.de> wrote:
>>
>>     As we have already many IDs outside I doubt that we can propose a
>>     certain GUID. But of course you can use GUID if you need some
>>     kind of ID for your system.
>>
>>     Jeff, uniqueness is most likely not realistic. We don’t have no
>>     governance over all possible IDs. But the nice thing about
>>     identifying things with relationships is that identifier don’t
>>     have to be unique.
>>
>>     There are several “Ingo Friese” outside, but since you know
>>     “works with T-Labs” and “Lives in Berlin” you can find me
>>     regardless of my identifier.
>>
>>     The identifier than is usually mapped to a address (e.g. IP
>>     address). And addresses are unique in their domain.
>>
>>     *From:*j stollman [mailto:stollman.j at gmail.com]
>>     *Sent:* Montag, 27. Juli 2015 20:45
>>     *To:* Ranjan Jain (ranjain)
>>     *Cc:* Friese, Ingo; afesta at alfweb.com <mailto:afesta at alfweb.com>;
>>     dg-idot at kantarainitiative.org <mailto:dg-idot at kantarainitiative.org>
>>     *Subject:* Re: [DG-IDoT] Common identity standard
>>
>>     Ranjan,
>>
>>     What would the GUID be based on?  How would you ensure its
>>     _U_niqueness across industry sectors, across the globe, and over
>>     time?
>>
>>     Jeff
>>
>>
>>     ---------------------------------
>>
>>     Jeff Stollman
>>     stollman.j at gmail.com <mailto:stollman.j at gmail.com>
>>     1 202.683.8699 <tel:1%20202.683.8699>
>>
>>     Truth never triumphs — its opponents just die out.
>>
>>     Science advances one funeral at a time.
>>
>>                                       Max Planck
>>
>>     On Mon, Jul 27, 2015 at 2:41 PM, Ranjan Jain (ranjain)
>>     <ranjain at cisco.com <mailto:ranjain at cisco.com>> wrote:
>>
>>     All great ideas so far.
>>
>>     How about using GUID as the identifier which can be tied to a
>>     “thing” and this GUID can have multiple personas based on the
>>     relationship? Ofcourse we’ll need some kind of discovery service
>>     and the things need to publish their meta data for usage but just
>>     wanted to get initial assessment.
>>
>>     *From: *"Ingo.Friese at telekom.de <mailto:Ingo.Friese at telekom.de>"
>>     <Ingo.Friese at telekom.de <mailto:Ingo.Friese at telekom.de>>
>>     *Date: *Monday, July 27, 2015 at 7:50 AM
>>     *To: *"stollman.j at gmail.com <mailto:stollman.j at gmail.com>"
>>     <stollman.j at gmail.com <mailto:stollman.j at gmail.com>>,
>>     "afesta at alfweb.com <mailto:afesta at alfweb.com>" <afesta at alfweb.com
>>     <mailto:afesta at alfweb.com>>
>>     *Cc: *"dg-idot at kantarainitiative.org
>>     <mailto:dg-idot at kantarainitiative.org>"
>>     <dg-idot at kantarainitiative.org
>>     <mailto:dg-idot at kantarainitiative.org>>
>>     *Subject: *Re: [DG-IDoT] Common identity standard
>>
>>         Hi Jeff,
>>
>>         Regarding point 3. following thoughts:
>>
>>         -The owner, admin, or user of a thing has to trigger an
>>         update…their might be services that do the update on behalf
>>
>>         -In general we need an update mechanism, if e.g. an owner
>>         changes, it should be changed in discovery/search...not a big
>>         deal. Isn’ it?
>>
>>         *From:*dg-idot-bounces at kantarainitiative.org
>>         <mailto:dg-idot-bounces at kantarainitiative.org>
>>         [mailto:dg-idot-bounces at kantarainitiative.org] *On Behalf Of
>>         *j stollman
>>
>>
>>         *Sent:* Freitag, 24. Juli 2015 19:21
>>         *To:* Alessandro Festa
>>         *Cc:* dg-idot at kantarainitiative.org
>>         <mailto:dg-idot at kantarainitiative.org>
>>         *Subject:* Re: [DG-IDoT] Common identity standard
>>
>>         I am with Alessandro in the complexity of this solution in
>>         the real world.
>>
>>          1. An iPhone is a collection of IoT devices (camera, audio
>>             recorder, touch screen, telephone, computer, etc.). 
>>             Should each of these have its own "good key pair"?  If
>>             not how do we handle the sale of just the camera by the
>>             same OEM who sells the camera to Apple?  Do we need a way
>>             to aggregate devices?
>>          2. Separately, what constitutes a "good key pair"?  Will all
>>             of the many unenlightened, non-high-tech manufacturers in
>>             the world participate?  What is the likelihood that they
>>             will create duplicate key pairs when there are billions
>>             of devices?  We tend to consider that we are servicing an
>>             environment where everyone is paying attention to
>>             international standards.  Standards in markets as broad
>>             as we are discussion take decades to become pervasive. 
>>             How many types of screws do we have?  It isn't just
>>             metric versus "standard."  Screws differ in diameter,
>>             pitch, head shape (flat, pan, etc.), and driver type
>>             (straight blade, phillips, head, star, etc.).  And then
>>             there are custom screws. In IoT we will have
>>             hobbyist-types creating devices, along with old-line
>>             manufacturers. It isn't just an Apply and Samsung world.
>>          3. To Ingo's comment about relationships, how do we track
>>             changes in those relationships without creating a massive
>>             infrastructure?  What happens when company A has a device
>>             that is used by employees A1, A2, and A3, sells the
>>             device to company B for use by B7, B8, and B9?
>>
>>         Jeff
>>
>>
>>         ---------------------------------
>>
>>         Jeff Stollman
>>         stollman.j at gmail.com <mailto:stollman.j at gmail.com>
>>         1 202.683.8699 <tel:1%20202.683.8699>
>>
>>         Truth never triumphs — its opponents just die out.
>>
>>         Science advances one funeral at a time.
>>
>>                       Max Planck
>>
>>         On Fri, Jul 24, 2015 at 7:34 AM, Alessandro Festa
>>         <afesta at alfweb.com <mailto:afesta at alfweb.com>> wrote:
>>
>>         Hi Nat,
>>
>>         related to the private key embeded by manufacturer I am
>>         wondering who would embed what in the case of a
>>         multi-manufacturer.
>>
>>         use case:
>>
>>         1) thing created by original manufacturer : embed a priv key
>>
>>         2) thing crafted/customized (oem) by second manufacturer :
>>         embed a priv key
>>
>>         when thing will need to act on behalf I expect to reflect a 1
>>         to many relationship at this point and so I'll need as user
>>         to decide the degree of relationship between the various keys
>>         or only one single key pair will be allowed and this means we
>>         need to define a hierarchical policy to decide who will embed
>>         what.
>>
>>         I immagine an onion ring model based on user consent and
>>         relationship constrain: user to seller, seller to
>>         manufacturer (original or oem), manufacturer (oem) to
>>         manufacturer
>>
>>         Alex
>>
>>         -
>>
>>         Alessandro Festa
>>
>>         website:http://alfweb.com
>>
>>         twitter:@festaatdell
>>
>>         email:afesta at alfweb.com <mailto:email%3Aafesta at alfweb.com>
>>
>>         Il Venerdì 24 Luglio 2015 13:10, Paul Madsen
>>         <pmadsen at pingidentity.com <mailto:pmadsen at pingidentity.com>>
>>         ha scritto:
>>
>>             Hi nat, I would follow on to your steps below
>>
>>             On 7/24/15 4:56 AM, Nat Sakimura wrote:
>>
>>                 Yeah, it is nice, but WSDL would be too big.
>>
>>                 Remember that sending 1 byte over the radio takes as
>>                 much power as encrypting 1000 bytes. Also, memory and
>>                 processing power is becoming cheap, so in IoT
>>                 context, we should probably treat "minimizing the
>>                 radio packet" as the priority.
>>
>>                 As to the identification of the things are cocerned,
>>                 the viable model that I imagine is as follows:
>>
>>                  1. The device manufacutrer creates a good keypair
>>                     and embeds the private key (and its key
>>                     thumbprint) in the device.
>>                  2. For device authentication, use the key to sign
>>                     the message.
>>
>>             When acting on behalf of a user
>>
>>             3. Authenticated user facilitates delivery of tokens to
>>             device
>>             4. Device authenticates to AS using embedded keys in
>>             order to obtain tokens
>>             5. Device uses tokens to authenticate to cloud endpoints,
>>             other device etc
>>
>>             Tokens thereby reflect 'relationship' of user & device
>>
>>             Nat
>>
>>             2015-07-22 1:33 GMT+09:00 Aninda Bhunia
>>             <abhunia at inc38.com <mailto:abhunia at inc38.com>>:
>>
>>             It would be interesting if we could create a standard
>>             that would allow even non IP devices to publish their
>>             identity through a wsdl type structure. Even if they are
>>             non IP at some point in their upwards relationship
>>             hierarchy their master gateway would be IP based and
>>             could be responsible for publishing the identity wsdls
>>             for the entities it brokers.
>>             Thoughts ?
>>
>>             On Jul 21, 2015 11:52 AM, "Joni Brennan"
>>             <joni at kantarainitiative.org
>>             <mailto:joni at kantarainitiative.org>> wrote:
>>
>>             Noting I have no vote =)
>>
>>             I agree with Paul and others regarding discovery as the
>>             key initial mechanism.  I believe Ingo has also noted
>>             this in the summaries from IDoT.  Sal mentions NMAP /
>>             SNMP are there other exiting approaches?  (apologies if
>>             this has been discussed in detail already)
>>
>>             - Joni
>>
>>
>>             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 Tue, Jul 21, 2015 at 8:42 AM, Salvatore D'Agostino
>>             <sal at idmachines.com <mailto:sal at idmachines.com>> wrote:
>>
>>             Other than ip devices?  In that case there are mechanisms
>>             support scanning ( eg NMAP) or SNMP that have been around
>>             for a while these are typically not exactly API friendly
>>             but do provide a starting point and we make good use in
>>             our offerings.
>>
>>             Salvatore D'Agostino
>>
>>             IDmachines LLC |1264 Beacon Street, #5
>>
>>             Brookline, MA. 02446 | USA
>>
>>             http://www.idmachines.com <http://www.idmachines.com/>
>>
>>
>>             On Jul 21, 2015, at 10:46 AM, Paul Madsen
>>             <pmadsen at pingidentity.com
>>             <mailto:pmadsen at pingidentity.com>> wrote:
>>
>>                 (one of) what is needed is a standardized mechanism
>>                 for devices to present their identity (and those
>>                 humans for which they are acting) to other things,
>>                 cloud endpoints & applications
>>
>>                 On 7/16/15 2:38 PM, Ranjan Jain (ranjain) wrote:
>>
>>                     Hey y’all,
>>
>>                     Hope everyone is doing well. Just wanted to
>>                     bounce a question which I’m consistently getting
>>                     asked around Identity, IoT perspective. Is there
>>                     any industry standard in place or in works which
>>                     can be used as a common standard across multiple
>>                     identities. What I mean by this is that humans
>>                     have SSN as an identity while a thermostat may
>>                     have serial number while a network device may
>>                     have a Mac ID as their identity. So, while
>>                     individually they all have their own identity
>>                     standard, when in the IoT world, all these
>>                     entities start interacting with each other, how
>>                     do we translate one identity into another or how
>>                     will one identity interact with another identity
>>                     in a standards way?
>>
>>                     Thanks
>>
>>                     Ranjan
>>
>>
>>                     *Ranjan Jain*
>>                     ARCHITECT.IT <http://architect.it/>
>>                     Information Technology
>>                     ranjain at cisco.com <mailto:ranjain at cisco.com>
>>                     Phone: *+1 408 853 4396
>>                     <tel:%2B1%20408%20853%204396>*
>>                     Mobile: *+1 408 627 9538
>>                     <tel:%2B1%20408%20627%209538>*
>>
>>                     	
>>
>>                     *Cisco Systems, Inc.*
>>                     400 East Tasman Drive
>>                     San Jose
>>                     California
>>                     95134
>>                     United States
>>                     Cisco.com <http://www.cisco.com/>
>>
>>                     	
>>
>>                      Think before you print.
>>
>>                     This email may contain confidential and
>>                     privileged material for the sole use of the
>>                     intended recipient. Any review, use, distribution
>>                     or disclosure by others is strictly prohibited.
>>                     If you are not the intended recipient (or
>>                     authorized to receive for the recipient), please
>>                     contact the sender by reply email and delete all
>>                     copies of this message.
>>
>>                     _______________________________________________
>>
>>                     DG-IDoT mailing list
>>
>>                     DG-IDoT at kantarainitiative.org  <mailto:DG-IDoT at kantarainitiative.org>
>>
>>                     http://kantarainitiative.org/mailman/listinfo/dg-idot
>>
>>                 _______________________________________________
>>                 DG-IDoT mailing list
>>                 DG-IDoT at kantarainitiative.org
>>                 <mailto:DG-IDoT at kantarainitiative.org>
>>                 http://kantarainitiative.org/mailman/listinfo/dg-idot
>>
>>
>>             _______________________________________________
>>             DG-IDoT mailing list
>>             DG-IDoT at kantarainitiative.org
>>             <mailto:DG-IDoT at kantarainitiative.org>
>>             http://kantarainitiative.org/mailman/listinfo/dg-idot
>>
>>
>>             _______________________________________________
>>             DG-IDoT mailing list
>>             DG-IDoT at kantarainitiative.org
>>             <mailto:DG-IDoT at kantarainitiative.org>
>>             http://kantarainitiative.org/mailman/listinfo/dg-idot
>>
>>
>>             _______________________________________________
>>             DG-IDoT mailing list
>>             DG-IDoT at kantarainitiative.org
>>             <mailto:DG-IDoT at kantarainitiative.org>
>>             http://kantarainitiative.org/mailman/listinfo/dg-idot
>>
>>
>>
>>             -- 
>>
>>             Nat Sakimura (=nat)
>>
>>             Chairman, OpenID Foundation
>>             http://nat.sakimura.org/
>>             @_nat_en
>>
>>             _______________________________________________
>>
>>             DG-IDoT mailing list
>>
>>             DG-IDoT at kantarainitiative.org  <mailto:DG-IDoT at kantarainitiative.org>
>>
>>             http://kantarainitiative.org/mailman/listinfo/dg-idot
>>
>>             _______________________________________________
>>             DG-IDoT mailing list
>>             DG-IDoT at kantarainitiative.org
>>             <mailto:DG-IDoT at kantarainitiative.org>
>>             http://kantarainitiative.org/mailman/listinfo/dg-idot
>>
>>
>>         _______________________________________________
>>         DG-IDoT mailing list
>>         DG-IDoT at kantarainitiative.org
>>         <mailto:DG-IDoT at kantarainitiative.org>
>>         http://kantarainitiative.org/mailman/listinfo/dg-idot
>>
>>
>>
>>     _______________________________________________
>>     DG-IDoT mailing list
>>     DG-IDoT at kantarainitiative.org  <mailto:DG-IDoT at kantarainitiative.org>
>>     http://kantarainitiative.org/mailman/listinfo/dg-idot
>
>     -- 
>     ForgeRock <http://www.forgerock.com/> 	*Simon Moffatt*
>     Solutions Director  |  Sales Engineering  | ForgeRock
>     *tel* +44 (0) 7903 347 240
>     <tel:%2B44%20%280%29%207903%20347%20240>  | *e*
>     Simon.Moffatt at Forgerock.com <mailto:simon.moffatt at forgerock.com>
>     *skype* simon.moffatt  | *web* www.forgerock.com
>     <http://www.forgerock.com/>  | *twitter* @simonmoffatt
>
>

-- 
ForgeRock <http://www.forgerock.com/> 	*Simon Moffatt*
Solutions Director  |  Sales Engineering  |  ForgeRock
*tel* +44 (0) 7903 347 240  | *e* Simon.Moffatt at Forgerock.com 
<mailto:simon.moffatt at forgerock.com>
*skype* simon.moffatt  | *web* www.forgerock.com 
<http://www.forgerock.com/>  | *twitter* @simonmoffatt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/dg-idot/attachments/20150728/2dd90e92/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 11225 bytes
Desc: not available
URL: <http://kantarainitiative.org/pipermail/dg-idot/attachments/20150728/2dd90e92/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FR_Sig_Logo.png
Type: image/png
Size: 11225 bytes
Desc: not available
URL: <http://kantarainitiative.org/pipermail/dg-idot/attachments/20150728/2dd90e92/attachment-0003.png>


More information about the DG-IDoT mailing list