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!

Bloody right

I was giving blood the other day and told the nurse my blood type. She said 'That's fine but we'll check anyways'.

I guess sometimes self-assertions just aren't enough.

<AttributeStatement>
     <Attribute Name="urn:blood:type">
         <AttributeValue>B-</AttributeValue>
     </Attribute>
</AttributeStatement>

Footy & spam?

Slashdot reports that 'Australian Rules to Crack Down on Spam'.

Personally, I question whether professional sports (antipodeal or not) have much to contribute to the spam discussion.

A metasystem - in porcelain

Now this is true "convergence"!



Begs the question - which specs correspond to the sink, and which to the low-level "platform"?

The Last Shall be First

Sat in 44K from Newark to Narita - absolutely the last seat on the plane. I chose it because of the extra leg room but expected to pay a price of being last to go through Japanese Immigration - with resultant delay.

Through the vagaries of terminal train shuttle loading and unloading (and some wily frequent flyer finagling - sorry Gramma), I ended up being the first through immigration. As a result, I waited only 5 m for the Narita Express.

It's sad that saving 30 minutes at the end somehow makes the previous 18 hours of travel more acceptable.

Outsourced PDP/PEP

When I leave Ottawa Airport for travel to the US, I can clear US Customs before I get on the plane. If I clear customs in Ottawa, then I can march right off the plane once I arrive in the States (suggesting that the plane can use a gate typically reserved for US dmestic flights). The desks in Ottawa are staffed by US Customs officers with the same suspicious glare, doing the same job they would do at at Dulles or O'Hare, they just happen to work abroad.

In the terminology of the SAML model, the PDP (Policy Decision Point) and PEP (Policy Enforcement Point) of the US government have been outsourced to Canada (hopefully with the permission of the Canadian government). It's at the desks where the decision is made to allow entry or not, and the hostered guns are there to enforce this decision.

I wonder what are the legalities of this set-up - am I considered to still be in Canadian territory when I stand before them with sweaty palms - wondering if they are going to be suspicious of a Canadian born in Russia working for a Japanese company travelling to the States en route to France?

Or is a little slice of America, i.e. by presenting myself to the officer am I considered to be in US territory, and governed by that country's regulations? If so, at what point do I cross back into Canada (because the gates beyond are presumably Canadian).

Identity gestures?

I use the Firefox extension All-in-One Gestures for common browser operations like new tab, close tab, history backwards, history forwards, etc. Rather than searching through menus, or right clicking on some browser widget, you need only mouse click somewhere in the window and then draw a designated gesture with your mouse.

For instance, the current tab can be closed by right clicking within and then dragging the mouse down. You even get a nice mouse trail to help you draw the right shape. There are as many distinct operations as permutations of up, down, left, right operations (view frame source is 'left-down-right-down-left', like I'm going to remember that one).

Why not 'identity gestures' - oft repeated identity operations that can be initiated through user-configurable mouse gestures? Some candidate operations (some presuming an 'active' client) and potential default gestures:

• toggle preferred/active identity provider (perhaps 't')
  
• log in with local SP account (perhaps 's')
  
• log out of all active sessions (perhaps an 'X')
  
• verify site credentials (perhaps 'T')
  
• display current site's usage policy for requested attributes (perhaps a '?')
  
• add individual (as indicated through their name on a page) to those who can share some resource, e.g. photo, blog comment (perhaps a '+')
  
• log in with Passport account (perhaps 'When in the Course of human events, it becomes necessary for one people to dissolve the political bands')
  

If we don't make identity easy, they won't use it.

Discovery Burden

Interesting post on the lack of consistency amongst blogs on how RSS feeds are made available for subscription.

Syndication feeds have become a predictable blog feature. But finding them on a site can be a bit unpredictable

When you need to make it easy for users to find something on a page, you either stanardize where you put it and what you name it so that the users can manually 'discover' it, or you define mechanisms by which it can be auto-discovered.

The post concentrates on recommendations for the first model, i.e. where in the page to put the link to the feed, what colour the button should be, how to deal with variants, etc.

Such best practices would undeniably be useful, I've spent minutes scanning through a page or using the browser 'Search in Page' to try to find a feed link. Nevertheless, UI standards are not the only way - the burden of feed URL discovery can be removed from the user and be semi-automated on their behalf.

It's in the comments to the above post that the possibility of this automated alternative is mentioned. Don't force users to find the feed links, instead enable the browser to find them by embedding suitable code in the page. Once found, the browser can present them to the user if and when asked.

For instance, in Firefox's "Live Bookmarks" feature, when the browser comes across the following in the page HTML

<link rel="alternate" type="application/rss+xml" title="John Bokma RSS" href="/index.rss">

This link is interpreted as a feed URL. The availbility of the feed is presented to the user as an icon in the address bar

Ultimately, a blog's best bet is probably to use both models for feed URL discovery, allowing users to search on their own through consistent placement of a link as well as taking advantage of automated mechanisms.

Likewise for identity discovery perhaps? Allow for both models?

Different identity systems assume differing levels of involvement from their users for the discovery of their identity attributes. Some systems presume that the user will play an active role, manually providing the address of their identity provider when asked, others place greater emphasis on automated mechanisms to match a requesting party to an appropriate identity provider, and others allowing for both options.

There will always be some users who know where every bit of their identity is distributed at any one moment, others for whom the prompt "Please indicate your Wallet Provider" would have them running to their kids for help.

Why do just about all Liberty demos emphasize alcohol?

I know why it's a significant focus of our meetings, but our demos ....?

Hubert le Van Gong has a post on a Sun demo of a Java applet implementation of an identity selector.

A user is visiting an online Wine Shop (as opposed to the gazillion other types of SPs that Hubert could have chosen) and the SP needs to know that the user is of an age allowed to buy booze.

The SP advertises this identity requirements to the applet, which then does a number of things:

1) uses Liberty WSF protocols to discover appropriate identity providers
2) allow the user to select the desired provider
3) interact with the chosen provider from #2 to retrieve the required identity data
4) hand the identity info from #3 to the SP.

The demo nicely demonstrates the support within the Liberty architecture for client-hosted functionality, here it's an identity selector and a client to network hosted identity services.

It also nicely continues the pattern established by the NTT demo of the 'Online Beer Shoppe'. Are we seeing a nascent market for federated identity rear its head?

I do wonder why Hubert didn't have the applet querying the user's nationality so that French customers wouldn't even be shown the plonk pages.

What will your URI say about you?

The ZD Net Web 2.0 Explorer has a post on URL Hotties. Apparently, URLs can be beautiful, or not.

