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).

Social Navigation

Supposedly, it's easier to just ask someone nearby where you are rather or how to get someplace than using mobile navigation applications - at least until the phone interfaces make this less cumbersome.

Whoever believes this has never asked a random passerby how to get to Ueno Park from Shinjuku in Tokyo. 'Sumimasen, Ueno doko desu ka?' only gets you so far.

Ummmmm Bacon

Andre Durand conjectures that the network is collapsing (in the sense that nodes, be they devices or people, are more easily connected than in the past). With the help of his mathematician father, he explores the rate of collapse, e.g. from year to year how much closer are the nodes. Interesting stuff.

As a starting point, they use what they call 'Kevin Bacon's 6 Degrees Theory'. Problem is, I don't think there is such a theory - this expression conflates two different ideas of small-world research.

The first is the well-known '6 degrees of separation' theory - the idea that anyone on the Earth can be connected to any other through a chain of at most 5 acquaitances. The second aspect is a game called 'Six Degrees of Kevin Bacon' in which Hollywood actors are labelled by their 'distance' from Kevin Bacon, this determined by how many links there are in the chain of co-actors between them and Bacon. So, different actors are said to have different 'Bacon numbers' (just as mathematicians can be labelled by their Erdos number)

But, as far as I know, there has never been a conjecture that the number 6 is in any way special for the Bacon number. A variety of actors will have this for a Bacon number, but many others will have Bacon numbers of 5 and 7.

It's meaningful to explore either the possibility that '6 degrees of separation' is becoming '5 degress of separation' (likely but by no means certain) or the possibility that a given actor's Bacon number decreases over time (it can't get larger) - but seems to me that Andre and his father are trying to combine the two.

Maybe we should define a Cameron Number, e.g. how distant people are from Microsoft's Kim Cameron - this distance defined with respect to blog roll membership (among other possible criteria like shared conference attendance). I don't personally know Kim but nonetheless have a Cameron Number of '2' (thank you Pat Patterson).

QR codes for two-factor authentication

On a recent trip to Tokyo, I was able to see some of the work of my colleagues at the Tokyo NTT Information Platform Sharing Laboratories exploring the potential of two-channel authentication systems. Such systems generally depend on various permutations of secrets shared across both a PC channel and a separate device channel. In essence, the phone serves as a second authentication factor.

Existing two-channel systems rely on either:

1) the client providing a phone number at registration time to which the service provider sends a OTP over SMS when the user logs in. When received by the user on their phone, they then enter it on the PC interface. By verifying the presented OTP, the server can be confident that the user is indeed the owner of the phone and therefore the account holder.

2) the server creating a one time phone number and presenting it to the user through the PC-channel. The user then calls this number from a phone with a previously registered number. The server, by verifying that the call came from a registered number, can be confident that the user is the account holder.

Both systems require that the user's phone number be provided to the server, which presents both privacy and scaleability (the server has to store these numbers) issues. The first relies on the security of SMS.

My colleagues are working on alternatives that:

a) don't rely on a phone number being registered/stored
b) leverage the certificates on many Japanese phones for client-auth SSL
c) authenticate the server as well

In both models above, it is the user that acts as the conduit by which the PC and phone channels are connected (this necessary for them to be correlated and authenticated). In the first, the user takes the OTP from the phone and types it into some HTML form; in the second, the user takes the presented phone number and manually dials it.

The research is exploring the potential for a technology mostly unique to the Japanese market to provide this connection/interface between the two channels. QR codes are two-dimensional bar codes into which can be embedded significantly more information. Critically, over 77% of Japanese phones have support for QR code readers. The phones' cameras can thereby serve as the conduit through which the two channels can be connected and correlated.

The prototype system has the server generate a dynamic QR code and present it to the user when authentication is required. The user uses their phone to take a picture of the code from their PC screen - the phone QR software then extracts the corresponding server address to which a mutual SSL session is established. To authenticate the server, the user sends a short text string from their PC as a nonce that the server signs and presents to the phone.

Below are pictures of 1) a user taking a picture of an on-screen QR code with their phone and 2) the phone display by which the server is authenticated.





The system is attractive because it leverages a (ubiquitous) second factor that users already have and expect to use, requires no specialized client software, does away with the privacy/scaling issue of stored phone numbers, and doesn't rely on the questionable security of SMS.

As Bruce Schneier points out, such systems can't guard against MITM attacks:

An attacker using a man-in-the-middle attack is happy to have the user deal with the SMS portion of the log-in, since he can't do it himself.

Nevertheless, to say that a technology doesn't prevent one attack doesn't mean they provide no value in defending against others.

Separation of Powers

Separation of powers is the concept within democratic government in which powers are distributed amongst different government organs to prevent any one of them from abusing that power. Along with checks-and-balances (the ability and responsibility of each to monitor the activities of the others), separation of powers is intended to reduce opportunities for tyranny.

