Re: different publish RDF in section 2.4.2

On 23 Nov 2011, at 14: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?

Given that the graph has to contain the pubkey from the user cert, it shouldn't matter. If I define my WebID as http://nevali.net/#me and host that site on tumblr (which I do), things are going to get problematic if I can't put the machine-readable graph in http://meta.nevali.net/foaf.rdf (for example), because that excludes a lot of people from ever being able to have a WebID at their preferred URI.

Ultimately, you do not know what is and isn't within the sphere of control of the user, until you have the graph and have processed the pubkey details it contains to confirm that they match those contained within the user cert.

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

I’m unclear as to what you mean by "resolves to an SSL cert or different ciphersuite“; last I looked WebID didn't really care whether the resource was served over HTTPS or not to begin with.

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

One needs both.

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

Then alter the wording?

> If an alternate link  points to another HTML document (with further links) what does one do?

Discard it, type doesn't match what's been advertised.

> We have to recall that the original link is an untrustworthy value, supplied by an unknown party. There referall alternates are just untrustworthy.

Well, quite. However, there's a distinction between “its claims are not trusted for identity purposes” and “its signposts must be ignored”.

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

There will be no chains.

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

303 is more relevant, but it applies to any sort of redirect, and exactly the same logic applies.

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

you're being incredibly charitable to openid 2.0

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

Received on Wednesday, 23 November 2011 14:42:44 UTC