Iconic

Given it's similarity to the standard 'i', will not more than a few people be clicking on the Cardspace icon expecting to GET information, rather than provide it?

Schrodinger's SSO

If a user SSOs into an SP, and then some amount of time goes by, during which the user's original session at the IDP has a 50% chance of expiring, is it not the case that, from the SP's PoV, the user can be considered to be in a superposition of signed-in and signed-out states at the IDP?

And, only once the SP asked the IDP for a new authentication assertion (with saml:ForceAuthn='false' or equivalent), would the user's authentication wave collapse into one of the two states - this result manifested in the IDP response?

Stuck on Band-Aids, 'cause Band-Aids ...

From Popular Science, plans to build a medical research system that

will give donors an unprecedented degree of control over their cells

BioTrust's automated process will enable donors to control how their tissue is used and to reap greater benefits from donation. During the consent process, donors will select the studies that they do or do not want done on their tissues, and the computer system will store that data along with the details of their samples.

They'll surely need 'sticky' policies.

Provider Purity Ball

Recently, high-school gyms and up-scale hotel ballrooms across the nation are playing host to Provider Purity Balls.

Advocates say that the balls are an innocent ceremony in which IDPs sign commitments to act with integrity in all areas of business ethics and to protect their SPs in their choices for partner selection. SPs themselves vow to remain 'business abstinent' and to be led by their IDPs in choosing parters. Critics of the balls claim they are nothing but a throwback to an age when SPs were nothing but property of IDPs, the value of which could be damaged by early participation in activities like SSO.

'It's not like when we were young SPs growing up' said Merle Jacobs, an IDP who brought his 3 SPs to a recent ball held in Topeka, Kansas. 'I mean, when I was an SP, it was just more innocent. You could talk with an IDP and not feel forced to actually, you know, exchange 'data'. But SPs today see potential federation partners everywhere they look, on TV, in movies, even on the Internet. The pressure for SPs to be promiscuous in picking partners is everywhere. All we're doing is to try to help them make the right decision. And the right decision is to not engage in federation until protected by binding legal contracts.'

A young SP named Mary agreed. 'Its like, you know, just that I want to save those special emotions for the IDP that I eventually sign legal contracts with. I'm in no hurry, it's not like the Internet is going anywhere'.

'For my SP and I, the evening is more just a chance to get dressed up and spend some quality time together' said one IDP who wished to remain anonymous. 'I mean, she's only just out of business school, it's not like I have to be worried about her engaging in indiscriminate partner selection at this point in her lifecycle right?'

One of the most memorable highlights of the balls is the point during the evening when the IDPs stand in the middle of the ballroom and form a circle around their SPs - each standing all aglow in their lovely ball gowns.

HP in a hand basket

I was going to leave a comment on a post of HP's Marco Casassa Mont’s Research on Identity Management blog when I saw this


Somebody at HP with a sense of irony? Or are they falling apart with Greg's departure?

SignOn.com

Ping's SignOn.com is a notable OpenID provider because it supports the use of an Infocard for authentication (as well as having an eminently Googlable name). Is it the first public OP to do so?

The process of registering a card is straightforward (at least currently, it seems that you must have a username/password account to which you 'add' cards). I did notice an oddity though.

After registering a card, I edited that same card (adding my postal code). I was hoping that the new info would be communicated to SignOn.com (the next time I presented the card), and used to populate the profile (where it could then be sent to requesting OpenID RPs). This didn't happen.

A peak under the HTML covers shows that this is because SignOn.com isn't asking for the postal code, it's not on the list of 'required' claims

<object id="_xmlToken" type="application/x-informationCard">
<param name="requiredClaims"
 value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier
 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"/>
<param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:>
<param name="issuer" value="http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self"/>
</object>

So SignOn.com isn't willing to ask Cardspace for the postal code (presumably because it fears rejection), but it is willing to ask me (it's on the profile page).

