Re: Question: User Story -- Bootstrapping Facebook

On 10 February 2011 12:15, Peter Williams <home_pw@msn.com> wrote:
> I find this very important, as it means the security enforcing requirements
> have no dependency on the properties of fragments. (*)

Not sure the fragments are such a big deal.  Intelligent software
should be able to handle structured data if it's semantic.

Claims can be made

1) on a server (such as facebook.com)
2) on any URI signed by a party
3) in the LOD cloud in an aggregator like sindice or google

if using (2) we're completely portable, in indeed a cert is a set of
claims signed to make them portable

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

Received on Thursday, 10 February 2011 13:23:02 UTC