Re: PROV-ISSUE-618 (pingback-in-prov-aq): Should pingback be described in PROV-AQ? [Accessing and Querying Provenance]

Stian,

I still need to do a careful review of your comments, but would not be opposed to your idea to "trim down" what can be posted.
By only accepting the values of the hasProvenance links that could appear elsewhere, it aligns with the rest of the document much more cleanly.
It also avoids the authoritativeness issue that you point out.
And, if "my server" wanted to offer up a small RDF graph around the "downstream" resource, then it could go fetch and select what it wants to re-host on its own.

So, can we resolve the issue by restricting what can be POSTed to the ping back URI (to only values of hasProvenance)?

Best,
Tim



On Feb 1, 2013, at 11:48 AM, Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk> wrote:

> On Thu, Jan 31, 2013 at 6:50 PM, Timothy Lebo <lebot@rpi.edu> wrote:
>> Following up from today's call, what is Stian's proposal?
>> I must admit that I have been following each of his feedback emails.
> 
> Well if you followed those emails, it should be clear! ;-))
> 
> The proposal is from my review at
> http://lists.w3.org/Archives/Public/public-prov-wg/2013Jan/0121.html
> 
> 
> My proposal is that the pingback works like a 'send me a URL' thing,
> just like a pingback in a blog is. I don't pingback to your blog
> service with a copy of my new blog post, I just give you the link,
> which your blog might or might not publish.  So the link in this case
> would be a provenance-URIs <http://example.com/some-provenance.ttl> or
> a provenance-query-service <http://example.com/sparql>, to be
> associated with some target-URI (read prov:Entity)
> <http://elsewhere.example.org/resource>.   If this is honoured, then
> subsequent requests to find provenance for
> <http://elsewhere.example.org/resource> (as in section 2) would
> include the new links.
> 
> 
> The good thing is that now this also provides a way for third-parties
> to provide additional data that can be returned by the provenance
> service described in first half of PROV-AQ - and so just like the
> first half does not detail how the actual provenance data is retrieved
> or got there in the first place, but mainly provides links to other
> resources which return the provenance or let you query it; then the
> second half should be about how to add those links. Currently there
> are no way to add those links.
> 
> The original proposal the pingback service seems more like a "Please
> store this provenance for me" service - which would go counter to the
> disclaimers in the first half about how you should place different
> trust on provenance from different sources (the hosted 3rd party
> provenance would appear authoritative if it comes from the same server
> as the resource) - and not have an obvious link to the lookup.
> Obviously this raises many other problems such as updates, alternative
> representation of the same resource, metaprovenance, Date headers,
> etc.  If you just want to do "Please store and host this resource
> (RDF) for me and give me a URL" - then there are many existing methods
> to do so - the simplest being HTTP PUT on the desired URI, a more
> elaborate one could be AtomPub or even.. ) out of bands with WebDAV
> (ugh) and (S)FTP.
> 
> 
> 
> 
> Here is my alternative proposal for this section:
> 
> 
> (Same blurb about finding prov:pingback)
> 
>  C: HEAD http://acme.example.org/super-widget HTTP/1.1
> 
>  S: 200 OK
>  S: Link: <http://acme.example.org/pingback/super-widget>;
>           rel=http://www.w3.org/ns/prov#pingback
>   :
> Each resource MAY be associated with one or more prov:pingback services.
> 
> 
> A client MAY post a pingback request to any or all of the returned
> prov:pingback services.
> 
> 
>  C: POST http://acme.example.org/pingback/super-widget HTTP/1.1
>  C: Content-Type: text/uri-list
>  C:
>  C: http://wile-e.example.org/contraption/provenance
>  C: http://wile-e.example.org/another/provenance
> 
>  S: 204 No Content
>  S: Link: <http://wile-e.example.org/contraption/provenance>;
>           rel=http://www.w3.org/ns/prov#hasProvenance;
>           anchor=http://acme.example.org/super-widget
>  S: Link: <http://wile-e.example.org/another/provenance>;
>           rel=http://www.w3.org/ns/prov#hasProvenance;
>           anchor=http://acme.example.org/super-widget
>  S: Link: <http://acme.example.org/pingback/super-widget>;
>           rel=http://www.w3.org/ns/prov#pingback;
>           anchor=http://acme.example.org/super-widget
> 
> 
> This client request above indicates that the two provenance-URIs at
> wile-e.example.org contains provenance mentioning
> http://acme.example.org/super-widget or its target-URI (-- either
> forward or backwards, we don't know).
> 
> The client MAY include provenance query services which can describe
> the target-URI by including the corresponding {prov:hasQueryService}
> Link headers. The anchor MUST be included, and SHOULD be the
> target-URI of the resource which this pingback service belongs to,
> unless the submitted query service would expect a different target-URI
> to describe the given resource.
> 
>  C: POST http://acme.example.org/pingback/super-widget HTTP/1.1
>  C: Link: <http://wile-e.example.org/sparql>;
> rel="http://www.w3.org/ns/prov#hasQueryService";
> anchor="http://acme.example.org/pingback/super-widget"
>  C: Content-Type: text/uri-list
>  C: Content-Length: 0
>  C:
> 
> In the above example, the client did not submit any provenance-URIs
> and the URI list is therefore empty.
> 
> The client MAY similarly include {prov:hasProvenance} Link headers to
> specify a different anchor. The provenance-URIs of those headers MUST
> also be included in the content if the POSTed Content-Type is
> {text/uri-list}.
> 
> 
> 
> The pingback service MAY resolve the submitted URIs to validate and
> check the provenance data, however reasonable care should be taken to
> prevent malicious use of the pingback service for attacks such as
> distributed denial of service (DDoS) and cross-site request forgery
> (CSRF).
> 
> The server MAY, immediately or at a later time, include the submitted
> *provenance-URI*s in responses to subsequent request to the provenance
> service for the target-URI. (insert usual blurb about not trust on
> such provenance)
> 
> The server SHOULD include a self-referential prov:pingback Link
> header, which MUST include the anchor for the target-URI this pingback
> service corresponds to. This serves the purpose for the client to
> verify it has submitted a pingback to the correct service, in case it
> has followed an untrusted prov:pingback Link header. The client MAY
> for this purpose POST an empty text/uri-list to avoid side effects.
> 
> 
> The server SHOULD indicate immediate acceptance by including the
> corresponding {prov:hasProvenance} {Link} headers for the accepted
> *provenance-URI*s. If all submitted provenance-URIs have been
> immediately accepted, the server SHOULD respond with HTTP status {200
> OK} or {204 No Content}.
> 
> 
> 
> If server acceptance is pending for any of the submitted URIs, for
> instance because the provenance-URIs are being validated or due to be
> approved by a moderator, the server SHOULD respond with HTTP status
> {202 Accepted}, and only include corresponding {prov:hasProvenance}
> {Link} headers for those provenance-URIs that have been immediately
> accepted.
> 
> The server MAY respond with {401 Unauthorized} and standard
> {{WWW-Authenticate}} headers if authentication is needed. The server
> SHOULD respond with {403 Forbidden} if for any reason it refuses to
> accept one or more of the submitted provenance-URIs or
> provenance-service-URIs. If some URIs were accepted, but others were
> refused, the server SHOULD respond with {403 Forbidden} and include
> generated prov:hasProvenance and prov:hasQueryService Link headers for
> the immediately accepted URIs.
> 
> 
> (The above needs to be cleaned up so that it talks equally about
> prov:hasProvenance and prov:hasQueryService in the error handling -
> and also to separate better the protocol and the example).
> 
> 
> 
> 
> 
> 
> -- 
> Stian Soiland-Reyes, myGrid team
> School of Computer Science
> The University of Manchester
> 
>

Received on Friday, 1 February 2013 17:18:36 UTC