EIC 2014: The Web of Identities

Here are my notes from the European Identity Conference 2014 in Munich.

Floor conversation with Kantara.org

  • Most of the online advertisement $ are complete waste
  • Distinguishing between verifiable vs aspirational attributes of identity
  • Currently advertisement is targeting verifiable attributes
    • which is why you get offers to hiking gears AFTER booking a hiking trip
  • But much more valuable are aspirational identity attributes
    • to offer you mountain gear BEFORE you book a hiking trip

Floor conversation with Software AG

  • Replacing all existing Software AG ESB’s with new Universal Message Bus in the future
  • Universal Message Bus got acquired through My-Channels
  • My-Channels was originally targeted towards high-speed financial trading platforms but is now used by Software AG as new ESB across all verticals
    • Supports MQTT

Identity and Wearables

  • Authentication:
    • 1 Factor: you know
    • 2 Factor: you know, you have
    • 3 Factor: you know, you have, you are
  • Future possibility: you wear, you are (externally), you are (internally), you feel
  • More: Who are you sitting next to? Where have you been in the last 6 months? How have you slept (pilot, truck driver, etc)
  • Dynamic, context-based authentication

Identity and IoT (Ping Identity)

  • Identity is the new Perimeter
  • From SAML to OpenID Connect
  • Between Network and Application Layer should be a SCALABLE and SECURE Identity Layer containing
    • Discovery
    • Identification
    • Security
    • Privacy
  • Identity Platform:
    • Spanning cloud and IoT
    • Identity Function API
    • Multi-Protocol

Identity and IoT (Dt Telecom)

  • Sensor data collection from Claas Harvesters
  • Fleet and crop management for agriculture across value chain
    • Harvesting
    • Transport
    • Processing
    • Storage
  • Challenges:
    • Object Identifier + Namespaces
    • Harvester is usually rented for limited time by individual farmer
    • Trucks are scheduled from common pool
  • Exploring use of XRI: xri:construction.org(urn:yellow truck:serial:12345)

User Managed Access - UMA (Kantara.org)

  • ownership and identity relationships
  • Owner/user/adminstrator vs the thing
  • Identity lifecycle - Spanning from minutes to years
  • Data governance:
    • Owner and user have different claims to data of Thing depending on where they are (Regulations)
    • Proposed configurable data ‘claims’ approach

MQTT (Software AG)

  • MQTT integrated in Universal Message Bus
    • 15 protocol commands, fixed 2 byte overhead
    • 3 levels of QoS: at most once, at least once, once and only once
    • 256 MB max payload
    • Over TCP
  • MQTT-SN extended for for lossy wireless applicationn
    • Over UDP
    • Suitable for low bandwidth, high latency, high link failure
    • Extended with discovery, advertising
  • First MQTT interop test at EclipseCon in March 2014
  • Broker-based architecture with eventual connectivity
  • MQTT relies on Gateways

MQTT (IBM)

  • MQTT implementer is responsible for security
  • Security guidance in spec:
  • physical security (tamper-proofing) and protocol security along following dimensions
    • Identify and authorize user and device
    • Idenitify and authorize MQTT server
    • Authorize of client access to server and topic
    • Integrity and Privacy of communication
    • One or two-way TLS authentication
  • Rule-based authentication policies on MQTT server due to potentially large number of clients
  • Registration of MQTT client with server contains identity info (HR: combine with device fingerprinting)

Floor conversation on MQTT alternatives

  • XMPP
    • has lots of extensions which are sometimes poorly defined or interpreted differently or never made it as spec
    • Interoperability is a challenge
    • No discovery or negotiation about which extensibility points are used
      • requires all clients to talk the same
      • based on another conversation with Michael Holdmann this capability does exist in XMPP:
Clients can discover other clients' capabilities through Entity Capabilities (XEP-0115).

This information is typically sent automatically in the presence packets, so
capabilities for the clients in use by roster contacts are gathered during
the login phase when presence is exchanged.  For non-roster clients, queries
can be sent directly if necessary.  Once capabilities are known, clients can
determine how to deal with each other.
  • Coap
    • Relies on DTLS for security
    • DTLS requires certificates
    • Bootstrapping problem of how to get certificates into client in the first place