- From: Paul Denning <pauld@mitre.org>
- Date: Thu, 29 Mar 2012 18:05:53 -0400
- To: <public-ldp@w3.org>
- CC: "Beuchelt, Gerald" <beuchelt@MITRE.ORG>
I suggest taking a look at the security considerations section of the OMG hData RESTful Transport spec [1]. [1] http://www.omg.org/spec/HData/1.0/Beta1/ This uses the HTTP OPTIONS method, and defines an HTTP header, X-hdata-security, to communicate the security mechanisms supported by the endpoint. It specifies several other HTTP headers for other purposes. I noticed that [2], which was recently mentioned on this list, also specifies the use of the HTTP OPTIONS method. The example HTTP response shown at [2] includes some HTTP headers defined by CORS [3], e.g., access-control-allow-headers, and also the link: header (with various @rel values). One of these is rel="describedby", which has been mentioned in the W3C TAG recently in discussing httpRange-14 and UDDP [4]. In the TAG's discussion, it is suggested [5] that it is easier for server admins to configure a new HTTP header than it is to deal with special response numbers, but it does not say anything for or against using the HTTP OPTIONS method. So maybe its okay to suggest that use of HTTP headers is a valid pattern for discovery of security options, but it may be premature to suggest any specific HTTP headers at this time. Also note that [2] specifies the HTTP Digest Authentication. I would think that LDP should support a variety of authentication mechanisms. hData [1] specifies a few mandatory authentication mechanisms that must be implemented, but can be disabled, and the X-hdata-security header to extend the available mechanisms. [2] http://code.google.com/p/callimachus/wiki/REST_API [3] http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html [4] http://lists.w3.org/Archives/Public/www-tag/2012Mar/thread.html [5] http://www.w3.org/wiki/HTML/ChangeProposal25 Paul On 2012-03-19 9:09 AM, Sandro Hawke wrote: > On Sun, 2012-03-18 at 16:28 -0500, Paul Tyson wrote: >> Section 2. Scope. >> >> "The Working Group will not normatively specify solutions for access >> control and authentication for Linked Data. However the Working Group >> will identify, based on a set of real world use cases, requirements for >> necessary authentication and authorization technologies." >> >> I understand how a strict construction of "linked data" would rule this >> out of scope, but realistically no one will be able to champion LDP in >> an enterprise with only a set of "requirements" for the security aspect. >> In the enterprise, security and access control must be built in from the >> ground up, not added as an afterthought. >> >> Industry doesn't need yet another set of requirements for access >> control. There are already several good models: XACML seems the most >> nearly suited for LDP, but there are also RIF and RuleML (and >> LegalRuleML recently started as an OASIS TC). The XACML TC has started >> work on a RESTful profile for XACML. >> >> Please consider upgrading this scope statement from "will >> identify...requirements" to something like "will specify an abstract >> interface and notional architecture by which LDP systems can >> interoperate with RESTful authentication and authorization systems". > > Personally, I agree with you, but I've heard otherwise from some folks. > Maybe people who disagree can speak up and we can try to work this out > here? > > -- Sandro > >> Regards, >> --Paul >> >> On Sun, 2012-03-18 at 12:13 -0400, Sandro Hawke wrote: >>> After various discussions, we've rewritten the Linked Data Platform >>> (LDP) draft charter. New version is here: >>> >>> http://www.w3.org/2012/ldp/charter >>> >>> The diff is linked from there, but only the last few paragraphs >>> (standard charter stuff) are the similar enough for the diff to be >>> useful. >>> >>> At this point, we're expecting to formally propose this to the W3C >>> membership within a week or two, so please review it soon. >>> >>> -- Sandro >>> >>> >>> >> >> >> > > > > . >
Received on Thursday, 29 March 2012 22:06:22 UTC