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

Melvin Carvalho melvincarvalho at gmail.com
Mon Nov 2 17:21:17 CET 2009


On Mon, Oct 19, 2009 at 8:05 PM, Henry Story <Henry.Story at sun.com> wrote:
> 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.

In pics: http://documentation.fring.com/images/1/11/Oauth_diagram.png

>
>
>>>       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
>
>


More information about the foaf-protocols mailing list