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.