W3C home > Mailing lists > Public > public-xg-webid@w3.org > May 2011

Re: MyProfile

From: Henry Story <henry.story@bblfish.net>
Date: Wed, 4 May 2011 21:40:22 +0200
Cc: "'Andrei Sambra'" <andrei@fcns.eu>, <public-xg-webid@w3.org>
Message-Id: <626D9656-898F-42B9-A495-5955AB34921E@bblfish.net>
To: peter williams <home_pw@msn.com>

On 4 May 2011, at 21:05, peter williams wrote:

> Ok. So the paper really *is& a discussion of myprofile, not webid. Myprofile is an implementation, contrasting with foaf.me (say).

I also think that it is worth developing the FreedomBox/MyProfile picture. It puts some things a lot more clerly into focus. 

> And, its specifically interesting BECAUSE the profile and its agent is on the user’s personal computer (and is not controlled by provider of websites, like the contrasting foaf.me more “webby” example). I like that you are focusing on this constraint (it’s what I wanted to do with Opera Unite, similarly; not that I succeeded to make it work). Since the foaf card is not signed, assuming a third party WILL maintain the profile’s integrity (think Facebook) makes webid little better than openid. Of course foaf.me is going to suspend me, the moment it gets a covert order to do so. He goes to jail if he doesn’t… Of course he is going to suspend me too, if his insurer rings up (and demands it, under threat of removal of coverage).
>  
> Ok. Im getting to understand, from this update. Myprofile may ENSURE there is a unique identity concept (not that the underlying webid standard does this). May want to make this clear - that there is an explicit constraint being imposed (that other webids may not have).  I’ll guess that by profiling and constraining webid standard, Myprofile enabled the webid mechanism to support the “unique id” claim, specific to myprofile.

I don't think one should misunderstand the idea of a "unique ID" . No open system can constrain any object to have only one name. What is important is that the ID be uniquely referring, which is of course what URIs do. What may be important is to
find a way to help other players know that they are dealing with a box that is owned by the identified agent - since that has certain properties relating to confidentiality.

One way to do that would be for the client certificate to use the same publc key as the TLS endpoints. It would be good to know if there are weaker ways to do this too.  


> To implement that, myprofile may for example be less open than webid as specified, in that it (a) might require the user browser to use certs that are minted by myprofile software (certs minted by third party software from PKI for example, cannot integrate in _MYPROFILE_), (b) may not support the multiple SANs notion (which introduces lots of identity ambiguity),

Why you could have a certificate that has multiple SANs but one of them has a special relation to a server that is found to be
administered by the identified person.

> (c) may somehow ensure the user cannot export the  keying material and reuse it (at foaf.me, say) undermining the uniqueness claim.

Why? You may export it, but in doing so just loose the "Administrator" of that machine property, and so 
loose certain confidentiality properties.

>  
> If anyone cares, the traditional structure in the security world is identification (get the name, as registered under registration criteria), authentication (of the name claim) to third parties, authorization (using role/group/label claims attached to the id, somehow).
>  
> In the case of foaf.me, I get a name, which is my identifier. It makes a PPD. Then I establish authentication credentials (by stuffing in my public key), allowing for acts of authentication of my presentation of the id claim (using TLS mechanisms). Then, authorization claims are pulled/pushed to the resource server, enabling IBAC (identity based access control). Alternatively, the resource server performs RBAC (rule based access control). In the IBAC world, users have discretion to change access rules on resources. In the RBAC world, users do not; only privilege administrators may change the users labels, or the labels on the resources, that guard access.
>  
> Perhaps we stick to that world view – being SO established. It’s the X.509 world, where the terms are long standardized by ITU/ISO in X.800. In the practical authentication framework version of the scheme, get an directory name and an user-class entry, stuff in cert attribute (optionally), use signed operations at a UA to present the name/identifier claim to an agent guard. As a result, the guarding agent validates the authN evidence from the wire (a signature, supported by certified name/key binding), then normally performs AuthZ, using either IBAC model (roles/groups tied to the id claim compared against ACEs in the ACLs) or RBAC access control models (labels lattices tied to the id claim and resources, and channels/ports often).
>  
> Now is something about webid or myprofile NEEDS a different organization of core security framework perhaps argue that. Lets know if its myprofile (specifically) or the underlying webid standard that mandates the shift in perspective. OpenID has the classical formulation (if that’s relevant). If security for/from the semweb perhaps requires  a different language game (perhaps because of the underlying RDF model, the nature of the webid enforcement logic,  or …), this is WELL worth communicating.
>  
> I think we just have to ensure we are not dropped in the openid 1 bucket, and folks like UK JANET look at webid per se and essentially dismiss it (because it has “no value”). Semweb with webid has to avoid being labeled as another 
> “openid 1”.
>  
>  
> From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org] On Behalf Of Andrei Sambra
> Sent: Wednesday, May 04, 2011 10:24 AM
> To: public-xg-webid@w3.org
> Subject: 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

Social Web Architect
http://bblfish.net/
Received on Wednesday, 4 May 2011 19:40:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 4 May 2011 19:40:55 GMT