RE: [unhosted] Re: Unhosted.org Project and WebID

>From the berner's lee writeup, as cited.

 

"(Note that the information returned by looking up the user's webID is not
trusted for access control purposes. Links are only followed out from the
ACL. The server operator can also provide the server with other trusted
information to include in the search for a reason to give the requester the
access. Eventually, something else will be found which points to it)"

 

So, in the berner's lee invention, from the validating entities perspective,
trust your own file of outbound links - a file that is secure against
hacking because of the system security boundary. If there exist links to the
requesting entity's foaf card (or some other linked place links to it),
assign the URI identity a local-issued token, probably based on account
mapping. Only do this once webid validation is complete (which confirms a
user's CONTROL over the cliamant's URI). Execute discretionary access
controls using a classical reference monitor, based on nested grouping.

 

This linking invention is largely identical with cert  chains, of course.
For decades now, the acl enforcing site site has been encouraged to (re)sign
the certs/public-keys of such as verisign's trust anchor (whose n element
cert chain links to you, and introduces you to anyone). As ACL entity, form
up the composite chain of <acl accepting site's public key><ACL site's cert
for verisign><Verisign cert to reseller><reseller signs you><you sign SSL
client authn msg>.

 

If it wants, the acl enforcing site can cut the chain down, and form

<acl accepting site's public key><ACL site's cert for reseller><reseller
signs you><you sign SSL client authn msg>.

 

Or, one cuts it further 

<acl accepting site's public key><ACL site's cert for you><you sign SSL
client authn msg>.

 

Since certs are public, ANYONE can resign the public key within - and add
the result to their trust store for use in there own chain discovery. This
is intended, and normal.

 

If you are REALLY old fashioned, having done one of the above the first
time, you can reduce <acl accepting site's public key><ACL site's cert for
you> to <public key of you> and store it in your acl site's trust store -
doing away with all certs (once they have authenticated a parties public
key).

 

The next time someone presents

 

<cert*> <you sign SSL client authn msg> you just ignore <cert*> and compute

 

<public key of you><you sign SSL client authn msg> based on a guess that the
inbound IP address (or cookie. or. other hint such as TLS clientHello
extension) that locally maps to <public key of you>.

 

This elimination of the <cert*> tends to bug some folks in the linking
"intermediary" business, as they want the fact that *they* revoked a
cert/link in cert* to influence the acl function of all so-called "relying
parties". 

 

The above linking model based on certs is functional and globally available,
in Windows, for browsers doing https and lots of other https consumer
(windows forms doing https web services, for example, or java forms doing
SOAP calls). This linking model was standardized by ISO, in 1988. The
partial path from public trust anchor to claimant is known as the forward
path. The validating entity supplies a reverse link path to the trust anchor
(or any cert on the forward path treated as if, a trust anchor). The two
partial paths conjoin, to make a sequence of signatures - that hopefully
closes. 

 

Having closed the chain cryptographically, one inspects the naming points in
the graph space - to overlay a name-centric trust model. (do I "like" this
chain). In some cases, you don't like some of the elements (poor reputation,
say), and you go looking for an alternative path, that avoids countries
whose namesspace YOU don't like - for some political reason (for example).

 

I keep hoping someone will launch a sparql service that given URI X and URI
Y and URIs {A, B C} as hints, will return a link path between X and Y that
have A or B or C in the path (probably). A B C are known as well-known trust
points. Social adoption works best when none of A B or C has particular
monopoly power, and they are selected to be independent and autonomous of
each other and political control. 

 

 

 

 

 

From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Michiel de Jong
Sent: Saturday, April 09, 2011 12:12 PM
To: unhosted@googlegroups.com
Cc: Melvin Carvalho; Kingsley Idehen; jeff@sayremedia.com; WebID XG;
@eschnou
Subject: Re: [unhosted] Re: Unhosted.org Project and WebID

 

Hi all!

 

 

We should definitely work together. I know WebID through Henry Story, and
have always found it intriguing. Let's