Opened 11 years ago

Closed 11 years ago

#189 closed protocol enhancement (fixed)

Access control

Reported by: zach@… Owned by: zach@…
Priority: minor Milestone:
Component: link-format Version:
Severity: - Keywords:
Cc:

Description

From Richard Barnes:

This document defines a format for describing a list of resources linked from a server, e.g., an HTTP or CoAP server. The document suggests the use of TLS or DTLS on the underlying transport for transport security. My only remaining security concern is that there could be access control concerns as well. For example, a server might not authorize all clients to see all services, or might provide some clients with different levels of access (e.g., read vs. read/write). The document already envisions that the list of links will have some dynamism, allowing for filtering based on link attributes. I would suggest simply noting that servers may want to support HTTP, CoAP, or [D]TLS client authentication and adaptation of the list of returned links based on the client's identity and authorizations.

Suggested text for Section 6:
"
Some servers may provide resource discovery services to a mix of clients that are trusted to different levels. For example, a lighting control system might allow any client to read state variables, but only certain clients to write state (turn lights on or off). Servers SHOULD support authentication features of the underlying transport protocols (HTTP, CoAP, or DTLS/TLS) and allow operators to return different lists of links based on a client's identity and authorization.
"

Change History (2)

comment:1 Changed 11 years ago by cabo@…

Re the proposed text:

  • define "operators"
  • the SHOULD probably should be limited to servers that have authentication and authorization features in the first place.
  • authorization may differentiate between the privilege to see the existence of a resource and the privilege to read it

➔ "reflect their authorization features in what links are visible to a specific client based..."

comment:2 Changed 11 years ago by zach@…

  • Resolution set to fixed
  • Status changed from new to closed

Done. The following text was added:

Some servers may provide resource discovery services to a mix of clients that are trusted to different levels. For example, a lighting control system might allow any client to read state variables, but only certain clients to write state (turn lights on or off). Servers that have authentication and authorization features SHOULD support authentication features of the underlying transport protocols (HTTP or DTLS/TLS) and allow servers to return different lists of links based on a client's identity and authorization.

Note: See TracTickets for help on using tickets.