Software Development/Common App Documentation/AddressBook-User-Identity-Demystified

#User/Identity Mapping & AddressBook

##AddressBook

p≡p Applications MUST implement contact management. Contact Management MUST support platform’s contact management first. It MAY support an own implementation, which then must be compatbile with platform’s in case users and/or use cases require that.

Contact management requires to identify people being represented by an ID for each person – or, in case this is not possible, by an ID for each contact. There MUST be a string representation of this ID, and it MUST be used for user_id.

##Addresses

p≡p apps need to implement addresses as either: a) email address b) URI

For p≡p these two addresses are identical: xyz@pep-security.net || mailto:xyz@pep-security.net

Both MUST be supported.

Additionally, addresses can be ANY URIs. While we only have mail transport, these will be addresses just stored. Later on they get usable.

###Addresses of Communication Partners

A Communication Partner is a person involved in a communication that is not myself.

ONE communication partner (user, person) can have MULTIPLE addresses, which are making him/her addressable in the net. communicationPartner:address == 1:n

(Currently only one transport exists. If that changes the user will be able to choose the transport in a drop-down menu or such. Then “email” and xyz@pep-security.net is resulting in mailto:xyz@pep-security.net.)

##User A user represents a physical person. That can be me or a communication partner

For the user of a p≡p app there is exactly one user (own/me/myself).

p≡p requires two fields from a user: user_id and user_name.

(According to the known scheme: “Peter Falk ”, without quotes)

###User Name Examples: Title: “Prof.” Forename: “Peter” Middle: "" Surename: “Falk”

Resulting User Name: “Prof. Peter Falk” (inlc. “Prof.”)

Resulting Mapping: “Prof. Peter Falk

Title: “Mr.” Forename: “Peter” Middle: "" Surename: “Falk”

Resulting User Name: “Peter Falk” (excl. “Mr.”)

Resulting Mapping: “Peter Falk

##User:Identity Mapping: The mapping between user and identity is handled different for the one and only own user and communication partners.

###Pseudonym p≡p is supporting pseudonyms. From user perspective “identity” is a friendly word for “pseudonym”.

For own identities we support our user to have more than one.

Outgoing messages ALWAYS MUST have a username in “From:” (own identity). In other words, the application MUST tell the Engine how the user is named for this message.

For identities of communication partners we try to help our user to uncover pseudonyms by trying to map used pseudonyms to one user. (more below)

###Mapping For OwnUser/Me/Myself Own identities ALL have a (maybe different) username (NOT per user, per identity).

Own identities DO NOT share the username

ALL own identities MUST store a username

{ own user: user_id } 1->m { own identity: name, address}

When presenting contacts to the user we DO talk about identities (the pseudonyms) for own identities.

###Mapping For Communication Partners (comm_partners)

Partner identities DO share the username. Partner identities must have ONE username ONLY (per user, NOT per identity) While for an address book with communication partners it’s storing ONE username ONLY per contact/user, and NOT per identity

{ own user: user_id, name } 1->m { own identity: name, address}

(To be able to map different partner identities to one user, we need access to the SystemAddressBook, which is not guaranteed on all supported platforms).

When presenting contacts to the user we DO NOT talk about identities for comm_partners

