WS-Fishy in Denmark

Tag Lady points to a interesting decision from the Danish Government.

Makes me proud of my Danish heritage.

PKI - the four letter acronym

Entrust, after the last few years spent trying to deny their PKI heritage, seem to be now embracing it - even to the extent of hiliting it on their home page.

Calendar Confusion & Shared Credentials

I was playing around on the new Google Calendar and searched on 'identity' in the available public calendars. I hit on a calendar owned by an identity colleague. Interspersed amongst industry events were a few that appeared out of place, e.g. 'Girls Night Out' and 'Take kids to school'.

My own personal calendar has lots of the latter type events (but distressingly few of the former) so I can definitely sympathise with the confusion by which these private events snuck into the public calendar.

It also points out an interesting issue, the private events that snuck in actually belonged (in the sense of who was going to be attending) to my colleague's wife. Google allows you to create separate categories for events (labelled as different calendars under the same Google account) and treat them differently with respect to sharing - which is what my colleague (call him Husband) did.

Also possible would have been for the lady of the house (call her Wife) to have created her own calendar under her own account, make it public and exportable, to be then imported into that of Husband. Likewise for the reverse direction - each would see their own events as well as those of their partner.

Another possibility would be for one or the other to define a 'Family Calendar' of shared events (e.g. dinner parties, vacations, etc) - this to be imported into both the personal calendars of Husband and Wife. When Husband viewed his calendar, he would see his own events as well as the shared family events - likewise for Wife. Importantly, neither would need see the details of the personal events of the other (except perhaps availibility for scheduling purposes).

This concept of shared resources (the family calendar) is important to operators and ISPs because there are situations in which an authentication, while insufficient to enable access to private resources, may be sufficient to enable access to such a shared resource. This sort of authentication is generally passive - consisting of the user opening some communication channel - and so of interest to those who provide such communication channels.

Consider Husband accessing the internet through the home PC he shares with Wife. The implicit authentication performed when he accesses the Web from the static IP associated with his ISP account can be sufficient for the ISP to identify him as one of the set of users associated with that account, and who therefore can view the shared calendar. But, because the "credential" by which Husband authenticated to the ISP (possession of that IP address) is shared with Wife - the ISP would be unable to determine which of the two was actually authenticating. But that's OK, because the access rules for the Family calendar would stipulate that anybody coming from that IP address would be allowed to view (and likely change) the Family Calendar.

If however, Husband then wished to view his own private calendar, the ISP would need to authenticate him as an individual in order to disambiguate him from Wife. At this point, he would then present a password etc unique to his account - the shared credential no longer sufficient for the task at hand.

When the resources being accessed are remote from the entity authenticating the user (e.g. if Google was hosting the various calendars but Husband and Wife were being authenticated by their ISP) then the Service Provider (Google) needs a way to stipulate to the Identity Provider (ISP) its requirements of an authentication (e.g. I need something that pinpoints the user as an individual).

Fortunately, SAML 2.0 provides a framework that allows Service and Identity Providers to discuss just such details about how the user authenticates (and much more) - its called Authentication Context. Work is currently under way in the SSTC to explore whether the existing Authentication Context mechanisms in SAML 2.0 need be extended to support this concept of Shared Credentials.

Ingenious eh?

The rubber of my iPod Mini holder split at the back where the armband went through.

To keep it together I wrapped it round with good ol' Canadian Tire hockey tape (red no less).

Duct tape just seemed so 90s.

You show me yours ....

I can think of a number of situations where I might be willng to release some slice of my identity only if the individual making the request (or on whose behalf the request was being made) was willing to share that same information (or perhaps even some other aspect of their identity) with me.

For example

• geolocation - if you want to know where I am, before I decide to approve the request I want to know where you currently are. Maybe I won't share mine if you are within a certain minimum distance.
• home address - similar to above but perhaps I'll only release my address if you live in the same city
• marital status - 'nuff said
  

This quid pro quo is a normal part of offline interactions, the sometimes not-so-subtle negotiation that we engage in before giving up some otherwise private piece of info. Sometimes merely the act of sharing is sufficient, other times the actual value of the data matters (e.g. 'what is your salary?')

To duplicate this in the digital world would require a number of pieces (not necessarily all):

1. the ability to express this preference as an access control policy.
2. the ability for this preference to be advertised to potential requestors, or the ability for non-compliant requests to be failed with appropriate fault information.
   
3. the ability for a request for some piece of identity to include any of
1. the same piece of identity for the requestor.
2. the location of the same piece of data for the requestor.
   