Even though I had entered the postal code into the card, because SignOn.com didn't ask Carddspace for it, I am presented with an empty form field asking to be filled in. Does SignOn.com want it or not?

SignOn.com is of course only asking me for the postal code because they anticipate that they themselves might be asked for it through OpenID. As a result, if I want to ensure that these eventual RPs get my postal code, I will have to enter it a second time beyond the value in the card.

The disconnect here is between the identity demands of the 'application' (the bit of SignOn.com that wants to provide postal code data to RPs) and the multiple 'query mechanisms' by which that data is obtained (both the HTML profile page and the Cardspace 'required claims' parameter). As it stands, the two query mechanisms are asking for different amounts of identity so its impossible to know what the application actually 'wants'. Ideally, the application would be able to indicate what identity it needed, and the query mechanisms would be driven accordingly (e.g. ensuring both sets of HTML were consistent) This is the CARML proposition.

Client Attribute Requirement Markup Language (CARML) is an XML-based language used by application developers to specify what identity information an application needs and how the application will use it.

The issue of course isn't unique to SignOn.com, or to Cardspace, this specific scenario just illustrates the challenges faced when identity flows through multiple providers (especially when intermediate ones collect identity on their own).

Ensuring that the user's privacy policies also flow with the data is a whole different ball game.

Tags: SignOn.com, Cardspace, OpenID

Clash of the Titans

Generally, whenever heavyweights like Kim and Conor go at it, I cower in a corner and wait for the storm to blow over before coming out and picking from the debris like some Welsh coastal farmer.

Well the 'storm' turned out to be more of a squall. And so to the looting.

Kim writes

So, returning to the axes for linkability that we set up in Evolving Technology for Better Privacy, we see that from an identity point of view, the identity provider “sees all” - without the requirement for any collusion. Knowing each other’s identity, the relying party and the identity provider can, in the absence of appropriate policy and suitable auditing, exchange any information they want, either through the redirection channel, or through a “back channel” that dispenses with the user and her browser altogether.

Some thoughts

1. 'sees all' is presumably in quotes because, as Irving had earlier pointed out (and as Kim acknowledged), the IDP doesn't see 'all'.
2. an IDP 'merely' seeing the RPs to which a user is visiting is not case of collusion. Collusion requires inappropriate cooperation, i.e. two or more entities have to be 'in cahoots'. All else being equal, for the IDP to have this knowledge (where the user goes) when it doesn't need it can be undesirable from a privacy point of view, but it's not collusion, it's leakage (and of course, all else isn't equal as Conor pointed out).
   
3. if the RP and the IDP are 'exchanging any information they want' without considering the privacy policies of the user, then the two of them are in cahoots, and colluding against that user. Both RP and IDP have 'turned'. The bar for two providers to go bad and collude against their users/customers is of course higher than for a single provider. How they find each other is one challenge. Do they advertise in the classifieds?

   SP seeks IDP partner for malicious & casual collusion. I enjoy curling up with a good book, stealing identity and walks on the beach. I 'm trying to learn to play the guitar, defraud the government, and snowboard Double Diamond runs. No kinkiness.

4. 'dispenses with the user and her browser altogether', in the sense of enabling identity flow without the user's active mediation, is of course necessary if you want to support use cases in which the user is 'offline' (as will be the case for many social-sharing use cases). How will active mediation systems like Cardspace support such use cases? Just pile up the requests for identity until such time as the user comes online?

Forced perspective

From Boing Boing, an example of 'forced perspective'.

Forced perspective is a technique that employs optical illusion to make an object appear farther, closer, larger or smaller than it actually is.

For identity operations, it could be used to make some operation appear 'safer' than actual.

Pictures of puppies, babies, or happy people on a log-in screen would qualify.

Too much information

Kim acknowledges the need for standardized information resources for Cardspace users (although the issue is of course not specific to Cardspace).

The research of the psychologist Paul Slovic on how the quantity of information does not guarantee quality predictions would seem relevant.