Federated identity is sometimes criticized for exacerbating the risk of identity theft through its connection of currently separate identity collections into a greater virtual whole. The argument goes something like:

'So, if I login to the identity provider, I can then access my resources at some other service provider? That sounds nice but what happens if my identity at the identity provider is stolen/phished/pharmed/hacked, can't the thief, because of the connection, immediately jump to the service provider and steal my identity there?'

The argument is based on the assumption that some rogue individual, on hacking the identity provider, can get everything they need in order to impersonate me so that they can access my multiple federated service provider accounts.

Here is the rub though. It does the hacker no good to impersonate me, they have to impersonate the identity provider. As they do not know my various service provider credentials, they have to convince the service provider that they are the identity provider asserting to my authentication status. And, the burden of authenticating one site to another site (not to a user as in phishing) is considerably more challenging for a hacker.

If a hacker is to fool a service provider into accepting a counterfeit assertion for me (and thereby assume my identity at that service provider) it needs to present two things:

1) whatever federated identifier had previously been agreed upon between the service provider and the identity provider for myself. Present a random string and the service provider will refuse access because it won't recognize it as one of its federated users. Even if the hacker were to by chance get lucky and pick a valid identifier, its only valid when presented by the corresponding identity provider. see 2) below

2) a signature over the message carrying the above identifier associated with a key trusted by that service provider. Not any key issued by Verisign will do, the service provider will certainly keep a list of 'trusted IDPs' and if the associated key is not on the list then you are not invited to the party.

If the identity provider does things "right", then it will ensure that it is very difficult for any one entity (internal or external) to steal both of the above (it will almost certainly make it difficult to steal either as well). A "good" identity provider will implement "separation of powers" to ensure that, were one of the above was stolen, the other wouldn't be.

You can fool such an IDP once, but likely not twice.

"There's an old saying in Tennessee — I know it's in Texas, probably in Tennessee — that says, fool me once, shame on — shame on you. Fool me — you can't get fooled again." —President George W. Bush, Nashville, Tenn., Sept. 17, 2002

It's a Mad Mad World

In the Cold War, Washington advertised one policy for the use of its nuclear weapons while privately holding a very different strategy.

The visible & public policy was referred to as Assured Destruction (the 'mutual' was later added by a critic to create a more derisive acronym). AD was the idea that the only sane application of nuclear weapons was a non-application - if both sides were completely confident that they would be destoyed in any altercation they would be unwilling to strike first, and so nuclear weapons would never be used. The opposing counterforce strategy (which Qwynne Dwyer in his book War claims Washington actually held even whilst professing AD) saw such weapons providing value above and beyond their deterrent effect through their potential delivery in a controlled and constrained manner in a conventional war .

So, the "real" policy was much less restrictive in its criteria governing the 'release' of the ICBMs. While AD was based on the premise that one side's missiles would only be lanuched in retaliation to a first strike from the other side (stringent criteria) - the counterforce policy asserted that weapons could be deployed in a range of situations, e.g. in a tactical manner even as part of a convential non-nuclear altercation (relaxed criteria).

(This is the exact opposite of what I might have expected, e.g. a public bluff of aggressiveness but a more realistic and sane private plan. Of course, there were vested interests involved for which the status quo of maintaining weapon expenditure was desirable)

I wonder if the idea of different public/private policies is relevant for any policy governing release of identity information? Would a provider claim to be governed by one policy whilst actually listening to another?

If the visible policy were less stringent than the actual, the provider would receive attribute requests that would be immediately rejected - requests that would not have been sent if the advertised policy were accurate. Beyond the inefficiency, this is a privacy leak as the provider would unnecessarily learn at which requestor sites the principal had been visiting. If the advertised policy were more stringent, then the requestor might not even send requests that would be approved had they been - doesn't seem much risk (or sense) in this.

Bidirectional PII leakage

Motivated by a spate of fiascos and consequent legislation, enterprises are currently focussed on ensuring that any privacy sensitive data they may hold about individuals doesn't leak out.

Given the risks of damage to reputation and liability associated with storage of such data, how long is it before enterprises worry just as much about not allowing PII to leak in?

Ben Laurie suggests that one tenet of privacy-respecting identity management is minimalism, i.e. that only that identity information required for a particular application be shared and no more. He describes it as a principal for the protection of the individual - which it is of course.

But, it's also protection for the data requestor/recipient. Unless it has an immediate and (business)justifiable need for some piece if identity information, why ask for it, or even accept it if not requested but nonetheless offered? Or store it past any usage? Better let some identity provider, presumably with a business model and corresponding security technology and processes take the burden and risk.

Just remember to log that you didn't accept it.

SP Collusion

Dictionary.com defines 'collude' as

'To act together secretly to achieve a fraudulent, illegal, or deceitful purpose; conspire'.