3. how to discover the same piece of data for the requestor.

Identity Middlespace?

Ross Mayfield writes of the middlespace - a hypothesized region where bottom-up phenomena meet top-down in a synergistic collision.

One quote caught my eye:

...when rules are kept simple and incentives are provided from the Top-down, the energies of the Bottom can be realized for mutual gain. However, negotiating the sharing of control is both ripe with risk and opportunity.

In today's identity, SAML, Liberty, and Infocard are typically presented as top-down initiatives; LID, OpenID, YADIS as bottom-up.

Notwithstanding that this distinction is, in some aspects, either completely wrong (Liberty can support user-hosted identity for instance) or a gross oversimplification (top-down identity provides more than governance and incentives, and bottom-up provides more than merely enthusiasm); the identity metasystem at least promises to be where top-down and bottom-up identity meet. The "identity middlespace".

One challenge (with associated risk) will be in dealing with the impedance mismatch presented by the different security & privacy characteristics of the various systems. Different use cases (blog commenting vs 401K access) result in (appropriately) different sets of requirements, which subsequently manifest themselves in varying security & privacy characteristics. Step-down might be easy, step-up though?

Risk and opportunity - rife indeed.

Alice doesn't live here anymore

In developing the Liberty People Service, we often relied on a particular use case (a principal named Bob trying to determine the coordinates of his friend Alice) to help us clarify requirements.

Having one user ask (or more likely a provider asking on behalf of that user) for a resource 'owned' by another, and maintaining the privacy of each through pairwise pseudonyms, presented us with a variety of challenges, both conceptual and technical.

