ListenLog Identity

Notes on Identity Requirements

When does identity happen? There are at least three contexts where we handle identity

1. Capture data implicitly
   1. No registration
   2. Linked to phone
2. Access to data provisioned through phone
3. Sending listen activity to other data store providers instead of the default store

Perhaps there are others, but these three seem clear so far.

By way of thinking about identity, it is worth noting that there are four distinct functional aspects of identity. Something I call the Identity Quartet (blog post imminent!)

1. For authentication, logging into services (username:jandrieu)
2. For presentation, e.g., as handle on MySpace or Facebook or WOrld of Warcraft (name: Thor the Destroyer)
3. Internally for database level handling of the attributes & privileges associated with a user (users.primaryKey=1023304)
4. As a service endpoint, e.g., joe@andrieu.net

Flexible identity systems separate these four elements. Lazy ones combine, such as using my email address as my username. Or displaying my email address when I comment on a bulletin board system. A good system has distinct identifiers for each of these roles, and in fact, sophisticated ones could/should allow multiple different identifiers of the same functional class, for the same user, such as allowing an individual to have multiple characters on WoW, Iain Henderson calls this aspect of identity "personnas".

So, between the first set of contexts and the four functional types, we should be able to map out what we need for ListenLog.

-j

Identity Workflow

How identity in the LL app(s) might work. This is a proposed workflow based on my limited understanding of how identity systems work:

Khopper 15:19, 10 March 2009 (UTC)

1. ID the data: iPhone app by default will create a unique ID for each install (likely created by combining application ID + device ID) in order to appropriately key the log data to a unique instance (individual)
2. Claim the data: In order to get access to this data beyond the phone, the individual must associate the existing unique ID in #1 with a more friendly and portable identity (i.e. user ID). This could be through a unique external or internal identification process. External might be something like OpenID, internal might be created and assigned through an integrated user registration process. This would have to happen on the phone.
3. To complete the association, the user must authenticate (internally or externally)
4. The LL datastore must associate the UniqueID in #1 with the userID in #2. Ideally, this will be obfuscated in some way to protect the identity of the user (is this possible?).
5. To retrieve the data remotely (e.g. on a website that lets you browse your LL data), you must provide identity credentials and authenticate. This will locate the data and validate your access to it.
6. To write to the data remotely through another application or device (e.g. Pandora), you must follow steps 1-4 above. This should be standardized as part of the LL specification. It is conceivable that there are use cases where data needs to be merged or split by application ID, by user ID, or by Unique ID.