Slovic performed an experiment in which he gave bookmakers varying amounts of information relating to horses' performances, and then asked them to predict the horses' success in races. He found that the accuracy of the picks remained the same, no matter how much information the bookmaker had - the extra data just served to make the bookmakers more confident in their picks.

Users will soon be presented with skads of information designed to help them understand (and effectively predict) the consequences of their decisions regarding their identity - and its sharing. Will the information help them accurately predict the results of consenting to some identity operation, or simply serve to make them feel comfortable with their choice?

Shortlisted

A photo I took of HMS Belfast, moored in the Thames in London, has been selected for possible inclusion in a travel guide

Your photo(s) shown below have been short-listed for inclusion in the third edition of our Schmap London Guide, to be published at the end of this month.

While we offer no payment for publication, many photographers are pleased to submit their photos, as Schmap Guides give their work recognition and wide exposure, and are free of charge to readers.

If you would like your short-listed photo(s) to continue to our London Guide final selection phase, please read our 'Terms of Submission' and press the 'Submit' button, no later than our editorial submission deadline – Friday, June 22.

For an artist such as myself, for whom the digital photo muse is the only true arbiter, recognition like this is meaningless.

Confused (and not the disingenuous kind)

I'm confused (OK partly the disingenuous kind)

Stefan Brands asserts that I , along with Dave Kearns

wrongly equate unlinkability with anonymity

in a blog thread between ourselves and Kim Cameron.

Try as I might, I find no mention of 'anonymity' or 'anonymous' (and definitely no reference to 'anonymous credentials') in my post?

Dave can look after himself.

Male Brain circa 2010

A fellow traveller