Over time, Bob and Alice (and sometimes the mysterious 'Tony', was he Alice's friend or what? He just kind of showed up) almost became honourary members of the Technology Expert Group.

But, overtime, familiarity bred contempt.

Bob, I am sick and tired of your incessant whining and repeated 'Where are you Alice?'. Take the hint buddy. If she liked you don't you think she'd actually be close enough that you wouldn't have to ask? And Alice, how about being honest for once in your life and just tell Bob how you feel? Women like you make me sick with how you lead guys on!

Jigsaw 's Missing Pieces

Jigsaw presents itself as

an online business contact marketplace where marketers, recruiters, and sales people can buy, sell and trade business contact information

Members buy their way in, either through a monthly subscription fee or by providing a certain number of their contacts to the system. Yes, the currency is the contact info of your friends and colleagues.

So, if you hand me your business card, I can effectively sell that information to Jigsaw. My gain, your (through the potential for cold calls from salespeople) loss.

You almost certainly weren't thinking of my abusing the privilege in this way when you gave me your business card. But, beyond scribbling across the front a non-enforceable 'Not for Resale', there is not much you can do to stop me.

If however, you had initially provided me your contact info digitally, then you could at least be given mechanisms/syntax in order to express any restrictions you might wish to impose on me. Such restrictions could include limiting sharing, constraints on contact (e.g. don't use IM before noon), or limits on how long the info could be stored).

Such preferences would still almost certainly remain unenforceable but I could no longer claim innocence or ignorance. Importantly, neither could Jigsaw if the preferences stayed with the contact info if and when submitted there.

Identity Rights Agreements would make this possible.

Liberty adoption

Liberty's latest newsletter indicates that adoption is soaring.

We're like a MySpace with far fewer predators.

In a previous life ...

I played alot of Ultimate in the Ottawa-Carleton Ultimate Association league (which used to be the largest in the world, perhaps still is), the monthly newsletter and web site for which I used to write a piece parodying Jack Handey's Deep Thoughts.

I've started a new blog at Cheap Thoughts to begin a list of the collection.

I feel your pain

Like myself, John Kemp is close to 40 (but the other side of it) and feeling the "slings and arrows of outrageous fortune" associated with this age and corresponding life milestones.

But he still enjoys getting out for a run, as I do. Maybe a slower pace, probably a stop mid-way through, almost certainly not as long, but at least I'm not wearing velcro walking shoes.

Who'd have thunk ....

... that a search on user-centric would return a reference to Microsoft Hailstorm.

Also, from a 2001 speech (in which there are a sickenly polite 26 'thank you's!) by Bill Gates:

So today is a milestone for us. It’s the public rollout of these user-centric XML Web services. It is a new model for user-centric computing. This is not the world of cookies and things that are very opaque to users. This is a world of a very explicit schema that you choose how you want to control the different parts of that schema in terms of how you fill in the information and where it is made available.

In addition to control, it seems that Microsoft (or maybe just Bill) saw the transparency of the system to its users as key to its user-centric nature. This wasn't some invisible cookie, but mechanisms that directly and explicitly involved the user in identity transactions. Hints of Infocard.

This principle appears to have evolved into Kim Cameron's "Laws" of 'human integration' and 'consistent experience'.

Social Mobs

This summary is not available. Please click here to view the post.

Frapper Map for Identity Podcast

Aldo has created a Frapper Group Map for listeners of his 'The Story of Digital identity" podcast.

I'm proud to be the first Canadian.

Numly & MicroID?

MicroID is a recent proposal by which publishers can lay claim to their content by embedding a microformat within that content.

Numly does something similar. I used Numly's Firefox extension to create the following ESN for this blog.

70509-060414-622231-41

© 2006 All Rights Reserved.

The Numly blog has a post on how they might use microformats.

By my count, there is an extra line in the above bar code.

I'd rather have the arm room

AirTroductions - four thoughts:

1. Incredibly hokey and awkward name. AwkwardSilences.com would be more appropriate.
   
2. Until they hook into the airlines booking systems or Expedia etc, I'm going to have to enter my flights by hand?
3. HotelBuddies.com must be next. Think of the economies.
   
4. Everything I do, from chosing my seat, to glaring at my seatmates at first sight, to pretending to be asleep or listening to music, is designed to ensure I don't have to talk to people on a flight.

I wonder if it's possible to specifically ask to be seated as far as away as possible from such kindred spirits.

OpenLaszlo fo Common Identity UI?

OpenLaszlo is pretty cool, you can build some powerful apps with it.

To explore its relevance for defining some sort of standardized UI for identity interactions, I mocked up just such an interface (flash).

In principle, both UI components and sequencing could be standardized.

FWIW, the code for the above mock-up is:

  
<canvas>
<view y ="30" >
<simplelayout axis="x" spacing="5"/>
 <view id="cart" bgcolor="#666699"
       height="250" width="125">
   <text fgcolor="#FFFFFF"
         x="5" y="5" >Available Identities</text>
 </view>
 <view id="wish" bgcolor="#666699"
       height="100" width="125">
   <text fgcolor="#FFFFFF"
         x="5" y="5" >Chosen Identity</text>
 </view>
</view>

<view x="${cart.x+10}" y="${cart.y+55}"
     resource="blast.jpg"
     onmousedown="dragging.apply()"
     onmouseup="dragging.remove();">

 <dragstate name="dragging"/>

 <method name="stop">
   if (this.x>wish.x) {
     this.animate("x", wish.x+10, 300);
     this.animate("y", wish.y+55, 300);
   } else {
     this.animate("x", cart.x+10, 300);
     this.animate("y", cart.y+55, 300);
   }
 </method>
</view>

<view x="${cart.x+10}" y="${cart.y+125}"
     resource="choo.jpg"
     onmousedown="dragging.apply()"
     onmouseup="dragging.remove();">

 <dragstate name="dragging"/>

 <method name="stop">
   if (this.x>wish.x) {
     this.animate("x", wish.x+10, 300);
     this.animate("y", wish.y+55, 300);
   } else {
     this.animate("x", cart.x+10, 300);
     this.animate("y", cart.y+55, 300);
   }
 </method>
</view>

<view x="${cart.x+10}" y="${cart.y+195}"
     resource="astro.jpg"
     onmousedown="dragging.apply()"
     onmouseup="dragging.remove();">

 <dragstate name="dragging"/>

 <method name="stop">
   if (this.x>wish.x) {
     this.animate("x", wish.x+10, 300);
     this.animate("y", wish.y+55, 300);
   } else {
     this.animate("x", cart.x+10, 300);
     this.animate("y", cart.y+55, 300);
   }
 </method>
</view>

<text x="5" y="5">
 Drag chosen identity to
</text>


 <button x="160" y="150">Select</button>
</canvas>

Do you really need an account?

As part of his "The Story of Digital Identity" podcast series, Aldo Castanada interviewed Ben Adida, a Phd candidate in crypto at MIT.

Ben made one comment in the interview that caught my attention.

.... everything you do is tied to some kind of identity, at least a pseudonym, because otherwise it's not that useful. I mean, if you go back to Amazon, and Amazon doesn't keep track of anything you do, then it's not a very useful web site ...

Ben seems to be suggesting that Amazon (and other such sites) must necessarily have some sort of persistent pseudonym for users in order to provide them any sort of useful and customized experience.

This ignores the very real potential for anonymous interactions with service providers, where a user's attributes can be asserted by some identity provider as needed, but no persistent account need be maintained at that service provider. Everytime they reappear at the service provider, they see the user fresh (excepting any cookies they might have set on the browser).

Bottom line, service providers will need to know something about you in order to provide differentiated service. Such information could include shipping address, calendar info, reputation etc. Today's reality is that service providers force users to create a credentialed account in order to allow them to track and cumulatively collect such information across multiple visits. But it needn't be this way if the information was supplied as necessary by some other identity provider.

User-centric lasik

For $99.95, I hope they provide drops as well.

I can't help but trust the site, I mean they have an MD.

A Long Tale of Two Cities

There is a cost associated with staying connected to friends or colleagues should circumstances change (e.g. change of address or job). Twenty years ago, if a friend moved to a different city, the options for maintaining that connection were letters and phone calls. Even with the emergence of communication technologies like email, IM, VoIP etc sharply cutting communication charges, the ongoing cost of tracking identifiers and addresses remained. When costs are high, limited time and energy will ensure that not all connections can be maintained - they get lost in the tail.

Applications that facilitate the maintenance of such connections by lowering the associated cost (e.g. in time, effort, duplication across various applications, etc) could be useful. A connection that might otherwise get lost in the long tail of the social distribution could keep its head above the water.

I have been thinking that something like Liberty's People Service could play a role here, imagining that somebody could build an application on top to help people stay in touch with those from which they would otherwise drift apart. Call it 'Virtual Mom' maybe. Seemed a bit far-fetched.

Then I came across this paper describing a 'Keep in Touch' Phone - a phone that reminds/persuades users to do just that, keep in touch with their contacts.

Public Displays of Connection

An interesting MIT paper on displays of social connections, i.e. the willingness and/or ability of people to advertise their social network for others to browse. For instance, in LinkedIn, a user can stipulate whether or not their list of connections is visible to others.


In developing our People Service, Liberty proceeded on the assumption that a user's social network (as manifested in the membership of their People Service) was an identity resource like any other (e.g. profile, geolocation, calendar etc) and so the user would be able to control under which circumstances, and to whom, it was shared with.

In describing existing social network sites like LinkedIn, Friendster, Orkut, etc, the authors write:

Most networking sites share a similar model of interpersonal links — they are mutual, public, unnuanced, and
decontextualised:

• links are mutual: if A shows B as a connection, then B has
  also agreed to show A as a connection,
  
• the links are public: they are permanently on display for
  others to see — here, the sites do differ, e.g. LinkedIn
  allows you to see only the connections made by your
  immediate links, and only if they allow it, whereas Orkut
  allows users to explore freely, and others limit network
  viewings to a still more broad class of friends of friends of
  friends,
  
• the links are unnuanced: there is no distinction made
  between a close relative and a near stranger one chatted
  with idly on-line one night,
  
• the links are decontextualised: there is no way of showing
  only a portion of one’s network to some people — some
  sites do allow users to adjust the closeness by degree of
  the people who are to be allowed to see their
  connections, and within that degree everyone can see all
  connections (there is no ability to segregate one’s links),
  and similarly for one’s profile, and a few sites allow
  limiting parts of the profile to closer connections, but
  again connection degree is the only distinction made.
  

We considered each of these aspects in developing the People Service.

mutual - while we allow for symmetric connections between users, we don't require them. Just because Bob is in Mary's list doesn't necessarily imply that Mary is in Bob's. However, it's worth noting that, for some use cases, the lack of a mutual connection can have a significant impact on the effectiveness. For instance, if Bob adds Mary to his connections in the context of enabling her to view his geolocation - without Bob also being added to Mary's list , Mary's applications will be unable to take advantage of this privilege and query Bob's geolocation on behalf of Mary. They wouldn't know where to start (unless Mary tell's them 'Oh, Bob said I could see his geolocation and this is the address').

public - ultimately, depends on the policy of the user (and of the provider's ability to enforce said policy). Most use cases we considered have the list of connections being queried by some provider on behalf of the same user (e.g. some provider querying Bob's list of connections on behalf of Bob, rather than some other user) and so the access control decision boils down to 'Which providers can ask on my behalf'. Another class of use cases would require that access be defined in terms of the identity on whose behalf the request was being invoked. For such use cases, a user might define access control for their list of connections as 'Allow anybody on my list to see the list, forbid any others'.

unnuanced & decontextualized - a user can categorize their connections through groups and/or metadata tags. Based on such categories, the connections can be differentiated (e.g. allow anybody to see my 'Work Colleagues' but keep hidden the 'Family' group).

What we haven't thought about to this point is the ability of a particular member of somebody's People Service list to specify their policy over display (e.g. allow Mary to specify that, while she consents to being added to Bob's list of connections, she does not wish this fact to be advertised'. This would introduce the question of who 'owns' this information.

London forecast - hot, fair & dry

di·ver·gence Pronunciation (d-vûrjns, d-)
n.

1.

a. The act of diverging.
b. The state of being divergent.
c. The degree by which things diverge.

2. Physiology A turning of both eyes outward from a common point or of one eye when the other is fixed.
3. Departure from a norm; deviation.
4. Difference, as of opinion. See Synonyms at deviation, difference.
5. Biology The evolutionary tendency or process by which animals or plants that are descended from a common ancestor evolve into different forms when living under different conditions.
6. Mathematics The property or manner of diverging; failure to approach a limit.
7. A meteorological condition characterized by the uniform expansion in volume of a mass of air over a region, usually accompanied by fair dry weather.

A Social Paradox

If my social network and that of somebody else have significant overlap (e.g. shared membership), then the odds are good that the two of us know each other and even that we know each other well. And if we share the same friends and colleagues, then we are likely to run in the same social circles - and so are likely to be in each other's social network as well. In a sense, the connection between myself and such a contact is strong, reinforced as it is by the multiple links between ourselves - both the direct one and the others that go through our shared contacts.

But, there would seem to be a paradox here.

For some applications, to accrue benefit from a social network (e.g. get that job recommendation, date, stock tip, etc), there is value in maximizing its radius (or equivalently, minimizing the average distance between myself and others). But strong connections don't contribute much here. There is little value (in the sense of expanding my network) in these tight social links. If I dropped such a contact from my network (let's rhetorically say he broke one of my dining room chairs at a New Year's Eve Party) - my network health & viability would likely not be significantly impacted - the other links we would continue to share would provide a buffer to absorb any significant shrinkage in the radius of my network (and to ensure that we will share ongoing awkward silences at summer BBQs).

Or equivalently, if I add a new contact to my online network, and they bring with them no fresh blood - individuals not already in my network - then I gain nothing (in the sense of maximizing radius) from the addition. I might as well just keep them in my Thunderbird Contacts.

More important to maximizing the size of my network are weak connections, i.e. those to individuals typified by the fact that we have few if any shared members in our respective networks. Such connections are weak in the sense that it is only through the direct link that we stay bound, there are no suppporting secondary links reinforcing them. But it is these weak connections that ultimately allow a network to expand beyond its incestuous (not literally) core of strong connections. Adding (or removing) such a connection can have significant impact on network size.

For me, this is a clear argument that I need to get out and meet new people. My wife remains unconvinced.

Reputation & Social Distance

I think of reputation as 'aggregate opinion'. Someone's individual opinion of me, while potentially feeding into my reputation (if they tell others), is not reputation itself. That's why, for me, some IDP asserting to some attribute of mine is not attesting to my reputation, unless that IDP was a Reputation Provider (ala Opinity) specifically doing so.

But, opinion aggregated from which community? Or, in other words, what set of other users are asked the question 'What do you think of Paul?'.

In eBay's feedback system or Slashdot's Karma, the community is comprised of all other users with whom I've interacted (within the respective systems). For those other eBay users scoring me, and for those relying on such scores, I am my eBay pseudonym. Neither group knows me beyond that identifier, nor do they need to, because the whole scope of the system (interactions, subsequent scoring, and querying of reputation) is confined to the online world, specifically eBay's corner of it. The only point at which the online and physical world intersect is at the point of shipping whatever product was bought and sold.

Another potential community of users from which my reputation could be built are those that do indeed know the real physical me - my offline friends, family, and colleagues. Such a group will almost certainly have insights about me unavailable to soem eBay user who knows me based only on our online commercial transactions.

So, my social network, generally comprised, at least in the first degree, of individuals who know the real me, and not some online pseudonym by which I present myself, could be a basis for reputation. I think it would be interesting to explore when this sort of offline/online bridging reputation would be more applicable than pure offline.

As one example, when someone is considering hiring me, they won't be thinking to themself 'I wonder what his eBay Feedback score is'.

Would this qualify as a "Purring Test"?

An alternative to captchas.

Identity Gospel

In Adam Nicolson's "God's Secretaries - The Making of the King James Bible" Nicolson portrays the decision by King James I to sponsor a new translation of the Bible as part of his hope to heal the schism within the English Church between conservative Bishops and reforming Puritans. Nicolson suggests that, more than anything else, James Stuart wanted his new reign to be undisturbed by the sort of religious strife that characterized his Scottish upbringing (as evidence his motto 'Blessed are the Peacemakers").

The hope was that a new "authorized version" of the Bible would serve as a middle-ground between the Protestant Geneva Bible (1560) and the established Church of England Bishop's Bible (1568), and thereby settle the many biblical controversies that divided the two camps.

James drafted a set of instructions to the committee of Translators tasked with creating the new version. To one instruction in particular Nicolson assigns particular importance:

No marginal notes at all to be affixed, but only for the explanation of the Hebrew or Greek words, which cannot, without some circumlocution, so briefly and fitly be expressed in the text.

Marginal annotations had been extensively used in the Geneva Bible in order to allow its translators to offer their interpretation and clarification of particular points in the main text (i.e. they profiled the main text). Problem was, King James found most of these clarifications, Calvinistic and Puritan in nature as they were, offensive. Consequently, he instructed that the marginal notes mechanism should be used only sparingly in the new Bible.

Nicolson interprets this instruction to mean that James deliberately sought to ensure that the main text of the new Bible could be, where appropriate, intentionally vague (i.e. underspecified) and unclarified by any marginal notes. For James, such ambiguity in the text would mean that both sides of the dispute, established Church of England Bishops and the reforming Puritans, could find an acceptable interpretation within the new Bible.Where clear direct text had been the goal of the Geneva Bible, the King James Bible would be known for its rich, grand and (importantly) subtle phrasings. Where the Geneva Bible had left no room for any interpretation other than that of its translators and subsequent annotators, the new Bible would provide a rich "platform" on which the different Christian faith systems could build. Bishops and Puritans, while disagreeing on specific interpretations, could agree on the fundamentals as expressed through the text. A meta-bible if you will.

We already have our identity Seven Commandments and evangelists abound. Maybe it's time to consider the Gideon's marketing model in spreading the gospel. I know I spend too much time in hotel rooms.

s/obscenity/user centric/

United States Associate Supreme Court Justice Potter Stewart could have been referring to many things other than pornography when he wrote in an opinion:

I shall not today attempt further to define [obscenity]; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it ...

Hopefully we can do better than this for user-centric identity.

Y.M.C.A (without the overt sexuality)

Johannes calls for contributions to the YADIS song.

Note: for optimum enjoyment, this should be sung while wearing motorcycle leathers. Your call of course.

Ya-URL*, there's no need to feel down.
I said, ya-URL, cause your future is sound.
I said, ya-URL, your metadata can now be found
Your issues need not go un-resolv-ed.

Ya-URL, there's a place you can rest.
I said, ya-URL, for your capabilities we can test.
They can start there, and providers can find
Others of a sim-ilar-URI-kind.

It's fun to rest with y-a-d-i-s.
It's fun to rest with y-a-d-i-s.

(Repeat till nauseus)

* - the 'earl' pronunciation, not the spelled-out acronym. This will be key for 'getting it'.

User-centric targetting

John Kemp postulates that user-centric identity is here already - and it's not what we were hoping for.

Many of today's systems put the user right smack at the center - of a big juicy identity theft target.

FSN - &$%#& Social Networks

Marc Canter argues that Social Networks must open up and allow their end-user data (their networks) to be accessed and moved.

He offers FOAF and the microformat XFN as options. Liberty's People Service is another.

Marc also creates a new acronym to stand beside 'YASN'.

Pidgin or Creole - Linguistic Interoperability

A pidgin is a reduced language created when two or more groups with distinct languages are forced into contact - the pidgin emerges in order to provide some level of cross-group communication. Each group retains its own language for "internal" communications but uses the pidgin for "external" communication. One example is a pidgin known as Russonorsk that emerged between Norwegian and Russian fishermen who encountered each other in the Arctic waters they trawled.

Pidgins often arise as a second language for colonists and workers who speak differeing native languages and yet need to talk to each other. For various reasons, the groups are unwilling or unable to learn the language of the other and so fall back on a pidgin as an alternative. For instance, when the English set up a trading post in Canton in the 17th century, both groups had such a high opinion of their own culture and language, and a low opinion of those of the other, that neither community would contemplate learning and using the other language.

Compared to normal languages, pidgins are severely limited in the complexity of communication they can provide. The sounds of a pidgin are generally just those common to the languages that go into it. A pidgin's words generally just consist of nouns, verbs, and adjectives, with little or none of the other components of a full grammar, e.g. adverbs and prepositions.

Pidgins can evolve into more full-featured languages. A creole is the result when a generation of pidgin-speakers begin to adapt that pidgin as their native language rather than a secondary option. Compared to pidgins, creoles have larger vocabularies and much more complex grammars. Consequently, creoles are far more able to support the expression of complex concepts and phrases expected of a real language - those which pidgins can't handle. Creoles often emerge amongst the children of pidgin speakers - it's as if the children naturally recognize the limitations of their parent's pidgin and fill the gaps in order to enable more meaningful communication amongst themselves.

Both Yadis and Web Single Sign On Metadata Exchange Protocol allow a provider to query the identity suites supported by some other, Yadis for URI-based systems like OpenId and LID, WSSOMEX between WS-Federation and Liberty ID-FF 1.2 enabled sites. In the absence of a single URI-based protocol, or in the absence of a single XML-based protocol, both Yadis and WSSOMEX enable a sort of interoperability by answering the question 'What does the other guy speak?'.

Both feel like pidgins in their limited scope and expressiveness, rather than a full-featured creole shared between the two worlds. It's like the previously mentioned fishermen using a pidgin (part of neither language) in order to determine which full language (either Russian or Norwegian) should be used in any particular boat-to-boat interaction.

Lars: Hey Dere Bro
Yuri: Hey Dere Youself Bro
Lars: Me Ken Norse and Russki
Yuri: Dat Good, We Be Using Russki
Lars: Zdravstvuite!

Also like a pidgin, the motivation for such metadata-exchange is primarily driven by the unwillingness of both sides to deprecate their chosen language in favour of the other.

Hawaiian pidgin offers one very useful construct. 'Da Kine' is a universal term used whenever the speaker can't rememember an actual term or phrase they wish to use. Imagine the usefulness of some universally recognized identity URI for 'interpret from surrounding context'.

War Jogging

Picked up a Palm T/X the other day with integrated WiFi.

On a run around the neighborhood, I was able to scan and connect through a couple of unsecured access points.

I didn't, but could have, used any of:

- Snapper for email
- u*Blog for blogging
- Chatopus for IM
- Quick News for feeds

Cheesy Comestibles!

Credit to Problems with HTTP AUthentication


Customer walks in the Federated Identity shop and walks past the blogger.

Customer: Good Morning.

Venda: Good morning, Sir. Welcome to the Identity Emporium!

Customer: Ah, thank you, my good man.

Venda: What can I do for you, Sir?

Customer: Well, I was, uh, pondering my IM infrastructure, and I suddenly came over all 'centralized'.

Venda: Centralized, sir?

Customer: Siloed.

Venda: Eh?'

Customer: 'Ee, Ah wor loggin-in me own y'users!

Venda: Ah, passwords!

Customer: In a nutshell. And I thought to myself, "a little federated identity will do the trick," so, I curtailed my activites, sallied forth, and infiltrated your place of purveyance to negotiate the vending of some identity!

Venda: Come again?

Customer: I want to buy some federated identity.

Venda: Oh, I thought you were complaining about the blogging!

Customer: Oh, heaven forbid: I am one who delights in all manifestations of user-centric expression !

Venda: Sorry?

Customer: 'Ooo, Ah lahk a nice post, 'yer forced too!

Venda: So he can go on blogging, can he?

Customer: Most certainly! Now then, some federated id please, my good man.

Venda: (lustily) Certainly, sir. What would you like?

Customer: Well, eh, how about a little Passport.

Venda: Afraid we don't get much call for it any more.

Customer: Oh, never mind, how are you on DigitalMe?

Venda: I'm, a-fraid we're fresh out of DigitalMe, sir.

Customer: Tish tish. No matter. Well, stout yeoman, a parcel of Infocard, if you please.

Venda: Ah! It's beeeen on order, sir, for two years. Was expecting it this morning.

Customer: Not my lucky day, is it? Aah, SXIP?

Venda: Of course.

Customer: Ahh excellent. Some SXIP please.

Venda: Oh sorry, sir. I thought you were telling me to skip that one.

Customer: Very well, ID-WSF?

Venda: Normally, sir, yes. Today the van broke down.

Customer: Ah. Digital IDs?

Venda: Sorry, problem with the ingredients.

Customer: LID? OpenID?

Venda: Only in very small quantities.

Customer: WS-Trust, perhaps?

Venda: Ah! We have WS-Trust, yessir.

Customer: (surprised) You do! Excellent.

Venda: Yessir. It's..ah,.....it's a bit unspecifed...

Customer: Oh, I like it unspecifed.

Venda: Well,.. It's very unspecifed, actually, sir.

Customer: No matter. Fetch hither the WS-Trust! Mmmwah!

Venda: I...think it's a bit more unspecifed than you'll like it, sir.

Customer: I don't care how fucking unspecifed it is. Hand it over with all speed.

Venda: Oooooooooohhh........!

Customer: What now?

Venda: It's been submitted to a standards body.

Customer: (pause) Has it.

Venda: Yes, sir.

(pause)

Customer: And this means?

Venda: Two years delay.

Customer: You...do *have* some identity, don't you?

Venda: (brightly) Of course, sir. It's an identity shop, sir. We've got--

Customer: No no... don't tell me. I'm keen to guess.

Venda: Fair enough.

Customer: Uuuuuh, Passel.

Venda: Just identity here sir.

Customer: Anything vaguely user-centric?

Venda: Uh, not as such.

Customer: XDI?

Venda: no

Customer: XRI?

Venda: Same thing sir.

Customer: YADIS?

Venda: Not *today*, sir, no.

(pause)

Customer: Aah, how about SAML?

Venda: Well, we don't get much call for it around here, sir.

Customer: Not much ca--It's the single most popular identity system in the world!

Venda: Not 'round here, sir.

Customer: {pause}and what IS the most popular identity system 'round hyah?

Venda: 'DIX, sir.

Customer: IS it.

Venda: Oh, yes, it's staggeringly popular in this manor, squire.

Customer: Is it.

Venda: It's our number one best seller, sir!

Customer: I see. Uuh...'DIX, eh?

Venda: Right, sir.

Customer: All right. Okay. 'Have you got any?' he asked, expecting the answer 'no'.

Venda: I'll have a look, sir... nnnnnnnnnnnnnnnno. Must have been some trouble at the factory.

Customer: It's not much of a federated identity shop, is it?

Venda: Finest in the district!

Customer: (annoyed) Explain the logic underlying that conclusion, please.

Venda: Well, it's very interoperable, sir!

Customer: It's certainly uncomplicated by protocols....

Venda: (brightly) You haven't asked me about the metasystem, sir.

Customer: Would it be worth it?

Venda: Could be....

Customer: Have you --SHUT THAT BLOODY BLOGGING OFF!

Venda: Told you sir....

Customer: (slowly) Have you got anything for the metasystem?

Venda: No.

Customer: Figures. Predictable, really I suppose. It was an act of purest optimism to have posed the question in the first place. Tell me

Venda: Yessir?

Customer: Have you in fact got any federated identity here at all that will simplify my user management burden and enable easier partner integration.

Venda: Yes,sir.

Customer: Really?

(pause) Venda: No. Not really, sir.

Customer: You haven't.

Venda: Nosir. Not a scrap. I'm just trying to maintain market position.

Customer: Well I guess it's back to passwords for me then.

Venda: Probably best sir.

The Blind Men & the Elephant

With apologies to John Godfrey Saxe and his poem.

It was five followers of IM
To privacy much inclined,
Who pondered on User-centric
(Though all of them were blind),
That each by exploration
Might satisfy his mind.

The First approached User-centric,
And happening to face
from the viewpoint of the desktop,
Proclaimed with great haste:
"Law #1 - User-centric
can only be met by common interface!"

The Second, thinking of local storage,
Cried out with strident tone:
"From the privacy advantages
to me 'tis clearly shown -
the demands of User-centric
argue for a phone!"

The Third, at User-centric,
myopically squinting,
And thinking of correlated behaviour
and resultant IDP-hinting,
Declared, "To do this we must
do digital-ID minting!"

The Fourth, with gaze
less than broad and full,
Considered user-mediation and
after pondering did mull:
"User-centric must
place push before pull!"

The Fifth, thinking of the geeks,
and to excite them what to try,
After restful examination,
and market analysis did cry:
"It can only be,
that user-centric demands a URI!"

And so these followers of identity
Disputed loud and long,
Each in their own opinion
Exceeding stiff and strong,
Though each was partly in the right,
Yet all were in the wrong!