[DG-IDoT] Common identity standard
Ranjan Jain (ranjain)
ranjain at cisco.com
Mon Jul 27 13:41:10 CDT 2015
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] 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 <mailto:email%3Aafesta 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 <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>
>> 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> 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
>>>> Mobile: +1 408 627 9538
>>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/dg-idot/attachments/20150727/5c3496ab/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2225 bytes
Desc: not available
URL: <http://kantarainitiative.org/pipermail/dg-idot/attachments/20150727/5c3496ab/attachment-0001.p7s>
More information about the DG-IDoT
mailing list