[foaf-protocols] FOAF+ssl, access control.

Fri Jan 15 11:38:47 CET 2010

The XACML model is as interesting for its protocol and distributed/linking
model as it is for its calculation logic. It's been around for a decade.

Its major problem is like SAML itself it suffered bloat - as the enterprise
API folk got their teeth into the standards making. But, I like its overall
architecture. So, keep the model, strip the bloat down to its minimalist
basis, cast its statements in RDFS, and I guess it will fit the semweb
nicely.  After 20 years, it really does not need yet another academic
research initiative, in what is settled understanding of authorization for
public networks like the web.

What the XACML folks did right is

(a)    Assume that the authorization policy statements of several documents
will be merged in realtime, to create an executable authorization logic

(b)    Assume that the party that does the decision making is distinct from
the party doing the enforcement

(c)    Accept the notion that a graph-reference/URI with role guards is
distinct from the Uri itself, and is known as an "entitlement".

(d)    Work with X.509 authorization certs, so the authz cert can represent
and communicate a decision (and integrate with SSL's support for cert
chains). 

As always the hard part is locating and discovering the several documents
with relevant authorization policy statements. Since the topic is discovery
, all the usual discovery arguments come to the fore. 

I keep being disappointed in the sparql community - for not address
discovery comprehensively. Yet another remote query engine is all well and
good, but what we need is the ability to have a sparql server walk for us
clients the linked graph - using discovery-driven processes (like ENUM, like
XRI, like Google's openid XRD enhancements for cloud endpoint discovery). In
this case, I want to be able to instruct the spaql server to go find the
authorization document I need for my context (and even evaluate the
calculation for me, if appropriate).

From: Melvin Carvalho [mailto:melvincarvalho at gmail.com] 
Sent: Friday, January 15, 2010 1:47 AM
To: Peter Williams
Cc: Story Henry; Michael Hausenblas; foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] FOAF+ssl, access control.

On Fri, Jan 15, 2010 at 1:55 AM, Peter Williams <home_pw at msn.com> wrote:

Talking of authorization logics:

One of the reasons I stay with the .p12 file for keying windows foaf+SSL
principals is that not all principals are using browsers (with HTML
capabilities and keygen power). My work is now focused on service clients
(HTTP servers, generally) calling restful WCF-implemented RESTful services
requiring FOAF+SSL token passing.

Peter do you know much about ACL as used in XACML / SAML?  

Im starting to put the webid into the client cert's CN field, in addition to
the SAN.

The reason for doing this is practical. The Windows (WCF) bindings for X.509
Principals already connect to the existing authorization policy and rule
enforcement apparatus - but the handoff keys off of the first CN in the
subjDN and the cert's fingerprint. There is no obvious way (for lowly me) to
change that and pass in the SAN's URI into the handoff, vs the CN.

-----Original Message-----
From: foaf-protocols-bounces at lists.foaf-project.org
[mailto:foaf-protocols-bounces at lists.foaf-project.org] On Behalf Of Story
Henry
Sent: Thursday, January 14, 2010 12:00 PM
To: Michael Hausenblas
Cc: foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] FOAF+ssl, access control.

On 14 Jan 2010, at 10:18, Michael Hausenblas wrote:
> Michael,
>
>>> P.S> I was trying to find the answers for above within the list and
>>> Internet... Though I saw a peaces related to the topic, I failed to
>>> find the answer.
>>
>> No you are on the bleeding edge here. That is exactly the topic that we
need
>> to look into next. :-)
>
> That's right. Two resources that might be of help to get started are [1]
> (for a broader introduction) and [2] (re RDF policy-based ACL).
>
> Cheers,
>      Michael
>
> [1] http://linkeddata.deri.ie/tr/2009-rw-wod
> [2] http://dig.csail.mit.edu/2009/presbrey/UAP.pdf

Great links Michael. Thanks for reminding me to read them. (I must have put
that on my todo list and had a browser crash at some point...)

> [1] http://linkeddata.deri.ie/tr/2009-rw-wod

Thanks for pointing me back to this again. It is a very interesting paper.
On the topic at hand here though it mostly deals with the issue of updating
data, using RDForms. Whereas what we are looking at here is how to do very
simple access control, so that people can protect their data depending on
who is viewing it. This would allow us to put together services such as
Facebook.

> [2] http://dig.csail.mit.edu/2009/presbrey/UAP.pdf

That is a very important article.

Minor nit:

"Unlike OpenID which limits the user identity to the reputation of HTML tags
in a web site or blog, FOAF+SSL explicitly links FOAF data to the identity
URI allowing access decisions to be drawn from a social network or other
linked data."

That text is a bit difficult to understand... Of course one can in fact use
OpenId (without attribute exchange) in a very similar way to foaf+ssl. The
OpenId page could contain rdfa describing the person and linking to the foaf
network. It's just that it is not used that way... But I think we can change
that by putting a few examples together that do this. :-)

Questions:

1. What would the meta.n3 look like to allow access to
  - members of a group
  - friends of someone's friends
?

2. If one has a public, a private, and a family foaf file
 eg
  foaf.public.n3
  foaf.foaf.n3
  foaf.family.n3
  How does one give access to each of those to a member of each group?

3. What is the best way to do the above?
  My guess is that we should always have a public file (foaf.public.n3)
that has rdfs:seeAlso links to the foaf.foaf.n3 and foaf.family.n3. This
would avoid recursive foaf+ssl logins, where the someone's foaf file
requires the user to authenticate, and the server then needs to get the
client's WebId which itself requires the server to authenticate,....
  But if we have such rdfs:seeAlso links, then we should probably also
describe somehow what the authorisation policies for those files are so that
robots don't need to bother fetching resources which they won't be able to
have access to.

  Henry

_______________________________________________
foaf-protocols mailing list
foaf-protocols at lists.foaf-project.org
http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

_______________________________________________
foaf-protocols mailing list
foaf-protocols at lists.foaf-project.org
http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100115/51a279c0/attachment-0001.htm 