RE: MyProfile

Ok. So the paper really *is& a discussion of myprofile, not webid. Myprofile
is an implementation, contrasting with foaf.me (say). 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. 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), (c) may
somehow ensure the user cannot export the  keying material and reuse it (at
foaf.me, say) undermining the uniqueness claim.

 

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_HbmQzed9wQBcLq8
nyE/edit?hl=en
<https://docs.google.com/document/d/1hqxoA70Gz6daGop7ucKwEZtc_HbmQzed9wQBcLq
8nyE/edit?hl=en&authkey=CPTf9qIP> &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