Things Discovery Authorization

From Web of Things Interest Group

Note: current contents present an initial draft state. They serve the discussion in the WoT IG

Authorization of things discovery is addressed in liasion between [TF-DF] and [IG-SP]. Note that authorization is not meant as an end in itself here but a means to address common concerns such as:

  • Privacy for individual users e.g. protecting things discovery in a home environment
  • Secrecy for legal entities e.g. protecting things discovery in an industrial environment

Problem Statement

TODO, inputs:

Let’s have a casual look at some of the options:

  • Thing is a consumer good, owner of to-be-discovered devices is an individual. During the discovery operation this actor is present and attentive i.e. a part of the communication loop (because she/he triggered the discovery)
  • Do it in style of the OAuth authz code trick. Note that the OAuth authz code trick requires the ability to authn the owner as well as the caller i.e. does not cover the case of alien callees
  • Thing is a capital good, owner of the to-be-discovered devices is a legal entity. There are admins/operators but during discovery operation none of these actors is present or attentive.
  • Do it in style of the enterprise-IT trick i.e. assume that the caller must have onboarded with the enterprise, hence is equipped with some credentials, metadata is (structurally) known and reflected in the authz policy that is used to decide about the discovery call/request

So we seem to have 2 broad cases:

  • Caller is no alien i.e. somehow known to the callee or its supporting infrastructure
  • Caller is an alien i.e. unknown to the callee and its supporting infrastructure
  • Note that “caller is an alien” means an alien to the callee. In cross-domain cases, the caller may be no alien in an origin domain but an alien to the target domain (which exposes means for things discovery)

The first case is addressed by prior art i.e. ingredients are known and the remaining task mostly is to pick the right pieces and assemble them to a solution that is accepted by the stakeholders in a community or a relevant subset (can still be a tough one)

The second case seems to be either at the boundary or even beyond the most prior art mechanisms. If that case plays a (major) role in [TF-DI] I suggest to first have a screening of the known approaches in security and esp. authz with respect to their ability to cover this case. One thing that comes to my mind and that may show similarities is the protection of dynamic OAuth 2.0 client

So as a next step I suggest to have a conversation between [TF-DI] and [IG-SP] to see whether discovery is case i (more or less straight-forward) and/or case ii (not straight-forward in my opinion). Another step is to double-check the "protection style" attribution made below

TODO: incorporate WebFinger (RFC 7033) and esp. its section 6 "Access Control"

State-of-the-Art

IoT/WoT Perspective

This section starts with well-known approaches for things discovery and checks their coverage of authorization. This reflects the items in Discovery Categories and Tech Landscape and adds an attribution "protection style" to them (might be merged into #1 Wiki page later on)

Finding things around me

  • Optical markers
    • Protection style: physical proxyimity/optical access
  • NFC
    • Protection style: physical proxyimity/network access
  • Markerless recognition
    • Protection style: TBD
  • UriBeacon (Google's Physical Web)
    • Protection style: TBD
  • iBeacon (Apple)
    • Protection style: TBD

Finding things on my network

  • mDNS (+ DNS-SD)
    • Protection style: TBD (RFCs 6762 and 6763 are silent about authorization, info seems to be available to arbitrary callers [open, public])
  • SSDP
    • Protection style: TBD (draft-cai-ssdp-v1-03 is silent about authorization)
  • WS-Discovery
    • Protection style: TBD (wsdd-discovery-1.1-spec-os.html has a security model and security consideration but seems to ignore authorization. Since the security mechanisms focus on XML Signature, an approach that might have been presented [if authorization would have been elaborated] is to rely on some trusted introducer [PKI service components])
  • XMPP Service Discovery
    • Protection style: TBD (xep-0030.html mentions but does not elaborate on authorization, xep-0115.html is silent on authorization)

Searching in Directories

  • CoRE Resource Directory
    • Protection style: TBD (draft-shelby-core-resource-directory mentions but does not elaborate on authorization)
  • XMPP IoT Discovery
    • Protection style: TBD (xep-0347.html is silent about authorization)
  • SPARQL Endpoints
    • Protection style: TBD (REC-sparql11-overview-20130321 is silent about authorization)
  • Research article: "Mobile digcovery: A global service discovery for the IoT"
    • Protection style: TBD (no access to paper)
  • Research article: "A discovery service for smart objects over an agent-based middleware"
    • Protection style: TBD (no access to paper)
  • Research article: "A Semantic Enhanced Service Proxy Framework for Internet of Things"
    • Protection style: TBD (no access to paper)

Searching across Peers

  • Research article: "A Scalable and self-configurable architecture for service discovery in the IoT"
    • Protection style: TBD (no access to paper)

Accessing thing metadata

  • CoRE Link Format
    • Protection style: TBD (RFC 6690 mentions but does not elaborate on authorization)
  • HATEOAS
    • Protection style: TBD
  • SOS
    • Protection style: TBD

My current finding is: things discovery proposals tend to ignore authorization, at most mention it without elaboration. Hence we either have no problem at all ("things discovery authorization" a fata morgana?) or a big problem (largely unexplored terrain)

IT-Security Perspective

This section starts with well-known approaches for authorization and checks their fitness for things discovery

OAuth

In the common OAuth exchanges, clients need to authenticate themselves in order to request access tokens from an OAuth authorization server. This does not help in things discovery cases where there is no a priori knowledge between things offering discovery and their infrastructure as well as their peers. This concerns following grant types: authorization code, ROPC and client credentials (RFC 6749).

The grant type implicit (RFC 6749) addresses a specific situation (browser-based apps that present so-called public clients) that does not reflect common things discovery needs (TBD with [TF-DI]).

This leaves SAML bearer (RFC 7522), JWT bearer (RFC 7523) as well as the concept of initial access tokens (RFC 7591). TODO: further assessments - see Problem Statement above for inputs on applicable criteria (many approaches assume things in style of caller must have onboarded with the enterprise, hence is equipped with some credentials, metadata is (structurally) known and reflected in the authz policy that is used to decide about the discovery call/request)

OAuth-for-CoAP

The OAuth 2.0 IoT Client Credentials Grant requires clients to authenticate themselves by means of DTLS client authentication in order to request access tokens from an OAuth authorization server. This does not help in things discovery cases where there is no a priori knowledge between things offering discovery and their infrastructure as well as their peers.

UMA-for-CoAP

TODO

DCAF

TODO

CoRE Authz

TODO

Next Steps

Conf Call on 2015-08-27

To-be-elaborated:

  1. Problem statement (incl. characteristics of discovery that are important for autorization - such a priori knowledge that system components may have from another)
  2. State-of-the-art from IoT/WoT perspective: start with well-known approaches for discovery and check their coverage of authorization
  3. State-of-the-art from IT-security perspective: start with well-known approaches for authorization and check their fitness for discovery

Proposed approach/timeline:

  • 1-3 are suggested to be done until the next F2F
  • Then review/discuss and
  • agree on subsequent steps 4... based on the commonly agreed/discussed understanding of the findings 1-3
Retrieved from "https://www.w3.org/WoT/IG/wiki/index.php?title=Things_Discovery_Authorization&oldid=2294"