[DG-IDoT] Common identity standard

Salvatore D'Agostino sal at idmachines.com
Tue Jul 21 12:40:46 CDT 2015


Agree publishing on behalf is sketchy.  Though at some point delegation has to be dealt with.

 

Maybe common registration endpoint for the constellation of devices and functions?  If you have an UMA authZ mgr, how about introducing them as UMA resources everything is a resource (maybe or not resource server in some cases they may/also be clients to use the registration endpoint).   So this is registration which is one way to do discovery in the sense you start by solving discovery (for however long tbd). 

 

On the discovery front still like the idea of being able to scan an identifier space where they could exist, assume you can manage the protocol, and then you have shared information requisite to your relationship, some might be public and not need the keyring.   As well as the identifier/relationship/shared resources tuple defined by the key, you could further leverage them as UMA token(s)  (snuck IRM in there as well..;-)

 

From: dg-idot-bounces at kantarainitiative.org [mailto:dg-idot-bounces at kantarainitiative.org] On Behalf Of afesta at alfweb.com
Sent: Tuesday, July 21, 2015 12:42 PM
To: Aninda Bhunia; Joni Brennan
Cc: dg-idot at kantarainitiative.org
Subject: Re: [DG-IDoT] Common identity standard

 

Publishing on behalf of another thing sounds not appealing to me.

In the end if the primary identity has no viable way to publish I cannot control its identity either so why I should publish itinerary behalf?

On non-ip based communication I am thinking more at communication based on keyring type of membership so I may expose my identity only to those things who are  member of the same keyring (and so the transport become less interesting).

 

 

Alex 

Alessandro Festa
web:http://alfweb.com
twitter:@festaatdell
mail:afesta at alfweb.com

 





On Tue, Jul 21, 2015 at 9:33 AM -0700, "Aninda Bhunia" <abhunia at inc38.com> wrote:

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

 

 

 



  <http://www.cisco.com/web/europe/images/email/signature/est2014/logo_08.png?ct=1408129135253> 


Ranjan Jain
ARCHITECT.IT
Information Technology
 <mailto:ranjain at cisco.com> 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
 <http://www.cisco.com/> Cisco.com

	
	

 


  <http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif>  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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/dg-idot/attachments/20150721/6fe793d6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5548 bytes
Desc: not available
URL: <http://kantarainitiative.org/pipermail/dg-idot/attachments/20150721/6fe793d6/attachment-0001.bin>


More information about the DG-IDoT mailing list