If people had URIs, would they be judged by the attractiveness of their identifiers?

I can see it now, "Well he was really cute and we had a great time together but I just couldn't get past his URI" or 'SWMU looking for SWFU, 20-30, athletic. Must be https for a trusting relationship'.

I guess beauty is in the eye of the resolver.

Identity Rights Agreements Quibbles

Phil Windley posts a position paper that he, Kaliya Hamlin, and Aldo Castaneda created for the W3C Workshop on Transparency and Usability of Web Authentication.

One paragraph caught my eye:

Relying parties requesting identity information would receive back a standard response indicating the IRA associated with that identity data. Proceeding with the transaction would be interpreted as agreeing to abide by the IRA requirement.

1. The implication is that some sort of 2-phase negotiation would always occur - the RP asking for some bit of identity, the IDP indicating under what IRAs it would be releaased, and the RP then resubmitting its original request. If the RP were to submit its original request with a particular IRA referenced, the semantics would be 'This is how I intend to use, store, protect the identity should you release it to me' and no such negotiation would be necessary.


2. Also implied is that the RP's commitment to agreeeing to abide by the IRA returned by the IDP would be implicit, determined from its choosing to resend the original request. This wouldn't be sufficient, subsequent audits would almost certainly require an explicit 'OK, I am re-submitting my request under IRA X'

Granted that this level of pedantry over unstated details is completely unfair when reading a position paper.

The position paper also argues for a Service Provider Reputation Network, a mechanism to ensure SPs abide by the IRAs through social pressure. What isn't clear to me from the paper is who scores the SPs, i.e. who tarnishes their reputation when they mishandle identity information - the users whose identity data was misused or the IDPs who released it.

For gladiators, size did matter

Peter Davis and I, along with other Liberty colleagues Conor Cahill and Steve Anderson, spent the day wandering around ancient Pompeii.

One particularly interesting bit was the colliseum. At dinner afterwards, Peter and I were discussing how large we thought the Pompeii version was relative to its more famous Roman cousin.

Peter guessed that the actual 'playing field' was around 100m across. I said, 'No, that's too big, more like 70m'.

Google Earth helped determine the winner (modesty prevents me from explicitly calling it out)

Roman hospital(ity)

Old Roman guy from the 16th century convinced us to buy questionably dated lamb for dinner the other night. Bought it and was happy. Hellmuth slipped him some euros for his trouble. He slipped us some bad basement champagne for ours. Much frivolity, far more than the morning after.

Identity Ro(a)ming

Used Google Earth to take a pic of the hotel in Rome where next week's Liberty Alliance meeting will be held. Triangulated in from the Vatican and St. Peters.



Pool looks cold, they must not have yet retrieved my temperature preferences from my profile.

Tear down

Wired has an article on how car manufactures routinely tear down the cars of their competition for the insights on manufacturing, costs, etc they can obtain from the carcas.

Reminds me of the process advocates of particular identity systems engage in when looking at the 'competition'.

What is promising is that, more and more, the analyses that we perform, and the conversations we have, include attempts at understanding how the different systems might be compatible.

I don't think GM and Toyota spend much time on worrying about the "auto metasystem" and how their cars might interoperate.

Boxed In

3D Boxes is a soon to be beta online calendar that those who've had a chance to play with seem to love.

Key to what people appear to like is how the app stresses the social aspect of calendars, namely that the chances are good that if an event is sufficiently noteworthy for a user to warrant being recorded then it's probably also noteworthy for their friends.

But the description of how you connect to others is nothing new:

Central to 30 Boxes is the concept of buddies. Basically in order to add someone as a buddy on 30 Boxes all you need to do is enter in their email address (talk about genius viral marketing). They then are sent an email inviting them to 30 Boxes and if you choose you can allow them to see your calendar, see only events tagged a certain way in your calendar (cool, tagging in a calendar app), or see none of your calendar.

This model distinguishes 3D Boxes from, oh lets see, no other social applications. You provide your friend's email, they get invited to create an account, their new account is given whatever rights you assigned them etc. Viral indeed.

As to the calendar functionality itself, seems very similar to Planzo and others.

Collective Authorization?

Eve muses on what user-centric identity means, and its implications for access control.

If, bottom-line, user-centric means giving users control over their identity (e.g. when it gets shared, how it gets used) then there had better be some authorization rules defined by the user being enforced if and when some piece of their identity is requested.

And, if the user's identity info is maintained on their behalf by some provider, that provider may have its own policies for access control (e.g. do not share with entities with which no legal agreement exists) unanticipated by the user themself. Both user and provider would have to 'approve' before identity is released. So, as Eve labels it, 'mutual authorization'.

Started me thinking about just how many entities might have an opinion on whether or not some piece of identity be shared:

