Friday, February 24, 2006
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).
Wednesday, February 22, 2006
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.
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.
Tuesday, February 21, 2006
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.
Sunday, February 19, 2006
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.
Friday, February 17, 2006
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.
- 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.
- 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'
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.
Friday, February 10, 2006
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)
Tuesday, February 07, 2006
Friday, February 03, 2006
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.
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:
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.
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.
As to the calendar functionality itself, seems very similar to Planzo and others.
Thursday, February 02, 2006
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)
Wednesday, February 01, 2006
I want to be Tag Boy.
- Able to hand edit XML documents (but not using any of the obscure stuff like parameter entities).
- Able to quickly call on real expertise through various communication channels when designing schemas.
- Able to drop 'namespace' into conversations at approximately appropriate times