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

I apologize for not responding sooner to Sandro's request for further
information.

I don't have much of an outline to propose for LDP access control, and
what I do have is rather fuzzy. Note that I'm not a member of the group,
just an interested future user of the LDP.

See [1] for a recent post to the XACML mailing list, in which I listed
some minimum requirements for a RESTful XACML profile. The two main
points are that 1) XACML (or any access control system) runs on rules,
and therefore collections of rules must themselves be treated as REST
resources; and 2) an access control system mediates the hyperlinked
relationships among Web resources--specifically, in the XACML model, a
world consisting of Subjects, Resources, and Actions. The 2nd point
means that everything mentioned in a set of access control rules must be
representable as a web resource.

This is far from a useful, coherent plan. But it is a step beyond just
listing requirements, and indicates one way to use rule-based access
control in a linked data system. I don't mean to prejudice the
discussion towards XACML--it is just what I am familiar with.

Regards,
--Paul

[1] http://lists.oasis-open.org/archives/xacml/201203/msg00000.html

On Fri, 2012-03-30 at 09:12 -0400, Sandro Hawke wrote:
> 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 Saturday, 31 March 2012 00:24:28 UTC