Re: MyProfile

On 04-May-11 18:39, peter williams wrote:
>
> Comments
>
> https://docs.google.com/document/d/1hqxoA70Gz6daGop7ucKwEZtc_HbmQzed9wQBcLq8nyE/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.
>
What I said there was in the context of MyProfile project, in which 
users host their profiles on their own computers/dedicated machines. 
What you should understand from this, as opposed to having your card 
stored on foaf.me, is that there is no other entity (i.e. administrator) 
who could potentially modify anything.

> 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.
>
Are you still referring to the above quoted paragraph (I see no 
relation)? If you are, then any ambiguity a reader might have can easily 
be dismissed by examining the WebID specifications (let's not be lazy).

> -----
>
> 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.
>
>
Identification and authentication are two different things. Would you 
agree that identifying yourself means matching a credential (i.e. the 
certificate) to a description of a user / device / etc.?

> 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.
>
Again, you are confusing identity and authentication. Authentication 
stops as soon as a match is found between the public key of the 
certificate and the RDF description of the same public key in the foaf 
card. Next comes identification, since now a service trusts that the 
contents of the foaf card indeed belong to the user that is found behind 
the browser and which is accessing said service. Even more, after 
identification we can now talk about authorization. All three are 
different concepts, you shouldn't get confused.

> 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.
>
Are you proposing anything for the Berlin workshop?

Andrei