Authentication and authorization as influences on the content of responses [foaf-dev]

Story Henry henry.story at bblfish.net
Wed Jan 23 14:28:21 GMT 2008


On 22 Jan 2008, at 20:40, Etan Wexler wrote:

> Henry Story (as =93Story Henry=94) wrote to the FOAF developers=92 list  =

> (see <http://lists.foaf-project.org/mailman/listinfo/foaf-dev>) on  =

> 2008-01-13 in =93[foaf-dev] for more information please log in=94
> (<http://lists.foaf-project.org/pipermail/foaf-dev/2008-January/008793.ht=
ml =

> >):
>
>> If a foaf file is to return different representations depending on  =

>> the authentication level of the person looking at it, there needs  =

>> to be some way for the foaf file to say that. Something like: for a  =

>> larger view you may want to log in there: http://...
>> Any thoughts on this?
>
> A FOAF file does not return representations and so cannot return
> different representations. A document that uses terms from the
> Friend-of-a-Friend vocabulary and the document=92s metadata can  =

> constitute
> a representation. An origin server may send a response whose entity is
> such a representation, in which case the entity-body is a FOAF file,  =

> if
> I understand the phrase =93FOAF file=94.

I think you are quibbling here. I suppose to be precise I should have  =

said that a foaf:Document can return a number of representations. In  =

any case a little later in the thread "for more information please log  =

in..."
http://lists.usefulinc.com/pipermail/foaf-dev/2008-January/008820.html
I accepted that the rdfs:seeAlso type technique would be more general  =

allowing the above resource returning multiple representations and  =

allowing a foaf:Document to refer to other documents containing more  =

information.

To copy the relevant example, I am suggesting the following triples in  =

the <public> file:

<public> rdfs:seeAlso <protected> .
<protected> readableBy SomeGroup;
             login [ =3D </login>; a OpenidLoginService ].


> The World Wide Web has mechanisms for authentication, authorization,  =

> and
> access control. I plead the case for using what exists.

Of course by all means we should reuse existing mechanisms.


> I fail to see
> the need for further effort and I offer the following HTTP exchanges  =

> as
> illustration.

These WWW-Authenticate Digests and Realm properties are not very  =

machine readable it seems to me.

You have to imagine a client coming upon the <public> foaf file by  =

following other links on the web. Once it arrives there it GETs  =

<public> and this should tell it where to get more information and  =

which resources are protected. Is this something I can do in a general  =

way with HTTP?

> GET /people/henry/card HTTP/1.1
> Host: bblfish.example
>
> HTTP/1.1 200 OK
> Date: Mon, 14 Jan 2008 02:40:20 GMT
> Last-Modified: Sun, 16 Dec 2007 20:16:33 GMT
> Vary: Authorization
> WWW-Authenticate: Digest nonce=3D"familial nonce 0",
> realm=3D"Henry's stuff for Henry's family",
> domain=3D"http://bblfish.example/people/henry/card",
> Digest nonce=3D"friendly nonce 0",
> realm=3D"Henry's stuff for Henry's friends",

How is a computer program meant to parse that? Will it have to learn  =

english to do this?
Please let me know if I am missing something important. I'd just like  =

to check before I go and read about the spec.

>
> domain=3D"http://bblfish.example/people/henry/card",
> Digest nonce=3D"omniscient nonce 0",
> realm=3D"Henry's stuff for those who see all"
> domain=3D"http://bblfish.example/people/henry/card"
> Etag: "res publica"
> Content-Length: 139
> Content-Type: text/rdf+n3; charset=3Dutf-8
>
> @prefix foaf: <http://xmlns.com/foaf/0.1/>.
>
> <http://bblfish.example/people/henry/card#me>
> a foaf:Person;
> foaf:givenname "Henry".
>
> GET /people/henry/card HTTP/1.1
> Host: bblfish.example
> Authorization: Digest username=3D"friend",
> realm=3D"Henry's stuff for Henry's friends",
> nonce=3D"friendly nonce 0",
> uri=3D"/people/henry/card",
> response=3D"8f8b71112b1a41baec644a503ecd77c7"
>
> HTTP/1.1 200 OK
> Date: Mon, 14 Jan 2008 02:40:21 GMT
> Last-Modified: Sun, 16 Dec 2007 20:16:33 GMT
> Vary: Authorization
> WWW-Authenticate: Digest nonce=3D"familial nonce 1",
> realm=3D"Henry's stuff for Henry's family",
> domain=3D"http://bblfish.example/people/henry/card",
> Digest nonce=3D"friendly nonce 1",
> realm=3D"Henry's stuff for Henry's friends",
> domain=3D"http://bblfish.example/people/henry/card",
> Digest nonce=3D"omniscient nonce 1",
> realm=3D"Henry's stuff for those who see all"
> domain=3D"http://bblfish.example/people/henry/card"
> Etag: "cosa nostra"
> Content-Length: 197
> Content-Type: text/rdf+n3; charset=3Dutf-8
>
> @prefix foaf: <http://xmlns.com/foaf/0.1/>.
>
> <http://bblfish.example/people/henry/card#me>
> a foaf:Person;
> foaf:givenname "Henry";
> foaf:family_name "Story";
> foaf:name "Henry J. Story".
>
> I welcome any corrections to the HTTP messages just given. Most of  =

> all,
> I welcome explanations of deficiencies in the chosen approach.
>
> -- =

> Etan Wexler.
> =93Don=92t misunderestimate the Internets.=94
>
> _______________________________________________
> foaf-dev mailing list
> foaf-dev at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2429 bytes
Desc: not available
Url : http://lists.usefulinc.com/pipermail/foaf-dev/attachments/20080123/79=
eab43b/smime.bin


More information about the foaf-dev mailing list