RE: How To Handle WebIDs for (X)HTML based Claim Bearing Resources

This issue is critical for me (and thus the spec's scope, I recommend). It will define whether webid is viable or not, in realty. 



I realty, one is governed by several authorities, and anyone can suspend you. More than often, the worst side of human nature if behind the suspensions, and it can be entirely corrupt. As there is nothing official about the source of authority, its important for an entire community of realtors to dump the current authority and go set up an alternative board. This often happens when a market shifts (with population migration, or investement, or city council policy change), and those (pwoerful) realtors who dominated the committe lost their power base, but held on. Those who make a new market, split the board, which contorls the identifies.

 

In realty, one MUST be able to marry and divorce ones identity. There is no stable source of authority; only that which people use. An established source tends to last for about 10-20 years, before dis-ontegration politically (and re-integrating). This happens in 300 cities every day i the US, as some or other point in the phase cycle, as local politics is carried out.

 

Im not a realtor, but I do get to prepare for those phase transitions - as folks expect the politics of dump and reform to work, expeditiously (as folks fracture, folks pull of committee coups, etc etc). Its not my job to argue with the coup, the plotters, or the old guard. If uou pay, you get identity arms. go and use them in the local market, when evolving to the ever shifting requirements.

 

Remember, realty is PURE competition, entirely open. Its not a regulated space, expect in the "assurance" requirements that states impose (trying to safeguard the public interest in mortages, systemic crash protection, inherent and inevitable fraud (hey its all human), and worry about that trillion dollars of cash that can make or break GDP.

 

openid 1.0 got it right, in specifically FACILIATING identity delegtation, intending that the IDP can be dumped tomorrow by the user, and this has no impact on the relying party relationship between subscriber and information content provider. SImilarly, it allows the IDP to dump the user (deemed unfit to be a member of PayPal). The design allowed for such political realities, and did not alter the balance of power in the web.

 

openid 2.0 got ir partly right, though many of the larger IDPs refuse to participate in the optional part of the protocol (delegatoin). They do not see it as in there interests (when offering "free" profiles) to allow such dumping, and commercial re-purposing. (And they have a point.) However, it alters the balance of power re subscribers and IDPS and consuming sites. While this issue may be balanced right (for Google enterprise class of applications), its arguable ehther they have it right for the web (where realty lies, bneing enterprise-ish in its sheer scale and risk management, but web-0sh in practice due to the nature of the persons who conform realty (mom and pop, as individual proprieters collectively working a trillion dollar cash flow)

 




> From: mo.mcroberts@bbc.co.uk
> Date: Sun, 1 Jan 2012 16:46:18 +0000
> CC: public-xg-webid@w3.org
> To: kidehen@openlinksw.com
> Subject: Re: How To Handle WebIDs for (X)HTML based Claim Bearing Resources
> 
> 
> On 31 Dec 2011, at 17:24, Kingsley Idehen wrote:
> 
> > Peter gave an example a while back where he loses his Blog space URIs (since he doesn't control Blogspot or WordPress) but still needs to be able access resources where his old Blog space (the IdP) URI is remains the focus of ACL list by those granting him access to resources (e.g., photos). In this case, he can present a Cert. that has his old URI and his new URI in the certs. SAN. The ACLs don't have to change, assuming the verifiers comprehend coreference claims.
> 
> There are a very limited number of ways in which that can work if the old URI no longer resolves to linked data matching up the with cert (as would be the case if the account at Blogspot was suspended, or Google shut it down, or whatever — including it now reflecting *somebody else's* claims) without making it trivially easy for hijacking to occur.
> 
> 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 Sunday, 1 January 2012 18:24:44 UTC