Re: different publish RDF in section 2.4.2

Ok, I have updated the spec in mercurial

   https://dvcs.w3.org/hg/WebID

And the new version is available again on

   http://bblfish.net/tmp/2011/11/23/index-respec.html



On 23 Nov 2011, at 15:19, Peter Williams wrote:

> If the link points to a site beyond the control of the original resource (identified by the user cert), what does one do?

I don't think this is a problem, the web is a global namespace. If one representation says that it is the alternate of another somewhere else, then so be it...

>  
> if the link point to the same site (as the original resource) but resolves to an ssl cert or different ciphersuite to that  of the original resource (identified by the user cert), what does one do?

Can you prove the WebID claim? If not you only have a claim and not a WebID. See step 5 of 
http://bblfish.net/tmp/2011/11/23/index-respec.html#authentication-sequence


>  
> I dont find it helps building in statement of principle, and informal education about the mechanisms. In a security protocol, one  needs hard engineering, not generalities.
>  
> Statements like "it is suggested" dont help. Reduce it to SHOULD or MUST. Dont use specs to educate about principles of design. Just specify what implementors need to do.

Ok. will use more military talk .

>  
> Note, that the webid validation protocol has no "discovery" elements of procedure for the validation agent to follow, today (and no security model for discovery, either). If an alternate link  points to another HTML document (with further links) what does one do?

It does: deference the URL - that' s the discovery bit. Where others have all kinds of layers we do it one go. That's because we build up recursively on URIs, and well in particular on URLs.
> 
> We have to recall that the original link is an untrustworthy value, supplied by an unknown party. There referall alternates are just untrustworthy. If an implementation has a hard limit of processing only 3 links (as I saw in code from the author of the webid test suite), an attacker would be subverting that limit, using alternates - if it is expected that "discovers" link chains.

What would the attacker be doing with the alternates. Recall that the WebID has to be the initial one in the certificate. Can you put together a simple scenario where an attacker uses links to subvert things? 

>  
> Now, as an implementor, I link this in my mind to another issue that the spec(s) are quiet on. If the link in a cert returns a 302 upon de-referencing, whose implementation follows these? the same question as for alternates apply (how many chaining element does one follow, what happens on https/http downgrade, what happens in the cert changes on the same site...)

yes, we need to look more in detail at what happens with redirects. Again it would be useful if you could work out a problematic scenario with redirects. The we would know what the problem is.


>  
> openid 1.0 had the same issues, and of course has had no massive commercial uptake. only a particular profile of openid 2.0 has met the needs of vendors and branded cloud players (such as those who conform W3C dues-paying membership).
>  
> > From: mo.mcroberts@bbc.co.uk
> > Date: Wed, 23 Nov 2011 13:34:12 +0000
> > CC: ddooss@wp.pl; kidehen@openlinksw.com; public-xg-webid@w3.org
> > To: henry.story@bblfish.net
> > Subject: Re: different publish RDF in section 2.4.2
> > 
> > 
> > On 23 Nov 2011, at 13:09, Henry Story wrote:
> > 
> > >> rel=“alternate” is, after all, a crutch for when the server hasn't sent a resource in the format you wanted in the first place, so good if the situation where it can do that from the outset is covered.
> > > 
> > > that's in the section
> > > 
> > > http://bblfish.net/tmp/2011/11/23/index-respec.html#processing-the-webid-profile
> > 
> > Ah, okay. The sentence in §2.4 doesn't really stand out.
> > 
> > It currently reads:
> > 
> > “The encoding of this graph is theortically immaterial to the protocol, so long as a well known mapping from the format of the representation to such a graph can be found automatically. In order to improve interoperability at this time it is suggested that WebID provider publish the graph of relations at least in one of RDFa [XHTML-RDFA] or RDF/XML [RDF-SYNTAX-GRAMMAR], though he may publish it in a number of formats to increase the usability of his site to different agents using content negotiations [SWBP-VOCAB-PUB].”
> > 
> > Perhaps amend to something like the below, might be clearer?
> > 
> > “The protocol does not depend on any particular serialisation of the graph, provided that agents are able to parse that serialisation and obtain the graph automatically. HTTP Content Negotiation [SWBP-VOCAB-PUB] can be employed to aid in publication and discovery of multiple distinct serialisations of the same graph, and it is suggested at this time that publishers serialise as one of RDFa [XHTML-RDFA] or RDF/XML [RDF-SYNTAX-GRAMMAR]. 
> > 
> > Irrespective of whether content negotiation can be employed or use of RDFa, if an HTML representation of the WebID profile is published, it is suggested that the provider uses the HTML <link> element to allow discovery of the various alternate representations of the graph which may be available:
> > 
> > <html>
> > <head>
> > <link rel="alternate" type="application/rdf+xml" href="profile.rdf"/>
> > <link rel="alternate" type="text/turtle" href="profile.ttl"/>
> > </head>
> > <body> ... </body>
> > </html>
> > 
> > Using the <link> element in this manner aids in robustness: if the HTML representation does not serialise the graph as RDFa, or if content negotiation is not available, an agent will still be able to obtain a machine-readable serialisation of the graph.”
> > 
> > (and then remove the equivalent portion from the end of §2.4.2)
> > 
> > M.
> > 
> > -- 
> > Mo McRoberts - Technical Lead - The Space,
> > 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
> > Project Office: Room 7083, BBC Television Centre, London W12 7RJ
> > 
> > 
> > 
> >

Social Web Architect
http://bblfish.net/