• the user (I don't want my geolocation shared for marketing purposes)
  
• any custodian of the identity if different than the user (don't share with competitors)
  
• the requestor (it might not even want the data if it is to be released with too onerous a set of requirements (e.g. security, reporting etc))
  
• some regulatory body (must not share unless auditable consent has been obtained)
  
• some other user (if I provide a reference for a colleague, both she and I would likely have our view of appropriate usages)
  

Collective authorization?

Tag Boy

The identity space already has Identity Woman and XMLgrrl.

I want to be Tag Boy.

Tag Boy!

1. Able to hand edit XML documents (but not using any of the obscure stuff like parameter entities).
   
2. Able to quickly call on real expertise through various communication channels when designing schemas.
   
3. Able to drop 'namespace' into conversations at approximately appropriate times
   

Just think of the animated series.

Social Bovines

Marc Canter's post reminded me of microformats. The microformats model for identity information is to embed the data within existing HTML pages rather than define new XML-based protocols for its sharing.

Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards. Instead of throwing away what works today, microformats intend to solve simpler problems first by adapting to current behaviors and usage patterns (e.g. XHTML, blogging).

Microformats leverage existing XHTML tags such as address, cite, and blockquote and attributes such as rel, rev, and title to create semantically meaningful information. Essentially, profiles of XHTML for encoding particular slices of identity (e.g. personal info, calendar data, etc) as HTML metadata.

There is a microformat proposal for expressing social identity, it's called XHTML Friends Network (XFN). In XFN, the social connections between users manifest themselves as hyper-links, just like connections between pages. Such an XFN link is distinguished from a normal link through its use of the rel attribute on the HTML <a> element. For instance, a user named Bob could represent the nature of their relationships to Josh, Kat, and Mary with the following elements embedded somewhere in their personal page (e.g. a blog).

<a href="http://josh.example.com/" rel="friend met">Josh</a>
<a href="http://kat.example.com/" rel="met acquaintance">Kat</a>
<a href="http://mary.example.com/" rel="co-worker friend met">Mary</a>

Each of the three could have a similar set of links in their pages, perhaps including a link back to Bob to represent a bi-lateral relationship. Depending on your point of view, the ability to indicate a relationship to somebody else without their permission or action is either a good thing or a bad thing. One could, for instance, indicate a totally unrequited romantic relationship.

XFN defines a short list of allowed values for the rel attribute, things like met, colleague, sibling, etc. For some applications this level of granularity for describing relationships might be sufficient - but not for many others (because ultimately the social data has to enable something or else it's simply an ego trip). To be fair I expect this was a deliberate trade-off in favour of simplicity over flexibility.

The alternative is to not attempt to prescribe what are valid relationship types but rather ensure that users can specify their own. The Liberty Alliance's People Service defines two such mechanisms in support of this model, groups and tags. Groups allow a user to define collections of the base members of their people service, the tag element can be used to add additional metadata to both members and groups. For instance, I might define a 'Identity Bloggers' group to carry those individuals who I wished to be able to leave comments on this blog. For other users who didn't quite fit this grouping, but for whom I still wished to enable commenting, I could define a 'respected' tag and apply it to each such member.

There are of course bigger issues dividing the microformats and XML protocols camps. Microformat advocates preach 'pave the cowpaths'. Sure, if the cows have been going to interesting places.

Identity Enabled Devices

ABC News anchor Bob Woodruff and his cameraman Doug Vogt were injured in Iraq by an IED (Improvised Explosive Device).

Two thoughts:

1. As opposed to naturally occuring explosive devices? Presumably the distinction is between explosive devices created by recognized arms manufacturers and those cobbled together with duct tape and spit. Given the obviously lethal nature of any such ad hoc devices, is the distinction relevant? Do convoy drivers say to themselves as they drive through hot spots 'Phew, only need to worry about brand name bombs today'?
   
2. The military must be the only community more inclined to create unnecessary acronyms than IT.
   

Social silos

Identity woman complains about the duplication & fragmentation that people current face in maintaining 'buddy lists'.

Each phone handset has one for address books -

• Motorola,
• Nokia

Telecom Incumbents

• Orange(france telecom),
• British Telecom

Cool “apps”

• YackPack
• Jazz

The Incumbent internet players

• ebay/Paypal/skype [PESk]
• Yahoo!
• Google (using Jabber)
• Microsoft

Amen to that.

Liberty People Service.

What does user-centric identity mean?

Granted that it makes for lovely slideware with a smiling face in the centre of appropriate clip art for banks, hospitals etc but I honestly don't know what it is.

Despite its popularity, I haven't come across a clear definition of what are the criteria to be met for an identity-system to be considered 'user-centric'. And yet, this doesn't stop people from characterizing those identity systems they don't favour as unable to meet these undefined criteria.

Perhaps user-centricity can be defined in the negative, i.e. determining the common characteristics of systems that don't have it.

So, which of the below are NOT user-centric?

• URI-based system under sole control of user (i.e. personal server)
  
• Liberty-based system with identity data hosted on the client and over which users have sole control
  
• Infocard mediating interactions between PC-hosted identity provider (over which users have sole control) & network service provider
  
  
• URI-based system with identity data hosted on user's behalf at network providers at which users are given mechanisms in order to specify policy over identity release
  
• Liberty-based system with identity data hosted on user's behalf at network providers at which users are given mechanisms in order to specify policy over identity release
  
• Infocard mediating interactions between service provider and network identity provider storing identity data on behalf of user and at which users are given mechanisms in order to specify policy over identity release
  
• Shibboleth-based system with identity data hosted on user's behalf at network providers at which users are given mechanisms in order to specify policy over identity release
  
• sxip-based system with identity data hosted at network providers at which users are given mechanisms in order to specify policy over identity release
  
  
• URI-based enterprise system with identity data hosted on user's behalf at network providers at which users are not given mechanisms in order to specify policy over identity release
  
• Liberty-based enterprise system with identity data hosted on user's behalf at network providers at which users are not given mechanisms in order to specify policy over identity release
  
• Enterprise Infocard mediating interactions between service provider and network identity provider storing identity data on behalf of user and at which users are not given mechanisms in order to specify policy over identity release
  
• Shibboleth-based system with identity data hosted on user's behalf at network providers at which users are not given mechanisms in order to specify policy over identity release
  
• sxip-based enterprise system with identity data hosted at network providers at which users are not given mechanisms in order to specify policy over identity release
  

Other than the enterprise deployments above, where it can be argued that the user's control over their identity are scoped by their employment contract, I believe all of the above can be user-centric.

What I take out of this exercise is that the ultimate determinant of an identity-systems user-centricity is the degree of control the user has over the data that comprises their identity. And, as far as I can tell, all of the above systems can support such control, but none can guarantee it.

For instance, although Liberty's protocols have explicit support for carrying user consent decisions for the release of identity, and implementations of these protocols provide mechanisms for the user-administered definition of such policy, nothing forces a deployment to avail itself of either. Liberty's protocols could definitely be deployed in a non user-centric manner. As could any other identity system.

More sxore

Sxip responded to my "Writeable Web & sxore" post of a few days ago in which I tried to understand the sxip-based sxore system for controlling blog spam.

Fundamentally, what I wrote yesterday was that sxore, like many other identity systems, relies on a trusted 3rd party to make assertions about users to relying parties. In the sxore system, the trusted 3rd party is sxore.com and the relying parties are the blogs at which a user wishes to post a comment. By either signing in to their sxore account, or completing a captcha there, would be commenters rise above the suspicion threshold sufficiently such that sxore.com recommends to the relying parties that their comments are authentic and not spam.

Sxip acknowledges that I had it mostly right based on what info is available but don't have all the details:

Paul Madsen thinks that Dion Hinchcliffe is off the mark about how sxore works. However sxore does more than Paul describes.

They go on to say

In sxore, as members write comments and are moderated, they build up an aggregate reputation that sxore can then use to auto-moderate comments. That aggregate reputation will also be portable, members of sxore will be able to take it to other sites using SXIP 2.0. Those other sites can verify that a user has a good reputation on another site, in this case at sxore.com.

So, as bloggers use sxore to moderate my comments, sxore.com builds up an overall reputation for me across the different blogs at which I've commented. Eventually, and presumably based on a preference specified by individual bloggers, my comments could be automatically approved based on that reputation. Also, the above gives the impression that the reputation, established in the context of blog posting, could be transferable to other contexts, e.g. online commerce or rating systems.

While I think such functionality is valid and useful (and makes me think that perhaps Liberty should be thinking about a 'Reputation Service' built on top of our Identity Web Services Framework) , I don't think it changes the model. Portable reputation won't mean a thing unless it's coming from an entity that a consumer of such reputation has reason to believe gives its stamp of approval only to deserving individuals (twisted grammar above to ensure that I didn't use the word 'trust')

If I show up at a blog and self-assert 'I have a reputation for making witty and relevant comments' I can guess where any such comments will be filed. If however, sxore.com were to assert the same thing, then I would be much more likely to have my spelling corrections and similarly insightful comments approved.

Writeable Web & sxore

Dion Hinchliffe writes about the potential of Sxip's sxore as a means of bringing responsibility to the writeable web.

He wonders

If I understand it fully, Identity 2.0-compliant credentials can be shown to anyone and validated on the spot, without consulting a validating authority

With the same caveat about fully understanding sxore, I think Dion is off the mark here on how sxore works.

From what I can tell from the sxore FAQ and playing around with the sites that are enabled, with sxore, when somebody wants to leave a comment on some post or article, they have 2 choices, they can complete a captcha to prove they are human and not a bot, or they can log-in to their sxore account. Either way, they prove their humanity or authenticate at sxore.com. Sxore.com then uses the sxip protocols in order to assert to the original site that the user is, at minimum, human.

So, with respect to Dion's conjecture above, the individual wishing to leave a comment does very definitely provide their credentials to a validation authority, specifically sxore.com (and perhaps other similar sxore-enabled authorities in the future).

This is not to question the value of sxore, it appears a slick (and user-friendly) solution for the problem of blog spam. But it does not do away with the role of an authoritative identity provider validating credentials and vouching for identity to relying party sites. And so, at this most basic level, sxore (and Sxip's larger Identity 2.0) appears to be consistent with many of the other identity systems.

Microsoft Codename Max

Codename Max is a cool P2P photo sharing (beta) application from Microsoft. The Channel 9 blog has an interesting video interview with the development team.

Haven't installed it but from the video's description of how it works, the mechanism for inviting friends to share your photos is the standard one - you specify their email addresses (seemingly linked to a .NET Passport?) and they receive an email with a link to click - after which a P2P connection is established between both machines for the transfer of the relevant files.

I saw no mention of support for tracking social relationships, e.g. friends, once invited to access one batch of photos, would be remembered for the next time. Or, even better, for Max to be able to use some common social layer not specific to photo sharing and isolated on the user's PC.

Theoretically possible would be that, when the user indicated they wanted to share photos (or videos, music etc), the Max desktop app would call out using the protocols defined by the Liberty People Service to view the list of friends, family etc with whom sharing was desired. Friends, once invited, could be optionally remembered for subsequent availibility to other social applications.

I take some solace in the fact that physicists who believe in the parallel-universe interpretation of quantum mechanics will argue that this is indeed happening in some other less-divided identity universe.

Agreement on Identity Rights Agreements

Drummond Reed refers to a Phil Windley post on the value of "identity rights agreements" - pre-defined policies governing the use and sharing of identity info.

When asking for identity info, the requestor would include an identifier (likely some URI) for whatever policy it would abide by if the requested data was released to it. Likewise, the custodian would include the appropriate URI for the policy governing any released data. Drummond & Phil point to Creative Commons as an example of the principle; P3P is another.

Phil throws out some possibilities for those policies that would warrant an identifier.

* Post publicly (broadcast)
* Share with anyone, but can’t broadcast
* Share with self and partners with which you have a legal agreement to honor this agreement
* Keep to self
* Stored encrypted
* Use for this purpose and destroy

The identifiers would serve as a simple and easily parsed syntax for the complete policies (captured and accessible somewhere).

Liberty ID-WSF has a container in our protocols for carrying such identifiers (an empty container because, as yet, we have not ourselves defined any policy syntax or identifiers - despite some early work along this route). The <UsageDirective> SOAP header is defined in the SOAP Binding specification.

Participants in the ID-WSF framework may need to indicate the privacy policy associated with a message. To facilitate this, senders, acting as either a client or a server, may add one or more <UsageDirective> header blocks to the SOAP Header of the message being sent. A appearing in a SOAP-based ID-* request message expresses intended usage. A <UsageDirective> appearing in a response expresses how the receiver of the response is to use the response data. A <UsageDirective> in a response message containing no ID-WSF response message data, a fault response for example, may be used to express policies acceptable to the responder.

Drummond points to Identity Commons as the place where relevant policies (and agreed upon identifiers) might be defined.

Identity rights agreements are becoming one of the galvanizing forces for a revitalized Identity Commons. One of the reasons is the oft-used analogy that “Identity Commons should be to identity rights what Creative Commons is to copyright".

This work would be really interesting & valuable. Identity agreements and their identifiers could be common across particular identity systems (e.g. Liberty, Shib, OpenID, LID, SXIP, WS-*, etc) and so serve as a key piece of any metasystem that underlies or unites such systems.

Testing, testing

In the Liberty Web Services Framework, the Data Services Template provides a design-pattern for identity services to (optionally) avail themselves of. At its most basic, DST defines a CRUD pattern so that specifications for individual identity services (e.g. for calendar data, for geolocation, for presence etc ) don't have to reinvent the wheel.

A key piece of upcoming functionality in DST is the ability to test identity attributes without necessarily actually sharing them. In many situations, a request for a user's identity is motivated by the requestor wishing to ask a question about the data rather than needing to know it's actual value. Examples include 'Is this person under 18?' (or more generally 'Is this person a minor'?), 'Is this person a Gold-Level Frequent Flyer' etc.

While the requestor could ask for the data itself and then determine the answer, this means sharing the attribute when such sharing isn't necessary. Minimal disclosure (surely some sort of Identity Law) dictates that a requestor should ask for, and a provider subsequently release, only the minimally acceptable amount of identity.

If, in order to deliver some service, all a provider needs to know is whether I'm over 18 years old, telling it that I'm (a spry) 42 breaks the principle. If, in order to bombard me with unwanted mobile coupons for a muffin, all a coffee shop chain needs to know is when I'm within 500 m of one of its stores, my mobile provider telling it my actual location (even if obfuscated through accuracy limitations) unnecessarily shares my identity info.

I expect there is an 'Identity Corollary' in here.

Liberty People Service for Group-based Access Control

Allowing users to define access control for their online resources in terms of their online friends & colleagues was one of the key use-cases that drove the development of the Liberty Alliance's People Service. We recognized that often times a user will wish to define access rights against a group of such friends rather than each individually, e.g. 'Allow all members of the "Soccer Team" group to see my online calendar and allow all members of 'Coaching Staff' to add entries'.

In this scenario, Alice has defined access rules to some of her resources at aservice provider (SPa) based on membership in a 'Work Friends' group she maintains at her people service (PSa). Anybody who is in the group can see the page etc, anybody else can't.

Bob is a friend of Alice and she has previously both added him to her People Service as well as to the group in question. Now, when Bob appears at SPa and tries to access the resource in question, in order to enforce Alice's policy, SPa must determine if Bob is a member of the 'Work Friends' group.

The messages below (a mixture of SAML & Liberty WSF) give an idea of how this might work.

1. Bob shows up at SPa and tries to access the resource in question.

2. SPa asks 'Who are you?'.

3. Bob wants to use his identity provider account and so says 'Ask IDPb'.

4. SPa redirects Bob to IDPb with a SAML AuthnRequest message.

    <samlp:AuthnRequest
      ID="NTT7630E00861279F0ADC63E241D0926D0B"
      Version="2.0" IssueInstant="...">
      <saml:Issuer 
          format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://spa.com
      </saml:issuer>
      <samlp:NameIdpolicy 
         format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
    </samlp:Nameidpolicy>
   <samlp:AuthnRequest>
 

5. IDPb authenticates Bob.

6. IDPb sends a SAML Response to SPa with a SAML AuthnStatement carrying a name identifier for Bob (this possibly a one-time anonymous identifier for Bob)

   <samlp:Response id="NTT3F633E3F712BAC4B0804714431D46D7B"
        inresponseto="NTT7630E00861279F0ADC63E241D0926D0B" version="2.0" 
        issueinstant="...">
      <saml:Issuer 
        format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://idpb.com
      </saml:Sssuer>
      <samlp:Status>
        <samlp:Statuscode value="urn:oasis:names:tc:SAML:2.0:status:Success">
      </samlp:Statuscode>
      <saml:Assertion version="2.0" issueinstant="..." id="NTT02068C15DFB">
        <saml:Issuer
           format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
          https://idpb.com
        </saml:Issuer>
        <saml:Subject>
          <saml:NameID namequalifier="https://idpb.com"    
            format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
            e0b735bf9d1f3959241d3584733d704c
          </saml:NameID>
        </saml:Subject>
        <saml:AuthnStatement authninstant="..." sessionindex="...">
          <saml:AuthnContext>AuthnContext goes here</saml:AuthnContext>
        </saml:AuthnStatement>
      </saml:Assertion>
    </samlp:Response>

7. Knowing that it needs to 'talk' to PSa about Bob, SPa sends IDPb an <sa:TokenMap> message, providing the previous name identifier for Bob and specifying PSa as the target namespace.

    <sa:TokenMap>
      <saml:NameID namequalifier="https://idpb.com" 
          format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
        e0b735bf9d1f3959241d3584733d704c
      </saml:NameID>
      <TokenPolicy spnamequalifier="https://psa.com">
      </TokenPolicy>
    </TokenMap>
 

8. IDPb returns an appropriately targetted(and likely encrypted) identifier for Bob that PSa will recognize.

    <sa:TokenResponse>
      <sec:Token>
        <saml:Assertion>
         identity token for Bob in PS's namespace
        </saml:Assertion>
      </sec:Token>
    </sa:TokenResponse>

9. As Alice has previously defined her access control rules in terms of a group maintained at PSa, SPa knows how to invoke PSa. SPa sends a query to PSa questioning Bob's membership in the group in question (the object for which is identified by the TargetID element), using the token just obtained from Bob's IDP to identity him.

    <ps:TestMembershipRequest>
      <ps:TargetID>https://ps.com/nmerflas</ps:TargetID>
      <sec:Token>
        <saml:Assertion>
         identity token for Bob in PS's namespace
        </saml:Assertion>
      </sec:Token>
    </ps:TestMembershipTequest>

10. PSa extracts the identity token, decrypts the encrypted identifier in the identity token, looks up the group in question, and finds that Bob is indeed a member (Alice having previously placed him there).

11. Consequently, PSa returns 'true' to SPa's original query.

    <ps:TestMembershipResponse>
      <Status code="OK">
       <ps:TestResult>true</ps:TestResult>
      </Status>
    </ps:TestMembershipResponse>

12. Confident that Bob is a member of the group against which Alice defined privileges, SPa grants Bob access to the resource in question.

Of course, all Bob would see of the above would be appropriate access to Alice's resources, everything happening behind the scenes.

Alternatively, when Alice first defined her access rule in terms of the 'Work Friend's group, the SPa could have then gone out and obtained individual identity tokens for all members of the group (from their respective IDPs). If and when somebody showed up trying to access a resource, SPa would check the identifier they presented against those in teh approved list and grant access accordingly. The issue with this model is dealing with changing group membership.

Dwight Shrute

Lots of wisdom here.

When there is a chill in the air, there are colder
weather patterns coming down from Canada.

In Canada it is always winter. Sometimes the sun
never rises in Canada. Harp seals abound until they
are brutally slaughtered by Canadians. They worship
maple syrup, hockey and Alanis Morisette. I hate
Canadians.

Seating inertia

I feel like Andy Rooney even asking this but .....

Have you ever wondered why, when people attend a multi-day meeting, whatever seat they happened to choose the first day they will typically sit in for the duration?

Is this some sort of sad vestige of a territorial imperative? An artifact of Grade 3 classrooms?

Vancouver Voted Best Canoing in Canada

SXIP's corporate blog brags that Vancouver was again voted the Best City in Canada.

Vancouver is a great city and may even deserve the award.

Truth in advertising would however suggest that SXIP at least acknowledge the occasional downside .

Make it into a bonus, e.g. 'come work for us and improve your swimming'.

Group Sex?

Over at weaverluke, Luke Razzell considers the possibility of a genetic explanation to why human's generally like to hang around those that think like ourselves

a man and woman who share a point of view are presumably more likely to reproduce together than a man and woman who do not.

Luke's theory offers no explanation as to why both men and women seek out similar-minded people of the same sex. If reproductive success isn't necesary to explain why males seek out other males (or females seek out other females) that share their point of view, why should we to attribute to it the same phenomena when it occurs between males and females?

Luke goes on to wonder

Could there be a genetic component in the formation of communities of thought?

I expect that any link between reproductive success and the tendency of humans to form into groups is less direct. If you aren't in a group you are on your own. In our evolutionary past, being alone would almost certainly have had an impact on your ability to pass genes on - starving when food is scarce, being swallowed by a lion or speared by another tribe would surely have cramped your moves on Friday night down at the pub.

Kemp

Nokia's John Kemp, at least within the Liberty Alliance, is one of those 'last name only' people. If he comes up in a conversation (and he does often, typically along the lines of 'I don't know how that works, who can we ask?'), people typically refer to him as 'Kemp' - as in 'Kemp would know'.

I don't know why - we haven't had a huge number of 'Johns' that would motivate such a disambiguating identifier.

Maybe it's the British accent that encourages some degree of social distance. But, he was a key contributor to the People Service, the key value of which is to decrease social distance.

A mystery.

Regardless, Kemp is blogging. And Kemp would know.

I feel like Microsoft (or a politician)

Sxip, Marc Canter and Johannes Ernst have blogged on Liberty's People Service.

All posts are an interesting mix of guarded approval and suspicion.

From the Sxip corporate blog

It will be interesting to see whether this is an open or closed "circle
of trust" approach to IdM for individuals, to what extent it will be
user vs silo-centric, and how complicated it is.

From Marc

I won’t go into the irony of announcing this right after CES and during MacWorld. I wonder if these Liberty people even have a clue what that ruckus is all about.

way - I’ll give them the benefit of the doubt. It’s just too coolio to be negative about.

From Johannes

I've got to admit that this is not something I would have expected from Liberty ... it runs counter to its traditional reputation ... but I very much like the direction this is going.

While it is definitely gratifying to see respected players see value in the People Service (and hopefully think about how they might work with it), I honestly don't understand why it's seen as such a paradigm shift and/or breakout for Liberty.

Internal to the Alliance, the People Service is very definitely seen as evolution rather than revolution. Whereas with the first version of our Web Services Framework we could deal with transactions involving single identities, with the People Service (as part of the soon to be finalized ID-WSF 2.0) we can now deal with transactions involving two identities. Definitely 'cool io' and interesting but in no way inconsistent with the architecture and philosophy that we've always followed. Just new functionality layered on top of what we already had. Put another way, just another slice of identity that can be shared. And, as before, supporting a range of deployment options, e.g. a People Service on the network, a People Service on a PC, or on a phone.

Guarded approval tempered by suspicion. My mother-in-law would recognize the dynamic.

Red Queen

The Red Queen principle is the concept in evolutionary science that animals engage in cyclic arms-races with their predators, prey, and parasites. The arms races are cyclical because, typically, the long term balance of power stays the same despite periodic reversals of that balance. Both sides must evolve merely to keep this balance.

The allusion is to Lewis Carol's 'Through the Looking Glass' in which a character of that name states to Alice:

"in this place it takes all the running you can do, to keep in the same place."

Cheetahs are almost certainly faster than their ancestors, and gazelles similarly improved relative to earlier versions. Despite this, today's cheetahs probably don't dine on fresh gazelle significantly more than previous generations. Both sides are 'fitter', but that hasn't changed the general dynamic. If either side were to gain too significant an advantage (e.g. cheetahs either catching everything in sight or starving), evolutionary pressure would act to bring things back.

We are seeing a number of seemingly Red Queen style arms races on today's Net - that between spammers and email clients, that between phishers (and other identity thieves) and unsuspecting email clickers, that between WAM products from competing vendors, etc.

For identity theft in particular, as defenses improve against existing attacks, the phishers/pharmers develop more elegant variations. Either side may enjoy a temporary advantage, but only until the other side catches up. If this race truly is a Red Queen phenomena, neither side will ever win out right and the general severity of the identity theft problem will remain relatively constant over time. Lets hope not.

p.s. One currently respected theory (as championed by Matt Ridley in his "Red Queen" book) for explaining the evolution (and relative ubiquity) of sex is that the genetic mixing that sexual reproduction enables (relative to asexual reproduction) gives hosts an advantage over the parasites and germs that attack them (the popularity of internet porn notwithstanding, sex does need an explanation because its costs relative to asexual reproduction are clear). By giving the genes a good churning with every generation, the theory posits that sex allows hosts to present a moving target to the pathogens that would prey on it. It's not clear to me what conclusions might be drawn from such a theory for the usefulness of sex for the battle between WAM products. Maybe being a product manager would be a better job than I've always believed.

Who do I sue?

Wired reports that some residents of New York State are up in arms over plans to install wind turbines in and around their homes.

The comments of one (particularly visionary) resident suggest the potential for an as yet untouched identity application. Patricia Oakes, a Hartsville, New York, resident asked:

"...Who do I sue if I have any health problems or my property value decreases because of this project?"

Beyond my admiration for Ms. Oakes' foresight (too often people wait till after suffering harm before they start contemplating damages) and the specifics of the windmill issue, surely an identity metasystem could help Patricia (and others with a litigious bent) obtain an answer to this question?

Currently it is a mostly hit-and-miss process by which Patricia finds potential candidates for her lawsuits. This ad-hoc nature allmost certainly means that she is unable to be fully compensated for the harm (known or otherwise) from which she is suffering.

Why not allow people to store and publish the list of current ailments, grievances, damages, etc that they are currently suffering from (or might in the future) - this identity info discoverable by 'suebots'. Lawyers would similarly publish the class-action lawsuits they were prosecuting (or even contemplating prosecuting should demand warrant) and the relevant individuals could be found and matched. People needn't even know they were part of a particular lawsuit, simply wronged in a high-level and non-specific manner.

For too long, American's have borne the burden themselves of finding litigants for their potential lawsuits. They need our help.

Identity Bowl?

Just watched Tulsa beat Fresno State in the Liberty Bowl.

Disappointing play by play - seems only fair that if we sponsor the game they mention our identity services framework more often. Maybe something along the lines of 'Man, he lost his privacy on that hit - could have used ID-WSF' or 'I don't think he would have given his consent to being thrown around like that'.

I tried to think of a more 'convergent' name - 'Meta Bowl' sounds too medical, 'URI Bowl' sounds like the Russian Mob bought the game, a 'WS-* Star Bowl' would require an indoor stadium (closed to external influences).

Maybe next year it'll simply be the 'Identity Bowl'. We could get a bunch of no-name players, opaque face masks, use encrypted URIs for uniform numbers. Advertisers would line up.

RSA Security blamed for failure of many federated identity projects

In an article discussing the challenges involved in federated identity projects is the following classic from copy-editor Hell:

Too often, federation projects suffer from poor motivation/co-ordination with business partners. This may be because the complexity of the options available has been underestimated and is usually RSA Security ......

As an ex-Entrust employee, I can't help but take a measure of enjoyment from this typo.

Geographic persona URIs?

Wired has an article on the possibility of Berlin being awarded a top level domain.

The line that jumped out at me is

Berlin's businesses and citizens will flock to the domain because millions of people regard the hip European city as a part of their identities

I suspect that Wired is referring to the potential of Berlin's citizenry liking the idea of a ".berlin" based email address rather than a URI identity (ala OpenID, LID etc) in the new domain.

Nevertheless, it does suggest the possibility of personalization for such URIs beyond a user being merely able to pick their identifier in some domain.

Newswire: Liberty Alliance Changes Name

The Liberty Alliance management board has voted unanimously in favour of changing its name to the "Liberty URI Alliance".

In a prepared announcement, Liberty Alliance Prime Minister I.P. Roperty stated 'URIs have garnered significant popular enthusiasm in the industry lately. Quite simply, they are hot and we wanted to make clear that the Alliance is completely in favour of them. They are just super. Fantastic things! I fully expect to like them even more when somebody explains them to me.'

Roperty explained further 'The new name simply reflects the emphasis and priority we have always given URIs. In fact we use them all the time. For instance, Liberty's homepage has a URL and that's kind of like a URI right? I myself am considering having my name legally changed to "SAMLart". Or maybe "http://" - I haven't decided yet. Maybe they could be different personas - those are hot too'.

Is it theft when identity is given away?

BugMeNot is a database of (freely provided) account names and passwords for many sites that require registration. Instead of creating an account, you ask BugMeNot for an existing account and password that will (hopefully) work there. BugMeNot looks through its previously created accounts and returns a pairing for you to use. There is even an Firefox extension to streamline the database query and form fill.

Anonymity through shared credentials.

The FAQ warns that only 'fake' (e.g. some disposable account I might create to read some online whitepaper) accounts should be registered. Nevertheless, people do appear to be registering 'real' (i.e. those for which they receive customized service) accounts.

As an example, using the BugMeNot extension, I was able (after many failed attempts) to access the (non-paid) Last.fm account of somebody named "Zudo***" and view their profile page. I know this was a real account (and not some aggregate reflection of all previous BugMeNot users who had been given this account name and password) because I was able to view which songs they had been listening to over the last week, so they must have installed the Last.fm plug-in into their music player.

Message to Zudo*** - Devo?

From the mind of a child

I was trying to explain what I do to my 6 year old son.

I presented a scenario of him playing a game at one site and then his high score being made available at some other site he travelled to.

After a pause he said 'So you help them connect?'.

'Exactly' I replied.

'But then what happens when you are sick. Do they just not connect on that day?'

Federated log-in & email validation

While playing around with an OpenID identity I received from Videntity, I saw an interesting artifact of the federated log-in mechanism.

At LiveJournal, I opted to sign in with my Videntity Open ID instead of using my local account. Everything worked great, I was redirected to Videntity, there I logged in, and was then redirected back to LiveJournal as my OpenID identity.

However, when I clicked on 'Manage My Account' at LiveJournal, I saw the following


Because my account at LiveJournal was virtual, there was no email that would have been validated through the normal registration process. When I clicked on the 'Not Validated' string, I saw this

LiveJournal didn't have an email for me so it tried to create one.

This is of course in no way specific to OpenID but just reflects how LiveJournal's account management mechanisms assumed an old-style account in which I would have supplied an email at registration.

If I had instead supplied my email to Videntity, then (assuming I authorized its release) it could have been passed to LiveJournal and there would have been a validated email for me (albeit validated by Videntity) for LiveJournal to display.

ISSO & Authentication Context

Looking at the i-names SSO (ISSO) spec being defined at XDI.org, they account for some minimum password strengths by which users MUST authenticate to their i-Broker (within the XDI.org community)

To help prevent dictionary attacks, XDI.ORG MUST specify a minimum password strength required of all ISSO accounts in the XDI.ORG network.

As they use SAML 2.0 as the protocol by which the Website requests an authentication and by which the i-Broker responds, it seems strange that they don't refer to SAML 2.0's Authentication Context as the mechanism for defining such minimum authentication requirements.

Planet Identity GreaseMonkey Script

I don't like to read my own blog entries at Planet Identity so I created the following GreaseMonkey script to remove my posts.

// ==UserScript==
// @name Ignore Planet Identity Users
// @namespace http://www.planetidentity.org
// @description deletes my blogs
// @include http://www.planetidentity.org/*
// ==/UserScript==

ignorelist = new Array("Paul Madsen", "Other author");

var allDivs, thisDiv;

allDivs = document.evaluate(
'//div[@class=\"entry\"]',
document,
null,
XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,
null);

for (var i = 0; i <>
thisDiv = allDivs.snapshotItem(i);
for(j = 0; j <>
if(thisDiv.childNodes[1].childNodes[0].innerHTML == ignorelist[j]) {
thisDiv.parentNode.removeChild(thisDiv);
}
}
}

Others could use it "out of the box" or adapt as preferred by modifying the ignore list array above.

Screwy GUI

To access my frequent flier account online I have a 9-digit account number and a password.

For some reason, the Aeroplan Web designers have decided to get creative with the GUI for logging in. Rather than providing a single HTML <input> element, they've divided it up into three separate input elements.

The problem is, Firefox's password manager can only recognize one of the three input fields for form fill.

Consequently, only the last 3 get filled in automatically.

I guess the lesson is that if a request for identity isn't properly posed then the IDP can't respond.

False sense of Security

I have the following strings of characters to remember in order to access my mortgage account through the Web or phone.

- card number
- Web password
- PIN
- telephone security string
- verbal passphrase

All these for a single account. Of course I write them down. I've complained to the bank that I shouldn't have to and thereby potentially compromise my account. No change. Seems that the perception of secerity is more important than the reality.

I wish I could forget the amount of debt as easily.

Imported Authn

In Collapse, Jared Diamond describes the impact of Australia's remoteness from the rest of the world:

with modern globalization, it is cheaper to grow oranges in Brazil and ship the resulting orange juice concentrate 8,000 miles to Australia than to buy orange juice produced from Australian citrus trees. The same is true of Canadian pork and bacon compared to their Australian equivalents.

The economics of the above only make sense for products low in bulk, high in intrinsic value, and, importantly, which can withstand the ordeals of the trip. You ship the concentrated juice and not the fruit; the bacon and not the hogs.

I guess the only thing less bulky than a SAML assertion is an X.509 cert but historically these haven't travelled well - they start to rot in their containers round about the Equator.

Implicit federation

The fact that federated identity connects together the current archipelago of user's identity islands is sometimes presented as enabling (or at least exacerbating) identity theft. The connections are seen as amplifying the consequences of any breach, e.g. a domino effect where one after another of your accounts is compromised.

But, if federated means connected, the different accounts of many users are already implicitly federated through the passwords that they reuse to access those accounts, this percentage of users reported as high as 40% (I confess I do it for "disposeable" accounts). If one account is successfully phished and the password is stolen for that account, it's a fair bet that that user's accounts at other providers will be accessible with the same password.

In addition to making strong and different passwords more useable for the end users, federated identity makes the connections between islands explicit and thereby manageable and controlled.

But, if two currently implicity federated (through shared password) accounts are explicity federated (through SAML 2.0, ID-FF, etc) and the passwords stay the same, then the risk of the implicit federation will remain. I'm sure users would love to be prompted with a request/demand to make sure that the passwords used at the two providers were different.

90210

After months of running in anon mode, I decided to create an account for Pandora, a streaming music service that tailors the stream based on preferred song attributes.

Problem is, you need a US zip code to create an account.


I supplied the only US zip code I knew off hand- it was accepted with no hesitation. I have to believe that there their geographic distribution of listeners would be inappropriately skewed towards Southern California.

Social Tags

One interesting (but admittedly only rudimentarily defined) aspect of Liberty's new People Service is the ability for users to tag the friends, colleagues, and family members (and any groups into which they are placed) that are members of their PS list.

Each friend or group Object can have multiple optional Tag elements, each with a ref attribute carrying a tag value (recommended to be in some established taxonomy like Flickr or Del.icio.us).

Tags are seen as an extra (to the friendly name) axis along which user's can categorize their friends and groups. As an example, if a user created two groups called 'Soccer Team' and 'Hockey Team', both groups could be tagged with 'sports' to make clear their shared relationship (as opposed to placing both in some extra hierarchal level through a 'Sports Teams' group).

Once both groups are tagged, access rights (e.g. allow any of my team-mates, irrespective of sport, to see this video) or group operations (e.g. send a party invite to all my team-mates) can be defined against the tag rather than the individual groups or individuals that have that tag.

We have much to learn here.

Geolocation with no privacy implications

Petscell is a GPS-enabled cell for pets, allowing owners to track the location of Fido.

Remote programmable geo-fence capability. Yes, I'm sure the dog will stop and come home when it gets a call.

Fortunately my children have gerbils - the phone's weight would crush them and I always know where the things are.

Killer Identity App

Judging by the conversations I heard after the Captain turned off the seat belt sign on a trip last week to Austin, there is a killer app just waiting to be built. It needs a slick marketing name but the jist of it is 'Hey, yeah we just landed, see you in 20 minutes, bye'.

Seems that many passengers have family, friends, colleagues who wait anxiously by their phones for just such brief but meaningful status updates.

Liberty's Identity Web Service Framework (ID-WSF) has all the necessary components to support such a system:

- People Service - defines a service by which one user can track those others with which they engage in online interactions
- Geolocation Service - defines a protocol by which the geographic coordinates of a user can be queried
- Subscription & notification - mechanism by which identity info requestors can subscribe to be notified if and when certain criteria are met

So, Frequent Flier uses a People Service to track their relationship with Friend, and then defines access rules at their cell phone provider such that Friend (referenced through the People Service) can see their geolocation. When Frequent Flier surreptiously turns their cell on immediately after touch down, the previously defined notification criteria (i.e. that Frequent Flier's location be within some distance of a major airport) triggers a message to that effect being sent to Friend.

You could even track miles flown for status. Maybe then I wouldn't need to save boarding pass stubs on the chance of my miles not being credited.

Panopticon - an overlooked aspect

Stefan Brands often uses the metaphor of the pantopticon to criticise federated identity models (like one possible manifestation of the Liberty Alliance architecture) in which a user's interactions with service providers are (partially) mediated by identity providers.

Stefan and Sun's Pat Patterson had an interesting discussion on the issue a while back. I won't revisit that - it's undeniable that in the LAP model that the IDP may 'learn', the discussion is to the what (it learns) and the when (it isn't appropriate).

There is another aspect of the panopticon model that gets lost in the 'IDP surveillance' theme. Panopticon refers to a proposed model for prison architecture and process in which inmates were distributed in isolated cells about a centralized watch station. In addition to the intermittent surveillance that was enabled, the architecture ensured that inmates had no contact with each other or prison officials. The theory was that such contact would interfere with the inmates reformation.

solitude is in its nature subservient to the purpose of reformation

Liberty today announced the release of another rev of its identity web services framework. This release includes support for what Liberty is calling a People Service. Bottom line, People Service is designed to allow users to manage their online relationships (e.g. friends, colleagues, and family, etc) such that the various applications that depend on a social layer (e.g. photo sharing, Find a Friend, YASN, etc) can build on a single consistent social network rather than each building their own duplicative version. A bit like a SOAP API into a FOAF repository.

The People Service is a key enabler of cross-principal web service interactions, e.g. those where the identity on whose behalf a request is sent is different than the identity that owns the identity resource in question (some site querying my wife's online calendar but indicating that the request is being sent on my behalf.) A key bit of this release of WSF is defining how the multiple identities in such a scenario are expressed in the SOAP Header.

The (admittedly limited) irony is that the ID-WSF People Service enables just the sort of interactions between individuals that the panoptical model for prison (and hospital) architecture was designed to prevent. No analogy is perfect it seems.

The PS spec is here and there is a whitepaper as well.

InteracOnline

A number of Canadian banks have created a federated payment system called InteracOnline. Consumers can pay direct from their banking account, comparable to debit cards versus credit cards at the cash.

They don't use the term but the claimed benefits for the consumer read right out of federated identity white papers:

• Privacy: you do not need to provide any financial details, card numbers or login information to the online merchant.


• Ease of use: because the payment is conducted through web banking, you don’t need to worry about creating any new passwords or accounts.


• Security: the payment is completed through the Financial Institution you know and trust.

and one I hadn't come across before

• Spending Control: The Interac Online service helps you better manage your finances – you can’t spend more than what you have in your bank account!

That last sounds like a challenge.

Despite the currently small number, there seems quite the mix of participating merchants. Professional curiosity as to implementation, UI design etc will almost certainly require me to conduct further research at one or two of these sites (most likely chosen at random).