[foaf-protocols] Sketch of a RESTful photo Printing service with foaf+ssl

[Henry Story]

On 18 Oct 2009, at 17:43, Melvin Carvalho wrote:
> On Sun, Oct 11, 2009 at 11:26 AM, Henry Story <Henry.Story at sun.com>  
> wrote:
>>
>> On 10 Oct 2009, at 15:28, Melvin Carvalho wrote:
>>> On Sat, Oct 10, 2009 at 8:28 AM, Henry Story <Henry.Story at sun.com>  
>>> wrote:
>>>> On 10 Oct 2009, at 07:11, Melvin Carvalho wrote:
>>>>
>>>>> On Wed, Oct 7, 2009 at 9:20 PM, Henry Story  
>>>>> <Henry.Story at sun.com> wrote:
>>>>>>
>>>>>> Hello All,
>>>>>>
>>>>>> I have written up in detail a sketch of what a photo printing  
>>>>>> service
>>>>>> using foaf+ssl could look like. As it required a lot of image
>>>>>> attachments, and hyperlinks I preferred to write about it in  
>>>>>> HTML and
>>>>>> post it on my blog:
>>>>>>
>>>>>>      http://blogs.sun.com/bblfish/entry/sketch_of_a_restful_photo
>>>>>
>>>>> This looks very promising.
>>>>>
>>>>> What is the URI of the new frame in:
>>>>>
>>>>> "3. When you click a button that says "Give Print.com access to  
>>>>> the
>>>>> pictures you wish us to print", a new frame is opened on your web
>>>>> site"
>>>>
>>>> That should be Joe's Contact adder endpoint. So presumably  
>>>> something like
>>>>
>>>> https://joe.eg/addContact
>>>
>>> Are we adding a contact, or access controlling resources?
>>
>> We are doing both. We are adding an ID and giving it certain access  
>> to
>> resources.
>
> Why do we need to do both?  As I understand it the ACL entry would be
> something like:
>
> <print.com> <acl:read> <albumURI>

Here you are doing both too.

What you are suggesting is an option. But we have a few things here  
that are presupposed:
   - The user will publish the name of all the photo albums he has  
visible to all. Perhaps he does not want to do that. Imagine that he  
has a list of music that he only wants his friend to see. The  
information that something is available may be more than he wants to  
reveal.
   - The service has to guess what albums the user wants to print or  
send a large number of requests.

>
> Which would give print.com read access to your album(s) -- Note you
> may have some public albums already with world read access, so
> print.com should be able to find these using semantics and ask you,
> 'Would you like to print any of the following albums' on startup.

Yes, we can imagine this situation, and that would be a different use  
case.
I am trying to solve the use case where the publisher wants to really  
protect his resources. He wants to keep most of his information  
protected. So in that situation we need a way for the user to specify  
on using the service which resources, print.com can access.


> What is the reasoning  behind adding the contact as well as the ACL
> entry?  I'm not saying it's a bad thing, but is it strictly necessary
> for this example?

The service does not know what the resources are that he can or should  
access.

>>
>>> Perhaps adding a contact is as simple as sending a line of sparql
>>> update to the webid.
>>
>> Sending a SPARQL update is an option for adding potential contacts  
>> to an RDF
>> database, but I don't see this being a useful option in this  
>> situation.
>>
>> In a browser based scenario, who would be sending the SPARQL update?
>>
>>        It can't really be Joe's browser. Even if browsers could  
>> send SPARQL
>> updates, they presumably should not do so without the user knowing.  
>> Joe
>> should be able to see information about print.com, and decide what  
>> types of
>> rights he wants to give that service. Making it a SPARQL update  
>> makes it
>> sound a lot to mechanical. Furthermore it seems to be a bit of a  
>> heavy
>> protocol, for something like this. The only type of addition that  
>> would be
>> required by this endpoint is that of adding a new user. It seems to  
>> me that
>> this is exactly what HTTP POST is for: we are creating a new  
>> resource, which
>> is a request for access/contect.
>
> Tabulator, for example, uses SPARUL from the browser via HTTP POST
>
> So for example in this case it could look something like:
>
> INSERT {
>    <print.com> <acl:read> <albumURI>
> }
>
> there is a good question as to who can send, server or browser, i
> think both are viable options.

yes, I'd like to know what the HTTP server sends as a response for not  
inserting now, but putting the information on the QUEUE.