Kim (a fellow traveller of mine don't you know) Cameran disagrees

The one statement Paul makes that I don’t agree with is this:

Were an IDP to use transient (as opposed to persistent pseudonymous) identifiers within a SAML assertion each time it asserted to a RP, then not only would RP’s be unable to collude with each other (based on that identifier), they’d be unable to collude with themselves (the past or future themselves)

.

I’ve been through this thinking myself.

Suppose we got rid of the user identifier completely, and just kept the assertion ID that identifies a given SAML token (must be unique across time and space - totally transient). If the relying party received such a token and colluded with the identity provider, the assertionID could be used to tie the profile at the relying party to the person who authenticated and got the token in the first place. So it doesn’t really prevent linking once you try to handle the problem of collusion.

Yes, but then we are no longer talking about 'RP/RP' collusion, in which (by my definition at least), the IDP stays pure and it is only the RPs that cross to the Dark Side. Bringing in the IDP changes everything (as Kim acknowledges by creating the separate 'RP/IP' correlation category.

Irving joins in (and he must be agreeing with me or I wouldn't link to him) to point out a Shib use-case. I was going to (smugly) point out how Sun used SAML/Liberty for enabling employee access to BIPAC as another example but, on digging a bit, it seems that they aren't using transient identifiers. I guess BIPAC wanted to provide employees continuity of service, e.g. no repeated questions like 'Are you now or have you ever been a member of the Communist Party?'

2nd Law of Correlation

This law which belongs to me is as follows.

Ahem. Ahem. Ahem. Ahem. Ahem. Ahem.

This is how it goes. Ahem. The next thing that I am about to say is my law.

Ahem. Ready?

The total correlation potential of two or more contiguous digital identity systems tends to increase over time, eventually approaching a maximum value of which marketing folks dream when they sleep.

Dopplrerati

The Dopplr effect swept through identity space last week (thanks to wave generator David).

I received a low-pitched follow-up this morning. The invite (identity obfuscated to protect the questionably innocent) is below



Dopplr has a list of my planned travel, as well as the same lists of colleagues of mine. In all likelihood, if and when we are going to the same destination at the same time, we are going to the same event (and so associated group logistics (e.g. hotels, shuttle buses, tours, etc) might be offered)

Why wouldn't airlines want this business (to the point of discounting it based on number of travellers)?

Come to think of it, Dopplr should be asking me for my FFF (Frequent Flyer Federation). It's points & upgrades, far more than the chance of an invigorating identity chat back in economy (the part of coach at the very front where they serve you drinks/meals first but otherwise treat you with equal disdain to the group of high-school students going to a band competition at the very back) that will drive my group allegiance.

Tags: Dopplr, VRM

Canada's no-fly list

As of today, we get our own list

Should be straighforward to manage

<eh:NoFlyList>

  <eh:ListRef uri="https://www.whitehouse.gov/noflylist.xml"/>

  <eh:OurOwnGuys>

    <eh:Entry>
      <eh:Name>Conrad Black</eh:Name>
    </eh:Entry>

    <eh:Entry>
      <eh:Name>Celine Dion</eh:Name>
      <eh:Direction allow="exit-only"/>
    </eh:Entry>

  </eh:OurOwnGuys>

</eh:NoFlyList>

Tags: no-fly list, Canada

Colluding with yourself

Kim Cameron introduces a nice diagram into his series exploring linkability & correlation in different identity systems.

Kim categorizes correlation as either 'IP sees all', 'RP/RP collusion', or 'RP/IP collusion', depending on which two entities can 'talk' about the user.

A meaningful distinction for RP/RP collusion that Kim omits (at least in the diagram and in his discussion of X.509) is 'temporal self-correlation', i.e. that in which the same RP is able to correlate the same user's visits occurring over time.

Were an IDP to use transient (as opposed to persistent pseudonymous) identifiers within a SAML assertion each time it asserted to a RP, then not only would RP's be unable to collude with each other (based on that identifier), they'd be unable to collude with themselves (the past or future themselves).

I was working on a diagram comparable to Kim's, but got lost in the additional axis for representing time (e.g. 'what the provider knows and when they learned it' when considering collusion potential).

Separately, Kim will surely acknowledge at some point (or already has) that these identity systems, with their varying degrees of inhibiting correlation & subsequent collusion, will all be deployed in an environment that, by default, does not support the same degree of obfuscation. Not to say that designing identity systems to inhibit correlation isn't important & valuable for privacy, just that there is little point in deploying such a system without addressing the other vulnerabilities (like a masked bank robber writing his 'hand over the money' note on a monogrammed pad).

User Dashboard

John Battelle discusses the relevance of a 'Privacy dashboard'.

Is it too much to ask, I keep asking, to ask our online services to provide us:

- Access to a record of all the information they keep on us and how they use it
- The ability to challenge that data's accuracy, and edit it for accuracy
- The ability to opt out (with a clear understanding of the resulting loss of services and opportunities that might result)
- The ability to set permissions as to who else might see the data
- The right to maintain a user copy of that data for archival purposes
- The right to share in the value of that data on negotiated terms

It's not stated but the implication seems to be that there would be such a dashboard for each provider in isolation, e.g. one for Google, another for AOL, etc. Dashboard silos. Beyond the implied management burden for the user are the issues such a model would create for providing a holistic view of their identity operations.

To combat this scenario, the Liberty Alliance is working on a Reporting Service, whereby the 'events' that a user/employee/citizen would wish to track/manage/approve would be communicated to their chosen 'dashboard provider' - thereby making possible a 'single' (the user could always have multiple providers) point of control as well as a comprehensive view of the W5 (who, what, where, when, why) of their identity transactions.

For instance, if Joe's calendar service shared his availability with their best friend Bob (based on Joe's previously set permissions), the calendar service could report this event (not the calendar data itself) to Joe's reporting service (and subsequently made available to Joe through a dashboard interface). If Joe, through the same dashboard, was able to determine that his wife Marie, simultaneous with Bob's query, was asking about Joe's whereabouts through Joe's geo-location service, he might have cause to be concerned (and perhaps avail himself of a 'Private Investigator Service').

Tags: privacy, dashboard, Liberty Alliance, Reporting Service

Guns don't kill people

People kill people (albeit with guns alot of the time.)

My identity corollary

Identity protocols aren't 'user-centric', deployments of identity systems are user-centric (or not).

Starpy?

During a discussion of terminology at this week's Liberty Alliance Technology Expert Group meeting, we noted the use of 'OP' (OpenID Provider) by the OpenID community to refer to their flavour of an Identity Provider.

A clear precedent for:

• 'LP' == 'Liberty Provider (who could hate somebody that increased the amount of liberty in the world?)


• 'FP' == 'WS-Federation Provider


• '*P' == 'WS-* Provider

Note: Yes thanks I am aware that LPs are antique technology. But consider the rich sound they give.

Today's Bible Lesson

Having finished my novel on the flight yesterday, I had nothing to read when I woke up this morning in the hotel room.

I opened the Gideon Bible to a random page.

Deuteronomy 25

14 "You shall not have in your house differing measures, a large and a small.

15 "You shall have a perfect and just weight, a perfect and just measure, that your days may be lengthened in the land which the Lord your God is giving you.

16 "For all who do such things, all who behave unrighteously, are an abomination to the Lord your God.

Amen to that.

I do hope Concordia is considered to satisfy the spirit of the directive if not the specifics.

When IDPs go bad

Nauru, and it's past indiscriminate issuing of passports to anybody who could pay for one, is an example of 'bad IDP', i.e. one that exercises less than the necessary due diligence in vetting it's users before making assertions about them (there are of course lots of other ways for an IDP to be 'bad')

Clearly, once the scam was recognized, customs officers around the world would have had their internal alarm bells set ringing anytime some traveler presented a Nauruan passport. At that point, it would have been almost better to have no travel documents at all than to have one from Nauru.

Traveller: Sorry Officer, I have no papers.
Customs: Hmm, that's a bit awkward, you see we normally do like to see a passport or something. Perhaps you could write yourself a little note saying where you're from?
Traveller: Sorry, no pen.
Officer: Ahh I see, well, that's probably best actually, we're trying to cut out self-asserted. Now let's think about this ...
Officer: (brightly) Say, you're not from Nauru are you?
Traveller: No sir.
Customs: (pause) Welllll, I guess I can make an exception. Just this time though OK?.

Strangely, I have more trust in Nauru's passport office than I do in its national airline.

Represent - verb

David Recordon gives his definition of 'represent' in explaining what he will be doing, and what he won't) at next month's Project Concordia panel at Burton Catalyst.

David's interpretation of 'represent' is consistent, I think, with the urban slang definition.

Coincidentally, it was through gangsta idiom that I was directed to represent my own company in Concordia.

Boss: We want you to help square up this identity mess, yo.
Me: So you want me to participate in Concordia?
Boss: Dat would be da hizzy.
Me: O.K.
Boss: Represent.

I do think Concordia needs our own 'gang sign'.

100% Canadian

Unfortunately so.

On the positive side of the Ottawa Senators loss to the Anaheim Ducks in the Stanley Cup finals is that I won't have to listen to the mono-syllabic 'analysis' of Don Cherry for a while.

When the most visible hockey export from Canada is 'All youze kids out there, youze guys, aints, anyhows, anythinks and dat deres', is it any wonder the game can't gain market in the US?

Blurring multi-factor

Would this be:

• Something you know, or
  
• Something you are, or
  
• Something you have.

Or all three?

I think there is a security loophole. My wife (says she) always knows what I'm thinking so she'd be able to impersonate me.

Surreal

I just used an OpenID (from Vidoop.com) to log in to the (erstwhile Liberty Alliance driven) Project Concordia.

I think there needs to be a Concordia use case along the lines of


Protocol Confusion

Preconditions

1) User knows what OpenID and SAML are

Sequence

1) User visits site at which they expect SAML-based identity protocols.
2) User instead sees OpenID-based identity options.

