Clerezza
  1. Clerezza
  2. CLEREZZA-515

ugly account name when logging into ZZ with a foreign WebID

    Details

    • Type: Bug Bug
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      When loggin in with my WebID http://bblfish.net/people/henry/card#me I get a login name

      http___bblfish.net_people_henry_card_me

      that is really ugly, and does not fit on the top page. It is not even guaranteed to be unique, so that it could
      lead to acces control issues.

      The server should try to display a name that is good looking, perhaps the person first name, last name, or
      nickname found in the profile document. What if none of those exist? Would a short automatically created name
      not be better? Any ideas?

        Activity

        Hide
        Reto Bachmann-Gmür added a comment -

        In the renderlets we have the context node which describes the user, so the template should display the FOAF.name instead of the PLATFORM.userName. For this we might have to add this to the context-node by the ContextProvider providing the user.

        This huge bunch of changes seem to handle things beyond the scope of this issue, why should WebIDTester and the authentication bunldes be changes just fo another property to be shown?

        Show
        Reto Bachmann-Gmür added a comment - In the renderlets we have the context node which describes the user, so the template should display the FOAF.name instead of the PLATFORM.userName. For this we might have to add this to the context-node by the ContextProvider providing the user. This huge bunch of changes seem to handle things beyond the scope of this issue, why should WebIDTester and the authentication bunldes be changes just fo another property to be shown?
        Hide
        Henry Story added a comment -

        > why should WebIDTester be changed

        because I moved the class WebIdPrincipal that was in Scala and in the foafssl.core package to platform security. Since the tester used the WebIDPrincipal, it was re factored to use the new Java one which has a getter.

        So why do we need a WebID principal? Because just as the principal definition shows in the official javadoc there are completely different things: a social security number principal is not a user name principal, is not an openid principal, etc... Ie: they should not be used by an authentication system in the same way. A social security principal for example in a traditional app would go to the Social Security column in an employee table.

        http://download.oracle.com/javase/6/docs/technotes/guides/security/jgss/tutorials/glossary.html

        This cannot be seen by looking at the String returned by the principal, unless those are forced to follow a specific URL like syntax. It is better for this to be indicated by the class type.

        > just fo another property to be shown

        The point is to allow people to authenticate with WebID without giving them an account. Currently the only thing that made sense was to show the account name in the login panel. What WebID authentication did was create a fake account name to satisfy existing code's need to do everything in terms of account names. These patches make things a lot more flexible, allowing people to be identified by their OpenID only, or by facebook connect, etc... No need to force everything into account names.

        It is quite possible of course to put the name in the system graph and get it from there. I am ok with variations. The point of this patch was to show how one can do authentication without account names, in a manner that is much more open to future improvements.

        Show
        Henry Story added a comment - > why should WebIDTester be changed because I moved the class WebIdPrincipal that was in Scala and in the foafssl.core package to platform security. Since the tester used the WebIDPrincipal, it was re factored to use the new Java one which has a getter. So why do we need a WebID principal? Because just as the principal definition shows in the official javadoc there are completely different things: a social security number principal is not a user name principal, is not an openid principal, etc... Ie: they should not be used by an authentication system in the same way. A social security principal for example in a traditional app would go to the Social Security column in an employee table. http://download.oracle.com/javase/6/docs/technotes/guides/security/jgss/tutorials/glossary.html This cannot be seen by looking at the String returned by the principal, unless those are forced to follow a specific URL like syntax. It is better for this to be indicated by the class type. > just fo another property to be shown The point is to allow people to authenticate with WebID without giving them an account. Currently the only thing that made sense was to show the account name in the login panel. What WebID authentication did was create a fake account name to satisfy existing code's need to do everything in terms of account names. These patches make things a lot more flexible, allowing people to be identified by their OpenID only, or by facebook connect, etc... No need to force everything into account names. It is quite possible of course to put the name in the system graph and get it from there. I am ok with variations. The point of this patch was to show how one can do authentication without account names, in a manner that is much more open to future improvements.
        Hide
        Henry Story added a comment -

        Btw, it is only by putting up such a patch that one can then think of improvements. It was important to show how this worked.

        For example perhaps what we should do in Clerezza is ask that all Principals implement another interface so Clerezza can be open to new
        types of logins without those needing to be placed into the core authentication module. Since for the moment there is only WebID and account name principals, I think it can be done this way. But I would certainly be for abstracting things away more if this can be shown to work.

        Show
        Henry Story added a comment - Btw, it is only by putting up such a patch that one can then think of improvements. It was important to show how this worked. For example perhaps what we should do in Clerezza is ask that all Principals implement another interface so Clerezza can be open to new types of logins without those needing to be placed into the core authentication module. Since for the moment there is only WebID and account name principals, I think it can be done this way. But I would certainly be for abstracting things away more if this can be shown to work.
        Show
        Reto Bachmann-Gmür added a comment - I vetoed the changes made so far under this issue, see: http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201105.mbox/%3C4DD9FD5F.1070400@trialox.org%3E
        Hide
        Reto Bachmann-Gmür added a comment -

        A detail that isn't working (just for the record, as I think it should be implemented in a complete different way): after connecting the admin account to my remote webid I see "me" instead of "admin" on the top right. Clicking on that "me" yields to a 404 page.

        Show
        Reto Bachmann-Gmür added a comment - A detail that isn't working (just for the record, as I think it should be implemented in a complete different way): after connecting the admin account to my remote webid I see "me" instead of "admin" on the top right. Clicking on that "me" yields to a 404 page.
        Hide
        Henry Story added a comment -

        >> A Veto the proposed resolution to CLEREZZA-515 for the following reasons:

        I'll answer your points below carefully. I am doing it here, because I saw no detailed
        response in the mailing list.

        >> - WebId Users no longer show up in the usermanager.

        That is probably because the user manager is working on the notion of "user"
        as being only determined by zz:username string. The WebID user is identified
        with a URI on the other hand. He does not yet have a username, and may
        in fact never desire to have a local account on your machine. Imagine all the
        WebID robots that may just come and fetch a page from your machine, just because
        they are crawling a foaf file. Are you going to give account names to each of them?

        What account names?

        The only way you can do this is by giving ugly account names to all users ie: mechanically generated ones. When some of these users then wish to
        have memorable names you will then have a problem of dealing with the legacy names
        they were given.

        >> this is a major regression as the usage p'attern currently known to me is as follows:
        >> my friends log-in with webid and the I go to user-manager and give
        >> them additional rights

        It is only going to be MAJOR for you reto and a couple of other people, since not that many are using WebIDs.
        So it is not that big of an issue.

        In any case it is not very satisfactory in a more distributed world (it is fine
        for closed worlds) for quite a number of reasons:

        1. the account control panel only shows you a small set of information about that user. My guess is that it will just
        show the claimed username and something else.
        2. It is not declarative enough.

        The better solution is to add the webids to your friends list, and then have rules such as

        "all friends of mine can do X"

        This is where I think we need to be moving towards in terms of access =
        control.

        So then it remains to make it easy to add people to your friends list. =
        This is why I have been developing the person browser

        Here is the view on Dan Brickeley

        https://bblfish.net:8443/browse/person?uri=3Dhttp%3A%2F%2Fdanbri.org%2Ffoaf.rdf%23danbri

        Users that do have accounts on my machine, will see little buttons appear that will allow them in one click to add Dan as friends. That will then give Dan Access to all the things they allow their friends to access - without requiring Dan to have an account!

        >> - The Issue is about showing the name that is good looking, imho the
        >> foaf:Name would satisfy this requirement better than the WebId URI

        The issue is not just about the name that is displayed in the UserInterface. Of course a foaf:name can be put there. The issue is that the current =
        solution also creates ugly account names, such as

        http://farewellutopia.com/user/http_bblfish.net_.../profile

        Account names should only be needed when people have decided to open a local account.

        >> - Even if I give all users permission to access the account-control-panel (selecting
        >> (org.apache.clerezza.platform.accountcontrolpanel.AccountControlPanelAppPermission
        >> "

        {username}" "") for the base-permission-role) Roaming Users no longer
        >> see the ACP. This is probably a problem that {username}

        is no longer
        >> supported.

        Yes, users without local accounts, don't have an account to look at. That is why I have been developing the ProfileViewer, so they can look
        at what we see of their profile as their home page, if they want. That page can then also ask them if they wish to create an account locally.

        That is the moment at which they can then choose the account name they prefer to have. That is an extra service that is easy to add.

        >> - The resolution goes far out of the scope of the issue. I have no
        >> strong opinion on whether the larger refactoring from using Subjects
        >> instead of the UserName is beneficial. I think I'd tend to postpone
        >> such a refactoring (if it turns out to be needed) to after the first
        >> release. BUT: even if I should conclude that the refactoring is needed
        >> or even urgent this should be in a dedicated issue and not in one that
        >> addresses the aesthetics of the shown account name ("ugly")

        I think this patch addresses the full aspect of account names. The
        initial description showed the place where that ugliness appeared. But this
        is in line with the rest of my work on the authentication in Clerezza
        related to WebID.

        >> A solution to show the foaf:name (or atlernatively foaf:nick) on the top-right corner shouldn't take more than a patch
        >> of a couple of lines. I show on my wall at https://farewellutopia.com/public-wall that it is possible with
        >> existing infrastructure (the post show the foaf:name) to implement
        >> this.

        When I go there I still get the huge ugly name. But anyway, I don't doubt that you can replace it by a foaf:name.
        That is not the only issue that is being addressed here.

        Show
        Henry Story added a comment - >> A Veto the proposed resolution to CLEREZZA-515 for the following reasons: I'll answer your points below carefully. I am doing it here, because I saw no detailed response in the mailing list. >> - WebId Users no longer show up in the usermanager. That is probably because the user manager is working on the notion of "user" as being only determined by zz:username string. The WebID user is identified with a URI on the other hand. He does not yet have a username, and may in fact never desire to have a local account on your machine. Imagine all the WebID robots that may just come and fetch a page from your machine, just because they are crawling a foaf file. Are you going to give account names to each of them? What account names? The only way you can do this is by giving ugly account names to all users ie: mechanically generated ones. When some of these users then wish to have memorable names you will then have a problem of dealing with the legacy names they were given. >> this is a major regression as the usage p'attern currently known to me is as follows: >> my friends log-in with webid and the I go to user-manager and give >> them additional rights It is only going to be MAJOR for you reto and a couple of other people, since not that many are using WebIDs. So it is not that big of an issue. In any case it is not very satisfactory in a more distributed world (it is fine for closed worlds) for quite a number of reasons: 1. the account control panel only shows you a small set of information about that user. My guess is that it will just show the claimed username and something else. 2. It is not declarative enough. The better solution is to add the webids to your friends list, and then have rules such as "all friends of mine can do X" This is where I think we need to be moving towards in terms of access = control. So then it remains to make it easy to add people to your friends list. = This is why I have been developing the person browser Here is the view on Dan Brickeley https://bblfish.net:8443/browse/person?uri=3Dhttp%3A%2F%2Fdanbri.org%2Ffoaf.rdf%23danbri Users that do have accounts on my machine, will see little buttons appear that will allow them in one click to add Dan as friends. That will then give Dan Access to all the things they allow their friends to access - without requiring Dan to have an account! >> - The Issue is about showing the name that is good looking, imho the >> foaf:Name would satisfy this requirement better than the WebId URI The issue is not just about the name that is displayed in the UserInterface. Of course a foaf:name can be put there. The issue is that the current = solution also creates ugly account names, such as http://farewellutopia.com/user/http_bblfish.net_.../profile Account names should only be needed when people have decided to open a local account. >> - Even if I give all users permission to access the account-control-panel (selecting >> (org.apache.clerezza.platform.accountcontrolpanel.AccountControlPanelAppPermission >> " {username}" "") for the base-permission-role) Roaming Users no longer >> see the ACP. This is probably a problem that {username} is no longer >> supported. Yes, users without local accounts, don't have an account to look at. That is why I have been developing the ProfileViewer, so they can look at what we see of their profile as their home page, if they want. That page can then also ask them if they wish to create an account locally. That is the moment at which they can then choose the account name they prefer to have. That is an extra service that is easy to add. >> - The resolution goes far out of the scope of the issue. I have no >> strong opinion on whether the larger refactoring from using Subjects >> instead of the UserName is beneficial. I think I'd tend to postpone >> such a refactoring (if it turns out to be needed) to after the first >> release. BUT: even if I should conclude that the refactoring is needed >> or even urgent this should be in a dedicated issue and not in one that >> addresses the aesthetics of the shown account name ("ugly") I think this patch addresses the full aspect of account names. The initial description showed the place where that ugliness appeared. But this is in line with the rest of my work on the authentication in Clerezza related to WebID. >> A solution to show the foaf:name (or atlernatively foaf:nick) on the top-right corner shouldn't take more than a patch >> of a couple of lines. I show on my wall at https://farewellutopia.com/public-wall that it is possible with >> existing infrastructure (the post show the foaf:name) to implement >> this. When I go there I still get the huge ugly name. But anyway, I don't doubt that you can replace it by a foaf:name. That is not the only issue that is being addressed here.
        Hide
        Reto Bachmann-Gmür added a comment - - edited

        Posting detail here, while having the big architectural debate on the mailing list:

        The idea of having a link on the name tio the ACP is nice, but it should be only for people which do in fact have the reight to access the ACP (like the menu item).

        And the presence of the link seems to be orthogonal to the niceness of the account-name, so I think it should be addresses by another issue.

        Show
        Reto Bachmann-Gmür added a comment - - edited Posting detail here, while having the big architectural debate on the mailing list: The idea of having a link on the name tio the ACP is nice, but it should be only for people which do in fact have the reight to access the ACP (like the menu item). And the presence of the link seems to be orthogonal to the niceness of the account-name, so I think it should be addresses by another issue.
        Hide
        Henry Story added a comment -

        Reverted changes, though will keep them on the bblfish branch, as I have not seen any good reasons against them.

        The ugliness problem was dealt with in depth here. The issue of what it looks like on the user front page was just one symptom of the problem of forcing usernames as identifiers of a person when no such identifier is needed, such as for WebID logged in users, or perhaps even OpenID logged in users.

        This is not a criticism of the initial decision to use account names, btw. That was a good expedient to get things and see how things were working. But we might as well move to the next stage which this patch was about. What did it do:

        Currently the system graph contains statements like this:

        _:anon a <http://xmlns.com/foaf/0.1/Agent> ;
        <http://clerezza.org/2009/08/platform#userName>
        "anonymous" .

        :joe a <http://xmlns.com/foaf/0.1/Agent> ;
        <http://clerezza.org/2009/08/platform#userName>
        "joe" .

        This patch allowed statements like this:

        <http://bblfish.net/#hjs> a foaf:Agent .

        ie without the need to create an arbitrary zz:userName .

        The handle of the agent should be _:anon, :joe and <http://bblfish.net/#hjs> .

        This make it possible then to have people authenticate with OpenID, and then add the following
        to the system graph.

        _:somone foaf:openid <http://openid.org/joe> .

        Or using fingerpoint with

        _:someone foaf:openid <accnt:henry.story@gmail.com> .

        Given the openid is really designed for humans more than robots, it makes more sense to give users that authenticate that way an account. But it is clear that it would be preferable to do that AFTER the user has authenticated, and perhaps had a bit of fun on the site, at which point he can decide what kind of account name he would like to have, and simply add the relation

        _:somone zz:accountName "joe" .

        As I was a bit in a hurry to get this out for the Identity in the browser Workshop in California - the presentation is online here http://bblfish.net/blog/2011/05/25/ - I probably did not go into enough explanation of what this patch was doing, and understand that it may on first look have seemed somewhat larger answer to the problem than might have seemed necessary. But on closer inspection I am sure others here will agree that the general gist of this is the right solution, and one that Clerezza being a semantic web engine is in an excellent position to enable - I can see that making this possible in SQL or imap environments would be a lot more difficult.

        Of course there can be improvements to the way things are being done here, and I will be working on some of them on my branch.

        Show
        Henry Story added a comment - Reverted changes, though will keep them on the bblfish branch, as I have not seen any good reasons against them. The ugliness problem was dealt with in depth here. The issue of what it looks like on the user front page was just one symptom of the problem of forcing usernames as identifiers of a person when no such identifier is needed, such as for WebID logged in users, or perhaps even OpenID logged in users. This is not a criticism of the initial decision to use account names, btw. That was a good expedient to get things and see how things were working. But we might as well move to the next stage which this patch was about. What did it do: Currently the system graph contains statements like this: _:anon a < http://xmlns.com/foaf/0.1/Agent > ; < http://clerezza.org/2009/08/platform#userName > "anonymous" . :joe a < http://xmlns.com/foaf/0.1/Agent > ; < http://clerezza.org/2009/08/platform#userName > "joe" . This patch allowed statements like this: < http://bblfish.net/#hjs > a foaf:Agent . ie without the need to create an arbitrary zz:userName . The handle of the agent should be _:anon, :joe and < http://bblfish.net/#hjs > . This make it possible then to have people authenticate with OpenID, and then add the following to the system graph. _:somone foaf:openid < http://openid.org/joe > . Or using fingerpoint with _:someone foaf:openid <accnt:henry.story@gmail.com> . Given the openid is really designed for humans more than robots, it makes more sense to give users that authenticate that way an account. But it is clear that it would be preferable to do that AFTER the user has authenticated, and perhaps had a bit of fun on the site, at which point he can decide what kind of account name he would like to have, and simply add the relation _:somone zz:accountName "joe" . As I was a bit in a hurry to get this out for the Identity in the browser Workshop in California - the presentation is online here http://bblfish.net/blog/2011/05/25/ - I probably did not go into enough explanation of what this patch was doing, and understand that it may on first look have seemed somewhat larger answer to the problem than might have seemed necessary. But on closer inspection I am sure others here will agree that the general gist of this is the right solution, and one that Clerezza being a semantic web engine is in an excellent position to enable - I can see that making this possible in SQL or imap environments would be a lot more difficult. Of course there can be improvements to the way things are being done here, and I will be working on some of them on my branch.
        Hide
        Henry Story added a comment -
        Show
        Henry Story added a comment - reverted with http://svn.apache.org/viewvc?view=revision&revision=1128619 mistakenly attributed to CLEREZZA-516
        Hide
        Henry Story added a comment -

        reverted, but available on bblfish branch

        Show
        Henry Story added a comment - reverted, but available on bblfish branch
        Hide
        Reto Bachmann-Gmür added a comment -
        • as there is not accepted resolution for this issue is must remain open
        • please fix the svn comment to be associuated to this issue
        Show
        Reto Bachmann-Gmür added a comment - as there is not accepted resolution for this issue is must remain open please fix the svn comment to be associuated to this issue

          People

          • Assignee:
            Unassigned
            Reporter:
            Henry Story
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development