Story Henry | 1 Apr 13:17 2008
Picon

[foaf-dev] RDFAuth_Sketch: what are we trying to solve

Dan Brickley asked the following question:
 > I'd like to see a 1 page "here's the problem we're trying to solve"  
that doesn't itself specify any protocol design.
 > Borrowing from Stefan Decker's page at http://www.stefandecker.org/the-heilmeier-catechism.html 
  quoting George Heilmeier:

I had partly answered some of these in the blog post on (the  
controversially named) RDFAuth [1]
But let me organize them as suggested by Dan:

  1. What is the problem, why is it hard?
  ---------------------------------------

The problem can be stated either in general terms as a result of  
requirements on Linked Data or by giving a specific example of a  
Linked Data application. Let me start with a concrete example: Social  
Networks.

In order to break out of the current Social Networking (SN) data  
silos, where each SN is a world into itself and users cannot link to  
users in other SN, we require Linked Data. This can be built using  
vocabularies such as FOAF in an open manner and one can use these to  
build Social Network browsers such as Beatnik [2] and servers such as  
Knowee [3]. Social Networks users though demand some levels of  
privacy. They want some information to be protected, available only to  
subgroups of people, to be determined by them. For example I may only  
wish to allow friends of my friends to have access to my network of  
friends. Strangers may only get my basic business information. Or you  
may wish only members of your (extended) family to have access to your  
family tree.
(Continue reading)

Toby A Inkster | 1 Apr 12:40 2008
Picon

Re: [foaf-dev] Re: RDFAuth: an initial sketch


Story Henry wrote:

> My feeling is that what is needed is to see how this could be made to
> work better with SSL.

I've already posted a message suggesting an HTTPS-based solution.

  Message-ID: <62649.81.2.120.180.1206622777.squirrel <at> goddamn.co.uk>
  Subject: Re: [foaf-dev] Re: privacy and open data
  Date: Thu, 27 Mar 2008 12:59:37 -0000 (UTC)

Summary:

 1. Client requests public FOAF
 2. FOAF contains rdf:seeAlso with URI for HTTPS private FOAF
 3. Client requests private FOAF using a client-side SSL cert
 4. Client includes URI of their public FOAF in HTTP "From" header
 5. HTTPS server requests client's public FOAF file and queries it
    to find client's certificate serial number
 6. Server checks that FOAF serial number matches the request
    cert serial number, thus requesting client really does own
    the FOAF file in HTTP From header
 7. Server makes decision on what information client should be
    shown, based on client's FOAF, and on client's FOAF URI
 8. Server sends client this information as RDF

--

-- 
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
(Continue reading)

Story Henry | 1 Apr 13:45 2008
Picon

Re: [foaf-dev] Re: RDFAuth: an initial sketch

Hi Toby, sorry I missed your previous post. I need to study HTTPS more  
which is why I could not grok it at the time.
I have added a link to both posts in the "history" section of http://blogs.sun.com/bblfish/entry/rdfauth_sketch_of_a_buzzword

Here is your previous post:
    http://www.w3.org/mid/62649.81.2.120.180.1206622777.squirrel <at> goddamn.co.uk

Let me study it now.

	Henry

On 1 Apr 2008, at 12:40, Toby A Inkster wrote:
>
> Story Henry wrote:
>
>> My feeling is that what is needed is to see how this could be made to
>> work better with SSL.
>
> I've already posted a message suggesting an HTTPS-based solution.
>
>  Message-ID: <62649.81.2.120.180.1206622777.squirrel <at> goddamn.co.uk>
>  Subject: Re: [foaf-dev] Re: privacy and open data
>  Date: Thu, 27 Mar 2008 12:59:37 -0000 (UTC)
>
> Summary:
>
> 1. Client requests public FOAF
> 2. FOAF contains rdf:seeAlso with URI for HTTPS private FOAF
> 3. Client requests private FOAF using a client-side SSL cert
> 4. Client includes URI of their public FOAF in HTTP "From" header
(Continue reading)

Anthony Steele | 1 Apr 15:22 2008

Re: [foaf-dev] RDFAuth_Sketch: what are we trying to solve

Story Henry wrote:

 > But instead of requiring an Identity server we use
> PGP asymmetric key cryptography to identify the User Agent Owner.

A point of order: In this context, PGP stands for "Pretty Good Privacy". 
  It is a particular implementation, albeit a groundbreaking one.  GPG 