Pause

3) Confused, user checks their address bar for location confirmation (and vows to stop spiking morning coffee with Kahlua.)
4) User proceeds warily, expecting SAML colleagues to jump out and yell 'April Fools'

Post conditions

The metasystem is a bit closer.

Tags: OpenID, SAML

Vidooping

I received an invite to the Vidoop Beta, so signed up for an account.

The sequence by which you pick your image grid is pretty slick. Below are the categories I chose (completely randomly I assure you)


Once categories are chosen, they help you practice

before eventually presenting you with a real grid to authenticate with



My tests indicate that the order of the characters for the code doesn't matter, e.g. 'AGB' is as good as 'GAB' in the above. Not sure why.

RFJ 2007

Some 25 members of our extended family participated in last weekend's 'Ottawa Race Weekend' - running/walking either the 5k or 10k.

We all wore t-shirts with a picture of my brother-in-law Jamie, who we lost to heart failure last year.



It felt like I was carrying Jamie within me. Maybe that's why my time was so poor - Jamie was a big man.

Black Swan

I've just started reading 'The Black Swan - The Impact of the Highly Improbable' by Nassim Nicholas Taleb.

According to the prologue, a Black Swan phenomenon is characterized by the fact that it:

• is an outlier, ie. it's not expected or predicted.
• has an extreme impact (isn't defining one of the necessary criteria for some event to be considered 'impactful' as 'must have extreme impact' a bit circular?).
  
• we attempt to explain its occurrence after the fact.

By the time I finish the book, I vow to have determined an identity Black Swan.

I can think of plenty of identity events that meet 1 or 2 of the above criteria (e.g. Microsoft saying they'd support OpenID wasn't expected, Conor singing Bohemian Rhapsody had an extreme impact (on my GI tract), everybody is trying to explain WS-Federation 'after the fact', etc) but, as yet, no events that meet all 3.

p.s. apparently, Black Swans make what you don't know far more relevant than that which you do. So, I got that going for me.

Lazarus-like

I received the following email this morning

Subject: [security-services-chair] Groups - Mr. Jeff Bohren removed from OASIS Security Services (SAML) TC

Date: 31 May 2007 19:14:53 -0000
From: workgroup_mailer@lists.oasis-open.org
To: security-services-chair@lists.oasis-open.org

Mr. Jeff Bohren from BMC Software has been removed from OASIS Security Services (SAML) TC (user left the group)

Given that I know of an upcoming piece of work that Jeff is spearheading for the SSTC, this came as a surprise. When I asked him for clarification, his response:

The rumors of my death have been greatly exaggerated. To switch from observer to member you have to remove yourself first and then to reapply as a member, which I have done. Since I am now the primary rep for BMC, I also approved my own application. SOD, what SOD?

Would this be an example of reprovisioning?

Separately, I applaud Jeff's usage of 'In Flanders Fields' as a tribute for the recent US Memorial Day. The poem (with associated poppies), is a key piece of our own Remembrance Day here in Canada. I venture that more Canadians can recite it in its entirety than our anthem.

Brute Force Attack

I'm determined to get me one of these (or at least temporarily borrow one) so as to avail myself of the advantages).

Given that I know a number of real Sun employees and, after years of meeting & social exposure, can claim some insight into their personalities, I think its worth my time to try to guess their passwords for logon (I already know their emails).

First attempts

1. astitchintime
2. skinnyasasnake
   
3. laformulaune
4. notapat
   
5. whenisnexttegmeetinginparis
   
6. sarcasmishighestformofwit
7. isoldmysoultorockandroll
8. whiskeyisgodselixir
9. turnofftheairconditioning
   
10. youcantpushstring
11. baguettesandredwine
12. iregretwssomex
13. perfidiousalbion
    

Just a matter of time now.

Tags: Sun, OpenID