Chat log

    17:38 < fdik> dirk: p?p for iOS MUST have an address book
    17:38 < fdik> dirk: no way around
    17:38 < fdik> dirk: preferred: having the system address book
    17:39 < fdik> dirk: no address book, no p?p
    17:39 < huss> fdik: then that is also true for android, as the user can block the acces to system address book
    17:40 < dirk> fdik: Ok, but what's the point of having an own address book (not the system one)? We can never map user
                  through this.
    17:41 < andreas> dirk: We do map the user, or not. I do not get it.
    17:42 < dirk> andreas: Without the user's address book, we never learn of email addresses pointing to the same user.
    17:42 < dirk> andreas: Except of course for our own addresses.
    17:43 < dirk> andreas: Without system address book, every single Identity has its own UUID.
    17:45 < andreas> dirk: that i correct. But "without addressbook" happens only if we are technically not able to access it,
                     because of missing permissions
    17:45 < andreas> dirk: otherwize we do the mapping
    17:46  * andreas is going back fighting Gmail and will not leave the office before done
    17:48 < fdik> andreas:
    17:49 < fdik> dirk: an address book needs to be designed as list of communication partners (people), where all have more
                  than one address in the internet

    17:49 < fdik> dirk: p?p apps need to implement addresses as either
    17:50 < fdik> a) email address
    17:50 < fdik> b) URI
    17:50 < fdik> dirk: for p?p these two addresses are identical:
    17:50 < fdik> dirk@pep-security.net || dirk@pep-security.net
    17:50 < fdik> dirk: you need to support BOTH
    17:51 < fdik> dirk: additionally, addresses can be ANY URIs
    17:51 < andreas> fdik: have more
    17:51 < fdik> dirk: while we only have mail transport, these will be addresses just stored. Later on they get usable
    17:51 < andreas> sorry, mistake    ^^^^
    17:52 < andreas> fdik: "more than one " == n or == 2?
    17:52 < fdik> dirk: so ONE communication partner (user, person) can have MULTIPLE addresses, which are making him/her
                  addressable in the net
    17:52 < fdik> andreas: n

    17:52 < fdik> 1:n
    17:53 < fdik> andreas, dirk: presenting networks can be done by UI
    17:53 < fdik> dirk: i.e.: drop-down with "email" and dirk@pep-security.net is resulting in dirk@pep-security.net
    17:54 < fdik> dirk, andreas: and while only one transport exists, "email" can be a static text instead of a drop-down list,
                  of course
    17:54 < andreas> dirk: maybe we should introduce a "user" entity in MessageModel that has a 1:n relationship to identity
    17:54 < fdik> andreas: exactly
    17:54 < fdik> "user" or "contact" or "communication partner" or "person"
    17:54 < fdik> In p?p it's "user"
    17:54 < fdik> p?p engine us needing TWO fields from a user: id and name
    17:55 < fdik> name must be the combined full name
    17:55 < andreas> dirk: that would also solve confusion in regards or the user_id
    17:55 < fdik> it's pretty much what you have with "Dirk Zimmermann <dirk@pep-security.net>"
    17:55 < fdik> (without the quotes)

    17:57 < fdik> Title: "Prof." Forename: "Dirk" Middle: "" Surename: "Zimmermann" is resulting to "Prof. Dirk Zimmermann
                  <dirk@pep-security.net>"
    17:57 < fdik> While Title: "Mr." Forename: "Dirk" Middle: "" Surename: "Zimmermann" is resulting to "Dirk Zimmermann
                  <dirk@pep-security.net>"
    17:57 < fdik> (without "Mr.")
    17:58 < fdik> Something like this
    17:58 < fdik> In the first case, username is "Prof. Dirk Zimmermann"
    17:58 < fdik> In the second case, username is "Dirk Zimmermann"
    17:58 < fdik> For OWN identities, it's DIFFERENT
    17:59 < fdik> Own identities ALL have a different username
    17:59 < fdik> They DO NOT share the username
    17:59 < fdik> While identities of communication partners DO
    17:59 < fdik> Today p?p engine is expecting own username ALWAY in all calls
    17:59 < fdik> Because the stored value cannot be used
    18:00 < fdik> And should be overwritten all the time

    18:00 < fdik> This is relevant for outgoing mails
    18:00 < fdik> outgoing messages are expecting to have a username in From: own identity ALWAYS
    18:01 < fdik> p?p is supporting pseudonyms
    18:01 < fdik> That's how we do this
    18:01 < fdik> The app has to tell how the user is named for this message
    18:02 < fdik> So when you're implementing for storing own identities
    18:02 < fdik> ALL of them need to store a name
    18:02 < fdik> While for an address book with communication partners it's storing ONE username ONLY per contact/user, and NOT
                  per identity
    18:04 < dirk> fdik: We have to support pseudonyms?

    18:15 < fdik> dirk: yes, all p≡p apps have to fully support pseudonyms
    18:15 < fdik> dirk: on the outgoing side, for the own user
    18:16 < fdik> dirk: on incoming they have to support own user to sort this out, it's exactly the
    opposite task
    18:16 < fdik> dirk: therefore the asymmetry

    18:15 < fdik> dirk: yes, all p?p apps have to fully support pseudonyms
    18:15 < fdik> dirk: on the outgoing side, for the own user
    18:16 < fdik> dirk: on incoming they have to support own user to sort this out, it's exactly the opposite task
    18:16 < fdik> dirk: therefore the asymmetry

    18:21 < andreas> fdik: what is the definition of pseudonym? One userName  per identity that can be changed by the user?
    18:23 < andreas> And now something completely different:
    18:24 < andreas> if I got or sent an unencrypted mail
    18:24 < fdik> andreas: the concept of p?p is creating ONE keypair PER OWN IDENTITY
    18:24 < andreas> and then delete it
    18:24 < fdik> andreas: therefore, there will be only one uid per p?p key (without aliases)
    18:25 < andreas> is it OK to save it unencrypted to trash folder?
    18:25 < fdik> andreas: when supporting aliases, it's ADDRESS aliases ONLY
    18:25 < fdik> If trash is on the phone (which it has to be), yes
    ...
    18:28 < fdik> { own user: id }n -> { own identity: name, address [, address_alias [, address_alias [, ... ]]]  }
    18:28 < fdik> andreas: only if everything is duplicated into the Clown^H^Hud
    18:29 < fdik> { comm_partner: id, name } -> { identity: address, [, address_alias [, address_alias [, ... ]]]  }
    18:29 < fdik> "->" is 1:m
    18:30 < fdik> This is the asymmetry I'm talking about
    18:31 < fdik> aliases for own addresses are mandatory
    18:31 < fdik> aliases for addresses of comm partners are optional (most users will not use that and may get confused, so if
                  you implement them, make it optional in UI)
    18:32 < fdik> To  present the comm_partner, show it as contact with addresses
    18:32 < fdik> DO NOT talk about "identities" for comm_partners
    18:32 < fdik> DO talk about identities for own identities
    18:32 < fdik> => it's completely asymmetric

    18:33 < fdik> "identity" in user's view is a friendly word for "pseudonym"
    18:33 < fdik> For own identities we support our user to have more than one
    18:34 < fdik> For identities of communication partners we help our user to uncover that and store how it really comes
                  together
    18:34 < andreas> fdik: OK.
    18:35 < fdik> andreas: may I ask you to convert this IRC conversation into some documentation in the Wiki?
    18:35 < fdik> andreas: I've the feeling it can be useful for other p?p developers, too
    18:35 < andreas> fdik: Already made a Jira ticket do exactly that IOS-945
    ...
    18:36 < fdik> andreas: hm... really? 

