MyProfile

Comments

 

https://docs.google.com/document/d/1hqxoA70Gz6daGop7ucKwEZtc_HbmQzed9wQBcLq8
nyE/edit?hl=en&authkey=CPTf9qIP#

 

 

"WebID proposes a way to uniquely identify a person, company, organization,
or other agents, using a URI which is included in an X.509 browser
certificate. The authentication process relies on TLS to validate that the
private key in use matches the public key of the declared certificate, as
well as the public key found in the profile at the location indicated by the
URI. In other words, it provides a cryptographic way of authenticating and
identifying a user, based on resources managed by the user -- the browser
certificate and the corresponding profile accessible at the URI location. "

 

The last clause is really not true. Surely, there is no *Cryptographic* use
of the assumptions of user control over browser or profile. Rather, webid
security protocol is asserting the truth of the claims, having itself relied
on TLS crypto to prove X. The crypto (in TLS) only does (mostly, see below)
what the first part of the paragraph says. TLS's security services are
relied upon, but the crypto (and TLS) methods underlying the delivery of
those services make no use of user-governance of the cert or user control of
the profile (at the URI).

 

Its obviously trivial for the administrator of foaf.me to modify my foaf
card, using privileged access.

 

Webid is a "security protocol (SP)". As the para says, that SP relies on TLS
(to do X..). The SP then enforces various non TLS controls, intended to
prove the claims. This relations is much like how https builds upon TLS, to
enforce various security controls that TLS does not deliver.

 

Suggest: First, distinguish the claims due to webid "validation" from the
evidence/role of TLS in helping make/prove those claims, where TLS is merely
a supporting mechanism.  Second, show how the validation design proves the
claims, or state the limits. In my view, the claims are merely assertions.
Its their nature that limits them to being only assertions, in my view.

 

-----

 

Concerning "proposes a way to uniquely identify", is this really true?
Nothing in TLS nor in webid SP prevents or detects two parties sharing one
private key. Indeed, we have said that there can be multiple URIs in the
SAN, pointing to different profile documents. A profile ownser can have
multiple keys in each profile, and the keys sets in n  profiles can be
disjoint. Thus, to the SP one has to assume the user has different keys (and
TLS evidences thus, when keys are applied for signing macs) and different
URIs, undermining the core "uniquely identifies" claim.

 

If I look at our fundamental concept, we are specifically not proposing a
way to uniquely identify. We are giving a way for different identities to be
considered equivalent. Its really is a variation of having two cert paths
terminating a different trust anchors, both certifying the same user pubkey.
In the semweb version of this problem/case, its something
ontological/logical/enforcing that the semweb elements of the design do (not
the crypto). It's also the semweb that delivers the *assurance* that
*inferred* equivalency claims are even computable and/or then true. 

 

It's the close reasoning on this I *most* want to hear in the Berlin papers!
Don't need more generalities per the paper for the American vendors. Now we
want the semantic web to shine, and not just because its webby. It has to be
showing how it enforcing some specific security claims, and also who why
anyone should believe it does this.