[DG-IDoT] Common identity standard

j stollman stollman.j at gmail.com
Tue Jul 28 06:22:24 CDT 2015


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.

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.

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

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?

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
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>
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 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 <stollman.j at gmail.com>]
> *Sent:* Montag, 27. Juli 2015 20:45
> *To:* Ranjan Jain (ranjain)
> *Cc:* Friese, Ingo; afesta at alfweb.com; 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
> 1 202.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>
> 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" <Ingo.Friese at telekom.de>
> *Date: *Monday, July 27, 2015 at 7:50 AM
> *To: *"stollman.j at gmail.com" <stollman.j at gmail.com>, "afesta at alfweb.com" <
> afesta at alfweb.com>
> *Cc: *"dg-idot at kantarainitiative.org" <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
> <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
> *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
> 1 202.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>
> 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
>
>
>
>
>
> Il Venerdì 24 Luglio 2015 13:10, Paul Madsen <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>:
>
> 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>
> 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
>
> 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>
> 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
>
>
> On Jul 21, 2015, at 10:46 AM, Paul Madsen <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
> Phone: *+1 408 853 4396 <%2B1%20408%20853%204396>*
> Mobile: *+1 408 627 9538 <%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
>
> http://kantarainitiative.org/mailman/listinfo/dg-idot
>
>
>
>   _______________________________________________
> DG-IDoT mailing list
> DG-IDoT at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/dg-idot
>
>
> _______________________________________________
> DG-IDoT mailing list
> DG-IDoT at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/dg-idot
>
>
>
>
> _______________________________________________
> DG-IDoT mailing list
> DG-IDoT at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/dg-idot
>
>
> _______________________________________________
> DG-IDoT mailing list
> 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
>
> http://kantarainitiative.org/mailman/listinfo/dg-idot
>
>
>
>
>
> _______________________________________________
> DG-IDoT mailing list
> DG-IDoT at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/dg-idot
>
>
>
>
> _______________________________________________
> DG-IDoT mailing list
> DG-IDoT at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/dg-idot
>
>
>
>
>
>
> _______________________________________________
> DG-IDoT mailing listDG-IDoT at kantarainitiative.orghttp://kantarainitiative.org/mailman/listinfo/dg-idot
>
>
> --
>   [image: ForgeRock] <http://www.forgerock.com/> *Simon Moffatt*
> Solutions Director  |  Sales Engineering  |  ForgeRock
> *tel* +44 (0) 7903 347 240  |  *e* Simon.Moffatt at Forgerock.com
> <simon.moffatt at forgerock.com>
> *skype* simon.moffatt  |  *web* www.forgerock.com  |  *twitter*
> @simonmoffatt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/dg-idot/attachments/20150728/ab0d0d4d/attachment-0001.html>
-------------- 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/ab0d0d4d/attachment-0001.png>


More information about the DG-IDoT mailing list