(http://gnupg.org/ ) is another. I don't want to be tied to an 
implementation when I can use standards.

I see from Wikipedia (http://en.wikipedia.org/wiki/Pretty_Good_Privacy )
that the relevant standard for public-key cryptography is rfc4880 
(http://tools.ietf.org/html/rfc4880 )

If this would be easier to implement for me over openId/OAuth depends on 
the availability of libraries. I haven't had time to look into this or 
the technical merits of the solution yet.

Anthony
Story Henry | 1 Apr 15:48 2008
Picon

Re: [foaf-dev] RDFAuth_Sketch: what are we trying to solve


On 1 Apr 2008, at 15:22, Anthony Steele wrote:
> Story Henry wrote:
>
> > But instead of requiring an Identity server we use
>> PGP asymmetric key cryptography to identify the User Agent Owner.
>
> A point of order: In this context, PGP stands for "Pretty Good  
> Privacy".  It is a particular implementation, albeit a  
> groundbreaking one.  GPG (http://gnupg.org/ ) is another. I don't  
> want to be tied to an implementation when I can use standards.

Yes quite right. I was thinking of any algorithm that would use public  
key encryption, and that would allow a public key to be safely  
published on the web.

As with HTTPS I can imagine that a good protocol would be flexible as  
to which algorithm to use.
Toby Inkster had a some interesting thoughts on how this could relate  
to https

   http://www.w3.org/mid/62649.81.2.120.180.1206622777.squirrel-Uum2ymaEwGoqdlJmJB21zg <at> public.gmane.org

Henry

> I see from Wikipedia (http://en.wikipedia.org/wiki/ 
> Pretty_Good_Privacy )
> that the relevant standard for public-key cryptography is rfc4880
(http://tools.ietf.org/html/rfc4880 
>  )
(Continue reading)

Brad Jones | 1 Apr 16:59 2008

RE: [foaf-dev] RDFAuth_Sketch: what are we trying to solve

May I suggest an interesting (at least to me) project?
http://waterken.sourceforge.net/ . It has some very interesting properties
with respect to RESTful access-control.

Cheers,

Brad Jones

-----Original Message-----
From: foaf-dev-bounces@...
[mailto:foaf-dev-bounces@...] On Behalf Of Story Henry
Sent: April 1, 2008 7:17 AM
To: Semantic Web; foaf-dev Friend of a
Subject: [foaf-dev] RDFAuth_Sketch: what are we trying to solve

Dan Brickley asked the following question:
 > I'd like to see a 1 page "here's the problem we're trying to solve"  
that doesn't itself specify any protocol design.
 > Borrowing from Stefan Decker's page at
http://www.stefandecker.org/the-heilmeier-catechism.html
  quoting George Heilmeier:

I had partly answered some of these in the blog post on (the controversially
named) RDFAuth [1] But let me organize them as suggested by Dan:

  1. What is the problem, why is it hard?
  ---------------------------------------

The problem can be stated either in general terms as a result of
requirements on Linked Data or by giving a specific example of a Linked Data
(Continue reading)

Peter Williams | 1 Apr 17:39 2008

RE: [foaf-dev] RDFAuth_Sketch: what are we trying to solve

The first paragraph had my interest hooked - to half-read the rest! It would be nice to see an academic paper style write-up. Two classical ideas were being played with in a classical setting of massively distributed access control enforcement: (i) capabilities and (ii) temporal references, both in graph-based computing models.

I posted a modern paper from the infamous Mr capability reference monitor himself, John Rushby, that is perhaps a good introduction to a reference monitor design suited to the policy control problem set that FOAF, specifically, faces: http://cid-05061d4609325b60.skydrive.live.com/self.aspx/Public/rushby%20model.pdf . It came from his SRI website, where there is more...

Applied d

iscussion of Lamport's temporal logic of action as an alternative basis for non-interference assertions is at http://cid-05061d4609325b60.skydrive.live.com/self.aspx/Public/oakland96.pdf .

I don't think this community is going to be fazed by the formalism used in these papers.

Peter.

From: Brad Jones
Sent: Tue 4/1/2008 7:59 AM
To: 'foaf-dev Friend of a'
Subject: RE: [foaf-dev] RDFAuth_Sketch: what are we trying to solve

May I suggest an interesting (at least to me) project? http://waterken.sourceforge.net/ . It has some very interesting properties with respect to RESTful access-control. Cheers, Brad Jones -----Original Message----- From: foaf-dev-bounces-RyYwo1q5J+qsOXdr9/+iASST3g8Odh+X@public.gmane.org [mailto:foaf-dev-bounces-RyYwo1q5J+qsOXdr9/+iASST3g8Odh+X@public.gmane.org] On Behalf Of Story Henry Sent: April 1, 2008 7:17 AM To: Semantic Web; foaf-dev Friend of a Subject: [foaf-dev] RDFAuth_Sketch: what are we trying to solve Dan Brickley asked the following question: > I'd like to see a 1 page "here's the problem we're trying to solve" that doesn't itself specify any protocol design. > Borrowing from Stefan Decker's page at http://www.stefandecker.org/the-heilmeier-catechism.html quoting George Heilmeier: I had partly answered some of these in the blog post on (the controversially named) RDFAuth [1] But let me organize them as suggested by Dan: 1. What is the problem, why is it hard? --------------------------------------- The problem can be stated either in general terms as a result of requirements on Linked Data or by giving a specific example of a Linked Data application. Let me start with a concrete example: Social Networks. In order to break out of the current Social Networking (SN) data silos, where each SN is a world into itself and users cannot link to users in other SN, we require Linked Data. This can be built using vocabularies such as FOAF in an open manner and one can use these to build Social Network browsers such as Beatnik [2] and servers such as Knowee [3]. Social Networks users though demand some levels of privacy. They want some information to be protected, available only to subgroups of people, to be determined by them. For example I may only wish to allow friends of my friends to have access to my network of friends. Strangers may only get my basic business information. Or you may wish only members of your (extended) family to have access to your family tree. In order to make privacy controls possible in a Distributed Network, Resource Servers needs a way to identify the User Agent Owner. This has to itself be done in a distributed ( non centralized ) way if we are not to create another bottleneck or control point. A Distributed Social Network such as the one here described will be very decentralized. Every one of Tim Berner's Lee's acquaintances, as described in his foaf file, has a URL on a different domain. If when browsing the network of Tim's acquaintances a User Agent had to log into each service with a new password the software would be of no interest to anyone. So the protocol cannot assume that the initial authentication cost can be large because it can then be recovered over a long session. In fact with protected resources the authentication cost has to be very low, because it may be difficult for a User Agent to know in advance if it has access to a resource or not. The Resource Server may not know the User Agent Owner by name, but may wish to determine whether to allow the User Agent access by understanding the owner's relation to other people in a Social Network. It must be possible for the protocol to find a flexible description of the User Agent Owner. If privacy controls are to be important then one needs to think a little wider. It is not just that the Resource Server wishes to protect information about the Resource Server Owner. The User Agent Owner may also not wish everyone to know what software he is using or whom he is asking protected information about. 2. How is it solved today? -------------------------- I don't think this has been solved today. The closest protocol I know that attempts to create a single sign on is OpenId. It makes it possible for a person to have one single global identifier and log onto any service on the web. The problems of this protocol are ( as described in [1] ) - the cost of authentication is very high. It was designed with the limitations of current web browsers in mind. As a result an authentication request requires the browser owner to log in with his openid. - The information about the User Agent available to the Web Service is quite limited. It can only be property value pairs. Neither is it easily extensible. - It does not work well with Semantic Web standards - It does not fit well into web architecture (REST) - the authentication server, and attribute server are points of control. The owner of these will know what services the User is logging into. Though one can deploy one's own attribute server this is not easy at all. (Many services seem to only accept ids with specific authentication servers) Another protocol, oAuth that has some relevance, requires services to agree before hand on how authorization can work on a case by case basis. This is not realistic in an open distributed social network. Things have to be much more flexible than this. 3. What is the new technical idea; why can we succeed now? ---------------------------------------------------------- As with OpenId we use a URL to identify a Person (or more generally any Agent) globally. But instead of requiring an Identity server we use PGP asymmetric key cryptography to identify the User Agent Owner. This is similar to the mutual authentication using client certificates of https, except that we link the client certificates into a Web Of Trust tied together with Linked Data and we publish the public key at a URL accessible via the User Id. The solution is RESTful and can make use of the Network Effect of Linked Data. We build on well established standards: HTTP for the protocol, REST for the architeture, URI for the naming, RDF for the semantics, PGP for encryption. Why can it succeed now? Semantic Web tools have now grown to be of good enough quality to develop this in pretty much every language and on any platform. The Social Networking Data Silo problem is very real, and will soon be felt by millions of people [4]. These new applications don't need to work around web browser limitations either. These applications can be built from scratch, and so they can develop the protocols that are needed to solve this problem. 4. What is the impact if successful? ------------------------------------ We have the first hyperdata applications for the masses: open distributed social networks browsers and servers. 5. How will the program be organized? ------------------------------------- It has to be open, patent free and open sourceable. The details have to be determined. 6. How will intermediate results be generated? ---------------------------------------------- Beatnik, Knowee, Tabulator, openqabal can be used to test the protocol. 7. How will you measure progress? --------------------------------- By 100s of thousands of users joining the network. 8. What will it cost? --------------------- To be determined by people with some experience in this. Henry Story NOTES ===== [1] http://blogs.sun.com/bblfish/entry/rdfauth_sketch_of_a_buzzword [2] https://sommer.dev.java.net/ search the page for Beatnik [3] http://knowee.org/ [4] http://blogs.sun.com/bblfish/entry/2008_the_rise_of_linked but also the Economist article http://www.economist.com/business/displaystory.cfm? story_id=10880936 _______________________________________________ foaf-dev mailing list foaf-dev-RyYwo1q5J+qsOXdr9/+iASST3g8Odh+X@public.gmane.org http://lists.foaf-project.org/mailman/listinfo/foaf-dev
_______________________________________________
foaf-dev mailing list
foaf-dev@...
http://lists.foaf-project.org/mailman/listinfo/foaf-dev
Story Henry | 1 Apr 19:23 2008
Picon

Re: OpenID + auto-login, was: Re: [foaf-dev] Re: RDFAuth: an initial sketch


On 1 Apr 2008, at 12:33, Benjamin Nowack wrote:
> So, here is a new proposal that I personally think makes more sense
> than inventing a whole new protocol:
>
> We write/tweak
>
> OpenID consumers so that they
> * send headers to advertize their OpenID support
> * follow an agreed-on pattern WRT signing in or that
>   provide (possibly again via an HTTP header) a hint how to
>   initiate the redirect
> * standardize the session instantiation/re-detection (e.g. an
>   agreed-on cookie name) after a successful login
>
> and OpenID Servers that
> * have a standardized and simplified login and redirect-back
>   mechanism

I think the idea of allowing connections via OpenId is a feasible one,  
though clearly a hack on a hack. But why not? This would be a good way  
to show why something like the RDFAuth_Sketch spec [1] is also needed.

So using OpenId will require the client (in Knowee's case the server)  
to know the OpenId username and password, and be entitled to  
automatically fill it in. (I wonder why/how that is more secure than  
having access to a private key?)

It will require us to develop a simple RDF vocabulary so that public  
foaf files can say things like "for more info log in here with your  
openid".

<protected> openid:login <login> .
<login> cookie:name "cookie".

then the client will be able to capture and replay the two redirects  
as a normal web browser would:
    - from the server via the client to the Identity Provider (IdP)
    - from the IdP via the client to the openid login service <login>
then the extra verification from the <login> to the IDP

so the number of connections we have are like this:
   1. client GETs public foaf file
   2. client finds protected resource and requirement to login via  
openid for more info
   3. client sends form with info to <login endpoint> (over SSL)
      and gets a redirect to the IdP endpoint
   4. client sends redirected request to IdP endpoint and received a  
form for username/password (over SSL)
   5. client fills in user name password and send to IdP and gets  
redirected to <login> (over SSL)
   6. client redirects to login  (over SSL)
   6.1 server sends verification request to IdP which returns IdP ok  
response (over SSL?)
   6.2 server sends cookie to client
   7. with session cookie client now asks for the requested resource

There are a lot of TCP requests, 8 to be precise, most of which are  
over SSL, which is a complex protocol, itself involving a lot of  
encryption handshakes. The RDFAuth_sketch [1]  may need only 3 (with  
only one over SSL) and after caching may only need 1 SSL connection  
(no need to fetch the public key or the foaf file again).

In order to reduce the need for clients to make unnecessary  
connections, it would help to have an RDF vocabulary to describe who  
can log into protected resources, so that clients could make some  
estimate of whether they should bother following a link.

 From what is described here, this requires servers to know OpenId,  
and to put this information in their RDF files. Is that all?
Clearly servers that later implement and RDFAuth_Sketch protocol will  
be much faster to interact with.

Henry

[1] http://blogs.sun.com/bblfish/entry/rdfauth_sketch_of_a_buzzword

Attachment (smime.p7s): application/pkcs7-signature, 3283 bytes
_______________________________________________
foaf-dev mailing list
foaf-dev@...
http://lists.foaf-project.org/mailman/listinfo/foaf-dev
Benjamin Nowack | 1 Apr 21:42 2008

[foaf-dev] Re: OpenID + auto-login

On 01.04.2008 19:23:27, Story Henry wrote:
>
>It will require us to develop a simple RDF vocabulary so that public  
>foaf files can say things like "for more info log in here with your  
>openid".
rdfs:seeAlso should be just fine for now, the client app will notice
if a resource is protected, and a site that supports the OpenID extension
to protect it's resources can easily send an HTTP header to indicate 
"more content after login", or point at its login endpoint (but even 
that may not be necessary, see below)

>so the number of connections we have are like this:
[...]

It's a little different. We have access to the openid consumer code and
also to the IdP code, so we can implement things like this (I'm using 
"autoID" as a shortcut for "OpenID + auto-login"):

r1.   the [client app] requests a resource from the [server] and sends
      an autoID header for (possibly protected information)
r1.b  the [server] serves content in case of non-protected resources, 
      or, in case of a protected resource:
r2.   it auto-discovers the IdP via a GET on the OpenID, which is provided
      by the autoID header(s). (The [server] may already have RDF information
      about the requesting app's user, then it can re-use that.)
r1.b  The [server] sends a redirect-to-IdP header to the [client app]
r3.   the [client app] logs into its [IdP] (this needs only to be done
      once a day/week/IdP session lifetime, btw, and only if the [client
      app] is not an IdP itself)
r4.   the [client app] requests the redirect-URL from the IdP (if
      the [client app] is not the IdP as well)
r4.b  The IdP returns the target URL
r5.   The [client app] requests the target URL from the [resource server]
r6.   The [resource server] validates things against the IdP
r5.b  The [resource server] returns the protected content and a session 
      cookie

So, that's 7 request worst-case (the client app didn't send an autoID
header in the first place), 6 requests if the client app is not logged
into it's (remote) IdP, 4 requests when the client app acts as the IdP,
and 3 requests, if the server knows the IdP URL of a given OpenID.

But counting HTTP requests (even if it's 7) is not really the way to 
decide on this, but whether an approach can be successfully implemented 
and deployed (try counting the # of requests in OAuth, and yet will it 
become the standard in Web 2.0 land. My browser needs 50+ requests when
I'm visiting a widget-filled web page). OpenID + auto-login can be 
implemented w/o the need for security experts, by riding the widely 
successful OpenID wave, and w/o much upfront spec discussion (well, 
maybe not if we continue like this..).

>In order to reduce the need for clients to make unnecessary  
>connections, it would help to have an RDF vocabulary to describe who  
>can log into protected resources, so that clients could make some  
>estimate of whether they should bother following a link.
That's premature optimization, I think.

> From what is described here, this requires servers to know OpenId,  
>and to put this information in their RDF files. Is that all?
Servers are compliant OpenID Consumers that also support auto-login
as described above. They send a pre-defined header for protected URLs.

>Clearly servers that later implement and RDFAuth_Sketch protocol will  
>be much faster to interact with.
Again, premature optimization. They will indeed be much faster on the
web because most servers will just say "I don't support PGP".

I'll try to drop out of this discussion here and better try to 
implement a prototype first (not before mid-april, though, as I'm
buried in other work). Things will be easier to explain when there's
running code. 

Oh, and let's please stop calling anything "RDFAuth", for the reasons
that danbri mentioned, and because I think I just dropped the idea. 

Best,
Benji

--
Benjamin Nowack
http://bnode.org/
Peter Ansell | 2 Apr 02:14 2008
Picon

Re: [foaf-dev] Re: RDFAuth: an initial sketch


On 01/04/2008, Toby A Inkster <tai <at> g5n.co.uk> wrote:
>
>  Story Henry wrote:
>
>  > My feeling is that what is needed is to see how this could be made to
>  > work better with SSL.
> I've already posted a message suggesting an HTTPS-based solution.
>
>   Message-ID: <62649.81.2.120.180.1206622777.squirrel <at> goddamn.co.uk>
>   Subject: Re: [foaf-dev] Re: privacy and open data
>   Date: Thu, 27 Mar 2008 12:59:37 -0000 (UTC)
>
>  Summary:
>
>   1. Client requests public FOAF
>   2. FOAF contains rdf:seeAlso with URI for HTTPS private FOAF

Why does FOAF insist on making things non-specific with seeAlso. If
you can make up a term that may be more understandable than ideally
you should. Ie, foaf:restrictedVersion or something like that so
someone knows why on earth they are following the URL and what they
should expect to occur after that given their knowledge of the term.

Peter


Gmane