RE: Question: User Story -- Bootstrapping Facebook

I find this very important, as it means the security enforcing requirements have no dependency on the properties of fragments. (*)
 
the claim's basis has been reduced to the very same property as openid, that one has write access to an idenified resources (the "identity document", in myopenid terminology).
 
This was said indirectly in X.509 note. It implies the same, when it said that write access to the directory record (which one tested for cert presence => authority) is slimited to (i) to those USING strong authentication and (b) ideally the party strongly authenticated should be the subject user depositing the cert.
 
X.509 is weaker than claims here in that it did allow an directory admin (with ACL write permission + strong auth) to also deposit the subject cert.
 
You can read this in Steedmans book on the 1988 era security model for access control.
 
(*) This is worrying politically, as this was one of the movement's main distinguishing points - that lots of properties derived, incuding security properties. Mostly, since HTTP intentionally strips #fragments, it was seperating transport from processing, where in the semweb processing one saw the "full web" model being portrayed (rather than just link anchors in a bit of HTML markup).
 
 

 
> Date: Thu, 10 Feb 2011 09:58:43 +0000
> From: nathan@webr3.org
> To: melvincarvalho@gmail.com
> CC: henry.story@bblfish.net; public-xg-webid@w3.org
> Subject: Re: Question: User Story -- Bootstrapping Facebook
> 
> Melvin Carvalho wrote:
> > This is my question. Is it a problem that they dont currently use
> > fragments. And can we easily can get around that?
> 
> It's probably the least significant of all the problems tbh, strictly 
> for webid all we need to do is prove that somebody had/has write access 
> to the "resource", so regardless of whether somebody uses /profile or 
> /profile#me, in both cases you'll be looking to see if the persons 
> public key is in /profile.
> 
> The /profile#me uri only comes in to play in RDF terms when you're 
> looking for information about /profile#me, and since facebook provides 
> next to no information about it's users, much less in full RDFa with the 
> subject set, this isn't really a factor at the minute.
> 
> One could even suggest that if facebook ever did publish full RDFa and 
> adopted fragment identifiers for people (they don't currently make 
> distinctions between pages and the thing the page is about), that the 
> information wouldn't be publicly available anyway, as in you'd have to 
> be "signed in" to facebook to see it!
> 
> Another potential issue, is that sites like facebook don't have "one 
> uri" for each person, each person can have several different ones, 
> basically whatever is in the address bar when that person is looking at 
> their own profile.
> 
> It could be worse though, look at twitters URIs for users.. 
> http://twitter.com/#!/webr3 that would lead to a GET on 
> http://twitter.com/ for every user on twitter.
> 
> Back to facebook, there are just so many questions - could a user ever 
> add their own "webid information" (public key for instance) to their own 
> profile page? publicly? in a machine readable consistent way? would 
> facebook block it? would facebook add it? would they require open graph? 
> would they only show it to identified / signed in sessions? etc.
> 
> Ultimately, there are three questions for facebook here:
> - would you ever allow users to sign in to facebook using webid(s)?
> - would you ever allow people to use their facebook uri as a webid?
> - would you publish users profile data (subject to their privacy 
> settings) in a machine readable way, at the profile uri?
> 
> In the meantime though, we can identify what steps facebook would have 
> to take to adopt and support WebID fully, without any input from them, 
> and see just how easy it would be for them ("not very" would be my 
> opinion on it!). Likewise for other sites, is it even possible for them 
> to adopt without changing their platform and deployed systems? (Twitters 
> URIs effectively means "probably not", likewise facebooks privacy and 
> custom auth* solutions + various apis).
> 
> However..
> 
> > I cant comment on why they built their platform the way they did, what
> > they will roll out in future, or in what time line.
> > 
> > But I'm interested in the short medium term, to see how easily
> > compatible WebID is with their EXISTING setup?
> 
> If we ask the question "why would somebody want to use their facebook 
> uri as a webid?", about the only answer I can come up with is so as to 
> re-use their (public) profile information.
> 
> One potentially very fast way to do this is to create a quick service 
> which dumps out foaf for each user, gives them a uri and let's them get 
> a webid, say something like fbusers.foo/webr3 . Although a service which 
> did this and imported info from any number of services (google profiles, 
> yahoo profles, twitter, facebook, myspace etc) may be more useful for 
> everyone, i dunno something like openprofile.com/webr3 would be sweet 
> for this.. (.. ..... ... ... .!!)
> 
> > Right now everyone is developing for the FB platform due to the
> > network effect. If we can have a hybrid system that easily manages
> > WebID and Facebook account, I can see people using it (I would at
> > least).
> 
> Indeed, we make a hybrid system then :) Unsure if managing a facebook 
> account it required, not simply import from the facebook account..?
> 
> >> Sorry, there are just too many hypotheticals in your question to make it possible to give any clear answer. There are many simple solutions to their problem. They could use redirects for example, if they don't like # urls.
> >>
> >> If they are interested in WebID, perhaps we should invite them directly, then we could answer their questions with more context....
> > 
> > I think they would be good people to talk to, yes, if it's possible to
> > get them more interested. It's the dominant social eco system on the
> > web. I know from SWXG telecons that David Recordan has at least heard
> > of WebID, so that's a start...
> 
> Fully agree, we have to ask people what their requirements are from 
> webid, and what restrictions they'd place on 
> implementing/adopting/supporting webid. The people who the SWXG spoke 
> to, like David Recordan, are the key people we need to be discussing 
> things with.
> 
> Best,
> 
> Nathan
>