[Freedombox-discuss] Identity Management wiki entry

[bertagaz at ptitcanardnoir.org]

On Tue, Aug 16, 2011 at 11:25:04PM +1000, John Walsh wrote:
>  Hi Everybody
> 
> > In the described scenario of this page, the activist would 
> > have one login on the FBX, from which she would manage 
> > different identities, one for the personnal 
> > activities/relations/etc, another for the more activist part 
> > of it. Each of them could use services hosted on different 
> > FBX and domains, i.e could use a mail server hosted on a 
> > remote FBX, but use the friendika instance running on the 
> > same FBX she logs into.
> Bert, I understand what you mean by identities now, with help from Melvin
> too ;)I realise now that term "identity" should be used instead of
> "username". So, do you agree there would be a separate identity for each
> language that a multi-lingual person uses? 

I guess it is up for the user to use it this way. One could separate based
on this criteria for sure. Another couldn't mind to have multilingual
communications using a single identity.

> Bert, in your scenario you say the activist would have one login for two
> FBX's, one for personal use and one for activist use. The FBX is targeted at
> the home. Does this mean the activist will have two FBX's in their home?
> Could one FBX do the same with two domains?

That is not really what I was describing, but it is also not something
that can't be changed. :)

What I was trying to explain was that the user would have one login on one
FBX, that would be the central place to manage some identities. But for
sure she could have another login on another FBX to manage some other
identity. It might even be better in some cases, to have a very strong
separation between identities and avoid wrong manipulations.

Identities in this context would be the owners of accounts on services.
This services could be hosted on the same FBX, on another, on different
FBX. For example this identity could use an account on a microblogging
service on FBX1, and use the mail server of FBX2.

Depending on their situation, it might be wise for some activists not to
host their FBX at home, which can be the first place where people would
search their data. So they can either host their freedombox somewhere
else, or use someone else FBX.

One FBX could do this with two domains, for sure. But it has to be
considered that it will be public that this two domains are sharing the
same IP/internet access.

> > > *	
> > > Identit{y,ies}: refers to a virtual (or service) identity. 
> > > 
> > > Identities should be able to use several services, not 
> > always hosted 
> > > on the same  <http://wiki.debian.org/FreedomBox> FreedomBox. Thus 
> > > there should be a way to publish this information, either 
> > publicly or privately.
> Do the different FBX's have the same owner? How does having two FBX's help
> publishing either publicly or privately?

The two FBX could and could not have the same owners :). One could consider
hosting a FBX at home for non really dangerous data, and another somewhere
else for example.

> > I prefer the "Identity" term over the "Username" one, because 
> > the later is a bit confusing. It is most often used to refer 
> > to account username, or login, which is only one small part 
> > of the picture this page is trying to draw. It's reference in 
> > the glossary is certainly confusing, badly worded, and 
> > probably should be more clearly explained. Actually the 
> > definition on the W3 webpage Melvin pointed at in his answer 
> > to your mail has an interesting definition for it.
> I like Melvin's definition too. Identity is the correct term. Username is
> wrong.

So we should probably update the definition on the wiki.

> Bert, I was trying to document all the different roles people would have on
> the FBX, while at the same time using labels people would understand from
> existing experiences. I was concerned you weren't documenting all the roles,
> but I realise now you were deliberating narrowing your scope to identities.
> 
> *Going Forward*
> In a thread the other day I learnt that the network protocols have separate
> layers. I was thinking we could have a *user/people model* (what do you
> think of the name?) that would have separate levels such as User, Identity,
> Privacy, Directory, Application. Each level builds/references the previous
> level.
> 
> At the User level you would describe the different "login" accounts such as
> "owner", "local", "guest", "group member", "subscriber" to the FBX. 

What are "subscriber" and "group member" referring to? Having an optional
guest login might be an interesting feature.

> At the Identity level, for each "local" user the FBX could automatically
> generate a different identity for each (different) language, etc. At the
> identity level you would also need to cater for the "personal" and
> "activist" persona's which will overlap with languages. Identities need to
> be linked to domains/FBX's too. Username would be an attribute of an
> identity. Lots to discuss in this space.

Yep. I'm not sure identities should be created automatically thought,
should rather be up to the user to create them, and after that attach
service accounts to it.

> At the Privacy level you would have to manage the release of personal
> identifiable/ personal information through relationships (sibling,
> sweetheart etc.) and user actions (like) as indicated in Melvin's document.
> There would be different profiles for each identity/language.
>
> At the Directory level you would have contacts and circles views depending
> on chosen identity. The identity directory view would interact with all
> applications e.g. email, calendar, social network app etc. The directory
> level could also interact with the "social applications" described in
> Melvin's document

This interaction could be very hard to implement, it might mean modifying
the chosen applications to be able to understand the system that would be
chosen to manage users/identities in the freedombox.
At this level I was only thinking to something really basic, which would
only be verifying others identities ownership, managing a trustdb. This
would be done using GnuPG, and with the help of monkeysphere could help in
securing the communications in the application level. This is in my
opinion the "easiest" way to go.

> At the Application level, you only define the FBX applications that
> introduce new people models or you define what people models each app uses. 

If by "Application level" you mean the services (microblogging, email,
social network applications) I was referring to earlier in this mail, then
as I said previously in this level more interaction would happen. In fact
a part of the actions you put in the "Directory level" would happen there
(the most social network part of it), because otherwise it seems we'd put
a lot of energy to do in the Directory level what the Application level is
already able to do, and what it is done for.

> Of course, the different levels offer the option to have separate wiki
> entries for each level which could be linked to a *master/parent* document,
> which would have a nice FBX user model vision diagram like Melvin's document
> ;)
> 
> Bert, in the identity management wiki entry you could focus on identity
> management and when you need to reference users you would just have to link
> to the user wiki entry.

Sounds good.

> I know it sounds quite ambitious and I can't do diagrams :( Still it does
> provide structure offering the option to work in small chunks and
> independently, building up the documentation as the developers build their
> different layers.

It is ambitious for sure. I only begin to understand what you are thinking
about. You should maybe start to write down all that and organize it on
the wiki, so that we can start to draft and note things there.

> The *user model* is based on a user centric view and I am not sure if this
> fits in with developers. One problem with this model is that there is no
> *user data" level, which I can't make fit. This model is probably broken in
> other ways too and may not work at any level for developers. Still help me
> find a way forward.

Probably the data here would reside on the FBX where the service is
running in the scenario we are discussing. There might exist ways to put
them all in one place though. Maybe this Locker application I pointed out
in a mail some days ago might help to achieve this.

Thanks for your inspiring email anyway. Looing forward to continue this
discussion. :)

bert.