Additional Info:

    Subject: Re: pEpAddressbook & Pseudonyms On Wed, Feb 14, 2018 at 12:45:19PM +0100, Andreas Buff wrote:


new questions pop up trying to create specs for the pEpAddressBook and pseudonym support. *

1) < fdik> { own user: id }n -> { own identity: name, address [, address_alias [, address_alias [, ... ]]]  }

This is a n:m relation, correct?

    No. I just see it: it's a typo. There is one “n” too much. What I wanted to say is: “For the own user, the name is with the identity, while for communication partners, the name is with the user”.

/"There is one, and ONLY one ”own user” in the database"/ (from "Engine Demystified" slices). 



    This is correct.

Btw: Our current implementation is like this: 
{ own user: id }1 -> { own identity: name, address }


    Keep it like this. Yours, VB.

Ongoing:

14:31 < andreas> fdik: If we have a communication partner named "XYZ" with two addresses AX, AY and then get a message
                 from AX with name "SEC", we should override the old name (XYZ) with the new one (SEC).
14:31 < andreas> fdik: ^^^ please confirm
14:32 < andreas> fdik: in other words, the last received name wins
...
16:04 < fdik> andreas: the stored name wins
16:04 < fdik> andreas: please provide the username of your contact
16:05 < fdik> andreas: there can even be more heuristics
16:05 < fdik> andreas: if manual username set (dirty flag managed) then manual entered name superseeds all
16:05 < fdik> andreas: if not then store what's coming in
16:06 < fdik> andreas: if the stored name has no blank (ASCII 0x20) and the new one has a blank, and the stored one is not
              manually set, then overwrite with the new one
16:06 < andreas> fdik: question was assuming we run our own addressBook (as we have no access to the systemAddressBook)
                 and the user did not manually type a name in pEpAddressBook
16:07 < andreas> fdik: so all we know is the user sent 1 msg yesterday with name "XYZ" and th same "from" address sends a
                 msg tody with name "SEC".
16:10 < fdik> andreas: there is more, one second, I'm busy
16:10 < andreas> fdik: its not urgend
16:23 < fdik> andreas: but important