Thanks for bringing this up. I was hoping someone would push me to think about this at some point, so that we could have a more in depth discussion.
On 19 May 2011, at 16:52, Reto Bachmann-Gmuer wrote: > On Thu, May 19, 2011 at 4:15 PM, Henry Story <[email protected]> wrote: >> >> On 19 May 2011, at 14:36, Reto Bachmann-Gmuer wrote: >> >>> Hello >>> >>> I've noticed that with the change to principals one can be logged in >>> as multiple users. >> >> To be precise the changes made use of the flexibility of Java's Subject >> class. >> >> http://download.oracle.com/javase/6/docs/api/javax/security/auth/Subject.html >> >> The subject class is designed to allow one to have multiple Principals. > > We shouldn't do things just because its possible, we should only > implementing things with a beneficial addition to useful possibilities > in relation to the added complexity The point is that you need multiple principals in the current world. This is so clear that the Java Community that has gone through a standardisation process with the requirements of a large number of players in mind has worked this out in detail and even written it out clearly in all their documentation. So this is a standardised problem. Let's be happy that we are using such a well thought out language and are not having to re-invent all these solutions ourselves. And if we are going to work on the web there is just no other way to do things. People are going to be able to login with OpenId, with passwords, or with other means. Being able to have multiple logins can increase security. > [...] >> >> So this is not that different from Foaf. We can have multiple identifiers: >> social security number, webid, username... These are all inverse functional >> properties. > > That's not as its currently implemented by your code, if one logs in > with multiple webids (and the maybe additionally with cookie login) > multiple users are created in the system graphs Well the first thing is that you end up with is multiple Principals. What is needed is a UI to allow users to merge those principals, or a UI to select from one or the other. This is in fact a cool thing in that you can see that someone logged in twice and allow them to merge. Let's be happy when the semantic web gives us benefits for free. :-) Ok more below... >>> How are applications supposed to deal with this? In >>> my wall-applcation and blogging engine I assumes a request originating >>> from exactly one user (which can be user anonymous). I know wanted to >>> updated my apps and was wondering how to do this. >> >> What we need is to improve the ways to identify the user so that he can log >> in >> various ways (including openid in the future or facebook connect). >> >> I think we should do the following. Currently the user is identified in the >> graph <http://tpf.localhost/system.graph> >> >> @prefix perm: <http://clerezza.org/2008/10/permission#> . >> @prefix zz: <http://clerezza.org/2009/08/platform#> . >> @prefix foaf: <http://xmlns.com/foaf/0.1/> . >> >> </user/admin/profile#me> >> perm:hasPermission [ >> perm:javaPermissionEntry "(java.security.AllPermission \"\" \"\")" >> ] ; >> perm:passwordSha1 "d033e22ae348aeb5660fc2140aec35850c4da997" ; >> zz:lastLogin >> "2011-05-17T18:03:48.558Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ; >> zz:userName "admin" ; >> a foaf:Agent ; >> foaf:mbox <mailto:[email protected]> . >> >> >> so here the user has already two identities >> - the WebID </user/admin/profile#me> >> - the zz:userName "admin" > yes, but we used to have just one resource, we now potentially have > multiple resources created by the foafssl login module. You have multiple URIs and one resource. That is what owl:sameAs is for, or what merging and smushing is for. Logging in with multiple ids is a a proof of an owl:sameAs relation. So then you allow people to merge. That is what the semantic web is so good at. For the moment we have a quite simple scenario to help us think about things. We have cookie and WebID. > >> >> It would be easy to extend this to allow openid by adding the relation >> >> </user/admin/profile#me> foaf:openid <http://bblfish.net/> . >> >> The principal can therefore be either: >> - the webid >> - the openid >> - the account name ("admin", "joe",...) >> - facebook account, ... >> it does not matter. >> >> What we should do is to create subclasses of Principal (which anyway is just >> an interface) >> to allow one to distinguish these different types of principals. >> >> Each principal can then be used to get the resource (bnode or uri) that is >> the >> foaf:Agent, and the zz:userName should be shown if it exists, or some >> zz:preferredUserName, which could be set automatically. >> >> >>> The same difficulty occurs with the displayed username in the menu, >>> and where the menu-item "control-panel" shall point to. >> >> It should point to the home page, as now. > yes, but what is the "home page" if one can log in as more than one > user simultaneously? I think we need to look at this case by case. 1. User has Username (only) --------------------------- We know how to deal with that For one a user cannot login I think with one cookie and a different user name. I think when you login with user name the cookie is automatically set to go with it. So the main case we have is the user logging in with WebID and a username. 2. User logs in with WebID -------------------------- (let's forget the issue of multiple WebIDs currently. We can look at that later) Currently we don't have a satisfactory home page for the user logging in with a WebID without a username. As shown in CLEREZZA-515 it is something like /user/http___bblfish.net_people_henry_card_me/... That was a good thing to get something going, but is not a good solution, and we should fix it. Especially as it would not be improved by the option of the same user then logging in with an openid, or with any of the many other options. ((Btw, I think it is because openid people are not using the semantic web that they are having trouble solving this issue. We are a lot further ahead here, and just need to think about it.)) I think that the user who logs in with a WebID without a username, should not have a home page, but only a profile page that shows him what we know about him. Something like: /remote?webid= ( I think that is what we are in fact doing - a WebId logged in user does not have an account. ) If that person does something local where we wish to keep some state then we put that in the graph for the webid. So if the system then wants to allow the remote user to sore local information about the user where would he put it? Perhaps here? urn:x-localinstance:/remote?webid={webid} But that may just be app dependent. I suppose it would be nice for the remote webid user to be able to get a quick list of all blog comments he posted. That should go there. 2.1 User then links to an account ---------------------------------- What such a page can do is ask the user to associate that webid with an existing account or create an account. In either case the following relations for a user named "joe" will the appear. </user/joe/profile#me> zz:userName "joe"; owl:sameAs <http://joe.name/#me> . 3. User logs in with Multiple WebIDs ------------------------------------ This is not going to be a big issue, and I don't think we need to work hard on it, as there will not be a big need for this. But it is good to think of it ahead of time a bit. 3.1 without a user account -------------------------- So it's the same as with one webid. The the user graph would just be the merger of the two. And either URL could be selected. 3.2 with a user account ----------------------- The the user account is the main graph and the WebId principals are just tied to the user like this. </user/joe/profile#me> zz:userName "joe"; owl:sameAs <http://joe.name/#me>, <http://apache.org/people/joe#me> . Conclusion ---------- So I think the conclusion of this is just that people only have a home page if they have asked for it. > >> >> If there are two non fused identities, the user should be asked if he wants >> to fuse them, and which he prefers to have as his new home. I suppose one >> could also give him the opportunity to log in as one or the other, by >> changing a menu. > > seems a great increase of complexity, what legimitates this? Talking > about certs with multiple webids in the specificatioon group is one > thing, making thing complex to support this (imho quite exotic) > feature is another. Well part of the reason I can work on this here is that this helps me work on things over there. So I am willing to deal with the added complexity. >> >> There is also CLEREZZA-515 "ugly account name when logging into ZZ with a >> foreign WebID" >> though this would be just as valid for OpenIDs. > I don't think this relates two my question, having more than one user > logged in is difficult both with nice and with ugly account names. Well it is an issue I want to solve anyway. Now that you have brought this up, we might as well tie this in, so I can work on it. >> >> I can work on the core auth code change if someone can help me with the UI >> piece from there. > > So the short answer to my question "How are applications supposed to > deal with this?" is "you currently can take a user randomly or let the > user choose who he wants to be, but in future thing might go back > again to one user, as this is handled like inverse functional > poperties in foaf" Does the above detailing help? Perhaps you can describe your needs more precisely too. Are you satifisfied with the one webid solution? I think that is what we have currently, except that we need to decide what the home page of a webid only user is. Henry > > >> >> Henry >> >>> >>> Reto >> >> Social Web Architect >> http://bblfish.net/ >> >> Social Web Architect http://bblfish.net/
