Re: access control -- in or out of scope?

On Thu, 2012-03-29 at 18:05 -0400, Paul Denning wrote:
> 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.

Interesting.  

( As an aside, seeing OMG specs I always get a bit jealous.  Some things
about their specs are so much better than W3C's.   Someday we'll find
the time to improve the usability of ours....   *headshake* )

There's no question that security is important, and that it's doable in
this space.  The question is whether we're ready to define the standard.
My sense is still that we're not.

Personally, I wouldn't be opposed to making a security mechanism
in-scope for this WG on a time-permitting basis, so if it turns out
someone has a solution the WG is happy with, they can go ahead and put
it into their Recommendation.

On the other hand, even if we don't so that, if someone comes up with a
solution everybody likes, it's not that hard to re-charter the group in
place to add something like this.   (It's 2-4 person-weeks of work, and
about two months elapsed - kind of pain, but not nearly as bad as
steering too far the other way, and asking the WG to reach consensus on
something where there is no clear solution -- the group could easily
spin its wheels for many months, if we did that.)

     -- Sandro

> 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 Friday, 30 March 2012 13:12:36 UTC