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