In the context of identity management, the term is typically used to refer to multiple providers communicating together about some principal without that principal's consent.

If each provider stores some aspect of a given principal's digital identity - collusion between them is made possible if the nature of such identity information allows them to infer that it is the same individual with which they both have accounts.

Federated identity management, if done improperly, can enable collusion by simplifying the correlation burden for the rogue providers. This because, valid (e.g. based on informed consent) connections between the two providers and some other third provider can provide to the rogue providers the necessary correlation keys.

Federated single sign-on (SSO) can be used to explore the dangers. In SSO, a user authenticates to an IDP, and then the IDP creates claims to that effect for use at other SPs. Correlation and collusion is enabled if the claims are not created carefully. If the same user presents two different claims to two different SPs, the SPs might be able to correlate the claims as referring to the same principal through any of the following mechanisms:

A common identifier in both claims, e.g. if an email address or SSN is used to identity the subject for which the claim was generated. SAML 2 and Liberty address this by defining mechanisms by which identifiers unique to each IDP-SP pairing are established and used.

sufficiently identifying attributes, e.g. if both claims describe me as male, 41, working on identity management, living in Canada, tired father of 3, then the SPs would be able to infer that their different local acocunts referred to the same user, me.

small-community IDP, e.g. if both claims are issued by an IDP known to only issue claims for a small community of end users, then the SPs can narrow down their focus. If the IDP is associated with a single principal then its trivial.

temporally, e.g. if the two SPs somehow knew that the nature of some other application required real-time data from both of them, then perhaps they could use the timing of the requests to correlate. For instance, one SP is a calendar service, another a shipping service. If both SPs received a request for one of their user's data within some window of time from a home grocers site, then the two SPs could infer that their two users might be the same. If it happened again it would be confirmed.

keying material, e.g. if the keys used to ensure HOK subject binding were to be reused for the two SPs, then they could correlate based on that.

I'm sure there are others.

SSSO - Social Single Sign On

There is nothing social in default SSO. There is a single user and he/she, based on an authentication performed at some identity provider, is granted appropriate access for their own resources at some service provider. There would seem to be some unexplored social (i.e. more than a single user involved) aspects of SSO.

For instance, a user may be SSOing in to access resources belonging to another user. If I define the permissions at some online photo site such that certain friends can see my recent photos; if and when those friends log-in to that photo site they will be granted those privileges. If they log-in with an account local to the photo site then its very straightforward for me to define privileges against the corresponding identifier and for the site itself to enforce them. This is how sharing currently works at such sites.

However, if they don't have such an account nor desire to create one, they will want to access my photos based on an authentication performed elsewhere, e.g. SSO in to the photo site. The challenge now becomes how the photo site gets an identifier for the friend to which the privileges can be assigned and how users can track and manage the social relationships relevant to their online interactions. The Liberty Alliance People Service is designed to facilitate this.

Another social angle comes from the fact that, in many situations, the nature of the credential by which a user authenticates to an IDP is such that the IDP can't unambiguously identify them as individuals. For instance, when I access the Net from my home PC, my ISP knows only that I am one of the family members with access to that PC. Based on that shared credential I should be able to SSO to some SP and be granted permissions appropriate to mmy family, but not to any particular member. So, I might be able to see the family's calendar but not my personal one (at least not until I re-authenticated with a credential that did allow the IDP to unambiguously identify me and make an assertion to this effect to the SP).

False claims?

Will an identity system allow me to lie?

I (and I expect most others) often provide false data to sites asking me for personal data. I'm more likely to do so if the site is asking me for specific identity information as opposed to some range. For instance, if the site asks for my birth date (or even age) it's very unlikely that I'll give the actual date (unless it will eventually serve as some credential). If instead, the site provides me a set of ranges of ages from which I can select I am far more inclined to be truthful.

Now, if an SP were to ask an IDP of mine for my age rather than me directly, what happens if the SP and request are such that I don't want the IDP to provide the real value. Does the IDP provide a value from a persona I've set up just for such requests? What is the meaning of such an assertion if there is another persona with my real age, i.e. is the IDP asserting to the truth of its claim or merely to the fact that its asserting a value previously supplied by me?

Seems to me that the problem with the current status quo of sites asking for my age is that there is no 'fall-back' option, e.g. if I want to proceed with setting up the account or purchasing whatever, the HTML form requires me to provide a value for the field. There is no negotiation possible, no leeway in the site's identity demands and consequently I respond with the only option that satisfies both this demand and my desire for privacy - I lie.

In the brave new world of identity, perhaps there is no need to lie. If an SP asks my IDP for my age, the IDP might respond with 'Why do you need it?', to which the SP would say 'Demographic study', so that the IDP would finish with 'Well then his age range of '35-45' will be sufficient'. Because there needn't be a binary yes/no for release of identity data, but a negotiated middle-ground, its more likely that both the SPs and mine can be satisfied.