Assuming we have a good answer to the above, one could imagine the  
server sending something like this for the use case I was describing

INSERT {
    <print.com> friendRequest <joe> .
}

>
> I'm not sure if this is too heavy a protocol for the messaging, but I
> am liking the idea of using SPARUL as a messaging system with rich
> sematics, even for example if it's limited to inserting triples.  What
> are the alternatives to this?

HTTP has a very light weight protocols, involving PUT or POST. POST is  
there to create a new resource. So it seems the method most adapted to  
the situation.

The disadvantage of this is that we would have to define the content  
of the message. But perhaps we could define a mapping vocabulary for  
key value pairs sent in a http form post to URI triples.  Then we  
could semantically define the content of the POST, but allow normal  
browser form mechanisms to work. A kind of GRDDL for forms. Servers  
that then also accepted RDF could have the full RDF triples posted to  
that container resource...


>>        If the browser does not seem to be the right tool to send a  
>> SPARQL
>> update, the only other let us consider it being print.com. In that  
>> case the
>> update - which can only be a suggestion of an update btw, as we  
>> don't want
>> any service to update our contacts - would end up on a queue. If  
>> Joe, the
>> user, then ended up going his site to accept and deny certain  
>> contacts, he
>> may end up being confronted with quite a lengthy list of people to  
>> accept or
>> deny. This could sidetrack the user of print.com, who might not end  
>> up
>> having time to print the photos, as he had set out to do.
>
> Yes, this is an issue.  But I think you can (eventually) apply rules
> to the queue, should you chose to maintain one, and perhaps link to
> your desktop.  For example in an IM system you often will get a
> request to your IdP asking, 'Person X wants to be a contact with you'
> Allow/Deny (in some cases it's an auto accept), but you normally will
> get the notification on your client.  I think a queuing mechanism is
> perhaps where we are headed with semantic read/writes.

The idea of using XMPP is appealing. I think this kind of method could  
be very useful for quite a number of similar cases. But if we can do  
the same without XMPP we reduce the dependencies, and so our protocol  
makes less assumptions. But the idea is really good.

>
> Of course you now have the issue of people spamming the queue, so you
> have to use many of the anti spam patterns used today, however you
> also have one big advantage, which is linked open data, to gather
> reputation information.

I like the idea.

But I think if we can do with less to start off with, we have  
something cleaner, and easier to implement. Learning XMPP is one more  
thing for a developer to get to know, and it is not a minor protocol  
addition.

>
>>
>>        So the link from the print.com page to Joe's web site, has  
>> to be one
>> that directs Joe to a page, where Joe can tell his server to accept
>> print.com as a member of a certain group, and give him certain access
>> rights.  (Btw, I don't imagine that Joe would want to add print.com  
>> as a
>> foaf:knows relation in his foaf file). It seems to me that this is  
>> done most
>> easily with a simple POST form.
>
> In this example yes,

ok.

> but as an alternative path in the wider space of
> solutions, a simple approach could be simply to permission print.com
> to have read access to your albums first, then go to print.com, and
> hit the login with webid button, then it'll show you a choice of
> albums to print.

yes, that would also be a solution. In fact both could be combined.

Really what I am trying to do is an semantic version of OAuth. I have  
not studied it yet in detail, so I don't know which use cases we have  
not solved that OAuth does. But if we can solve a major use case with  
just one relation to our system then we have a pretty neat solution. I  
have been told that OAuth is very complex to work with.


>>        Can one open the result of a POST in a new frame?
>>
>>        Henry
>>
>>
>>> Access control is more a case of selecting a set of resources and
>>> GRANTING READ permission on it (for one hour)?
>>
>> Access control is giving some AGENT access to some Resources, for a  
>> specific
>> amount of time.
>>
>>
>>>>
>>>> The URL of print.com would be passed as an argument to the POST or
>>>> perhaps
>>>> even just as an attribute value. So perhaps it should be
>>>>
>>>> https://joe.eg/addContact?id=https://nasdaq.com/co/PRNT&hash;co
>>>>
>>>> Should I make joe's url explicit, in the text? Might make it more
>>>> readable.
>>>
>>> Yes, why not
>>>
>>>>
>>>> Does that make sense?
>>>
>>> Yes
>>>
>>>>
>>>>>
>>>>>>
>>>>>> Looking forward to your comments.
>>>>>>
>>>>>>      Henry