Friday, May 30, 2008

SocialHistory.js exploits a CSS leak to determine which social networks users have visited.

SocialHistory.js works by exploiting the feature in modern web browsers that automatically uses a different link color for visited links. The JavaScript loads up a bunch of links from a list of top social media sites in an iFrame and looks at which have been visited based on the change in link color. From there, it can assume which you are most likely to use

Thursday, May 29, 2008

In a move that has stunned the industry, Microsoft announced today that they have entered into an agreement to be acquired by Ping ID for an 'undisclosed sum'.

Even long term Microsoft insiders are shocked. Said one, on condition of anonymity,

'Well the way I hear it, it's all just a big misunderstanding, but the big guys can't admit it. Apparently, in the middle of the Yahoo! discussions, Steve sent the legal team an email saying "Ping me, acquisition". Next thing you know, here we are ....'

When asked about the deal, Ping's CEO Andre Durand was quoted as saying

'Well it's always been part of our strategy, it just came together a little bit ahead of schedule. We made another acquisition a little while ago and it was pretty straightforward incorporating that product line, so we figured we'd be ready for this.'

When asked how long he expects the integration of the huge Microsoft into the small Ping to take, Ping's CTO Patrick Harding responded

'Oh, she'll be right. We've got some ace tech that just makes it bloody heppen. I reckon by brekkie tomorrow we'll be apples.'

We examine the possibility to employ neutrinos to communicate within the galaxy. We discuss various issues associated with transmission and reception, and suggest that the resonant neutrino energy near 6.3 PeV may be most appropriate. In one scheme we propose to make Z^o particles in an overtaking e^+ - e^- collider such that the resulting decay neutrinos are near the W^- resonance on electrons in the laboratory.

Johannes led a session at IIW2008a entitled 'Partioning the Space', in which we specifically attempted to come up with new visual metaphors for identity which would help explain/understand the space.

One idea was to sketch out the value/depth of a relationship between a user and some service provider as a function of time. We posited that the depth would climb smoothly over time, starting from zero.

Over time, the depth of the relationship grows, one manifestation of which is the collection of user attributes by the SP.

Federated identity makes (perhaps theoretically) possible a model in which a relationship can be 'jump started' with identity, these attributes collected from an IDP rather than through successive transactions between the SP and the user.

From the PoV of the user, this step-function establishment of the relationship may feel artificial, as the depth (as determined by the attributes the SP has) does not reflect any shared history. It may also feel artificial to the SP.

An 'identity collection model' that better aligns to the 'slow growth' relationship curve is one in which the SP obtains the user's identity on a JIT basis. Rather than try to obtain identity attributes in anticipation of future need, the SP waits till it actually requires some attribute.

(Bob Blakly made the point in his relationship talk at IIW that, because of the associated risks, SPs will more and more think of identity as 'hand grenades', i.e. something you don't hang on to longer than absolutely necessary. The flip side of throwing the hand grenade as quick as possible is of course only asking for it when you really need it.)

For this to work, the SP & IDP will need the ability to reach out to the user on a JIT basis to both collect attributes and clarify consent, and not rely on the user's erratic surfing schedule.

Wednesday, May 21, 2008

Consider some magazine at which I've subscribed. The mag only needs my address at the start of every month, just in time for sending out that month's edition.

Their demand curve (I'm sure there is a proper economics term) for my address looks like

If the magazine relies on me actually visiting their site (to view online content etc) as the mechanism by which it can get the most recent address, then they are at the mercy of my erratic visit schedule for the update operation.

Although I think the name is misleading (do not other cards also represent relationships?), Higgin's R-cards are interesting.

My (current) understanding is that R-cards are used to establish a long-lived, secure & privacy-respecting 'identity pipe' (or is it a bus?) between some entity that holds a user's identity, and another that wants those attributes. Unlike the relationship enabled by 'normal' cards, the R-Card relationship works even without the user's explicit participation/mediation at the time of sharing. (how about a name that reflects this distinction, e.g. Direct-Card, Silent-Card, etc?)

What R-cards don't do is define just how the identity actually flows, i.e. what are the specifics of how the requestor asks for the attributes, in what format are they passed, how can the requestor subscribe to be notified should they change etc.

That's where something like Liberty ID-WSF is needed, because ID-WSF defines just this sort of plumbing.

Fundamentally, to get things going for ID-WSF, the requestor needs to get a WS-Addressing EndpointReference (EPR) (as profiled by Liberty) for the user's Discovery Service. Once armed with this DS EPR, the requestor would be able to obtain the EPRs for particular service types, e.g. contacts, calendar etc.

The graphic below portrays this simplest case.

As modelled, the originally provisioned card does not capture a semantic of 'this attribute is stored at this provider' but rather 'This card can be used to discover where the user's attributes are stored'. Is this weird?

To test the Google Health privacy policy, I plan on adding all known conditions, diseases, and ailments to my profile.

The theory is that if some drug company contacts me with an offer to participate in a drug trial, then I'll know that Google sold my data to the highest bidder. If not, I will continue to trust Google with my calendar info.

I plan on working through alphabetically as the interface for adding conditions is slow & clunky (why not a 'Select All' option?)

I've learned to live with the fissures, but I do confess that the pap smear results have me concerned. And the 'premature' thing? That was just once!

To my mind, an interesting twist of a mobile selector is that the resource being accessed need not be accessed on the mobile, i.e. a mobile selector can be used to facilitate PC based access.

When surfing from a PC, rather than rely on any selector on the PC, use the one you have on your phone (and thereby indirectly achieve card portability across different PCs). This is the same model that NTT explored with our SASSO - a SAML IDP on a phone.

One challenge for this model is solving the 'how do I wake up the identity agent?' issue. In the 'normal' sequence, the selector is invoked by the browser (or some other application) when it comes across some indication from an RP that identity is being sought.

Not so easy to do when the application is on the PC, and the selector on a phone.

You either have the PC communicate the invocation to the phone (through Bluetooth, QR codes, etc), depend on the selector to determine if it needs to wake up at any instance (by polling, etc), or have the user manually launch the selector.

The 'verifiedness' (verificity?, verificabiltiy? verificatiousness?) is built right into the claim identifier.

To my mind, the level of assurance that can be ascribed to a claim is orthogonal to the claim itself. An IDP makes a claim, and then provides supporting information to help an RP decide how to treat it.

I understand the attractiveness of Sun's new fedlet (separately, the site gets my vote for most tenuous application of Guns'n'Roses - I'm seeing Axel drunk on stage at some future JavaOne) mechanism for quickly enabling federated operations with a partner, but how is it all relevant that fedlet is built on SAML?

If you control the technology at both the IDP & SP ends, the fact that both ends use a standard for messaging and assertions is irrelevant isn't it?

Would the fedlet, once deployed by an SP, be reusable with other IDPs (than the one that created it initially) and thereby be considered a quick and easy way to SAML enable an SP? I bet not.

Monday, May 19, 2008

Word from Redmond is that, inspired by this salesmanship fiasco, in order to demonstrate their corporate loyalty Kim and Mike are working on their own music video, a duet remake of the Beatles 'Please Mister Postman'.

I been standing here waiting mister postmanSo patientlyFor just a card or just a letter

Disquieting as that thought may be, I find it less disturbing than the conflicting rumour that the two of them will be performing 'O SAML Mio' with Vittorio.

I don't think I can count how many times I heard discussed at IIW the privacy challenge inherent in one user deciding to share their social network - the contents of which necessarily containing or referencing the PII of other users.

As far as I know, there is as yet no name for this effect/issue?

As they say, Nature abhors a terminology vacuum .....

According to Wikipedia,

Usufruct is the legal right to use and derive profit or benefit from property that belongs to another person, as long as the property is not damaged.

The word derives from the Latin words for 'use' & 'fruit' - the archetypical example is enjoying the apples from a tree growing in your neighbour's yard (and not harming the tree).

Is my sharing of the fact that you are in my social network an example of usufruct?

User-centric is out, relationships are in, according to Bob at least. Rather than think of identity as being centered on the user, Bob argues that it is more appropriate to think in terms of of the relationships that exist between the user and their providers (and their friends etc.)

Bob draws an analagy between this interpretation and planetary dynamics. Before Nicolaus Copernicus, the belief (popularized by Ptolemy) was that the planets and Sun orbited the Earth - a so called geocentric universe. Copernicus proposed what he saw as a simpler model, he demoted the Earth from the center and placed the Sun there instead - a heliocentric model.

As important as this shift was, Copernicus stuck with other aspects of the geocentric model. For instance, he still described the planets as orbiting on circular paths on fixed invisible spheres in space. So, a step closer to the truth, but no better at creating a stable calendar than Ptolemy.

It was on the observations of the Dane Tycho Brahe that Johannes Kepler took the heliocentric model to the next level. Kepler used Brahe's data to calculate elliptical orbits for the planets, the motion due to a force of attraction from the Sun and no longer requiring magical spheres.

Johannes Ernst led an interesting session at IIW entitled 'Partioning the Space'. In that session, we developed an interesting way to think about how the relationships between customers and bricks'n'mortar stores deepen gradually and incrementally, but how typical consent models in federated identity completely break with this slow growth pattern (e.g. 'Do you consent to sharing all your identity attributes with this SP you've just met?')

Therapist: So, SP, why don't you get us started and tell me why you and User are here today?SP: Well, I just think that User and I are drifting apart. The relationship was great at the beginning. I mean, User even had a password with me. And I stored all his attributes. We were really close.Therapist: And that has changed?SP: yes, ever since he has been hanging around with his new federated friends, things are different.Therapist: How so?SP: Well, for one thing, we never spend any, you know, err .... 'quality time' alone.Therapist: Quality time?SP: (blushing) yes, he uh, he always insists now that one of his IDP friends join us.Therapist: And how does that make you feel?SP: Well, let's just say that my Mother didn't raise me that way.Therapist: OK, I see. User, why don't you tell me your view point.User: Well, I don't see what the big deal is. Sure I'm bringing some IDPs home, but I'm just trying to spice up the relationship - the password thing was getting tiresome. Therapist: And you think adding IDPs to the relationship will help?User: Yeah, and I mean, it's not like I'm bringing home some Passport or anything. These IDPs are all right.Therapist: SP, is the issue that you don't know anything about these IDPs?SP: Definitely. User will have a few beers after work and then just show up with some IDP and, with only a very brief introduction, expect me to 'party', as he puts it. And then he says he wants to watch because he doesn't trust us!Therapist:Just to clarify, by 'party' do you mean engage in the transfer of identity assertions?SP: Well yes, but you don't have to be so blunt about it.Therapist: Sorry about that. Would it help you if you knew more about these IDPs that User was introducing you to?SP: Yes I think so.Therapist: OK, I think we're getting somewhere. User, would you be OK with if SP got this info about your IDP friends?User: Sure, just so long as I still get, you know, serviced ....SP: And a bottle of wine wouldn't hurt either. Maybe some flowers once in a while. An SP likes to feel appreciated after all.Therapist: User...?User: (sighing) Sure, wine & flowers sounds fair. Hey, can we talk about her Mother-in-Law always coming over?Therapist: Let's save that for the next session. SP, are you in agreement that User can involve IDPs if you are able to find out more about them?SP: Yes, but fair is fair right. Maybe I might want to party with an IDP User introduces me to without User even being at homeUser: No way, nope, I'm not ready for that. I need to be present.Therapist: Why don't we work up to that. Baby steps right?

I think it was the psychology course I took in 1st year (or maybe its because I'm an Ottawa Senators fan) but, for some reason, I am particularly attuned to the suffering and frustration of others.

That's why I'm able to read between the lines of Andy's post on Infocards and see what most people, oblivious to the subtle signals the post sends, would miss.

On the surface, Andy's post is an amusing romp of a story about an experience he had with Infocards, specifically logging in to leave a comment on Kim's blog. All seems well. Dig a little deeper however, go beyond the surface hunky-doriness, and there are tell-tale signs that the experience might not have been optimal for Andy.

For an emotionally aware person like myself, certain phrases act like signposts for Andy's, otherwise hidden, true frame of mind. Phrases like

- Infocard Hell- frustrated anxiety- I have now been trying to write .... about this damn post for 3 hours

are indicators that many just don't (or won't) see. You shouldn't feel bad if you missed them. I am, as I said, very sensitive.

Someone less sensitive than I, someone more inclined to go for a laugh at the expense of another, might say to Andy

'Hey man, stop your whining and suck it up. You've just come across the joy of tri-party communication interoperability.'

It's a curse being this tuned into the suffering of others. Weddings for example, make me cry every time.

Tuesday, May 13, 2008

It was by pure luck (for me, as he has a car and can drive me to and fro the meetings) that I ended up in the same hotel as Peter for IIW2008a.

The lovely Ramada Inn Limited. Pool, hot tub and free breakfast. Business travel at its best.

It's the combination of Peter's bookings that is critical. If he and I were both in the same hotel but he had no car, then the benefit to me is limited, perhaps shared cab fare and some sarcastic and snide banter on the drive.

If on the other hand Peter had a rental car but was staying at a different hotel, then I would need to guilt him into picking me up and dropping me off each time. I've had great success with this ploy in the past but I don't like to overuse it.

What I would love is a hotel booking engine that, in addition to allowing me to filter hotels based on the normal criteria, e.g. free WiFi, pool, exercise room, etc, it would allow me to specify a search param of

"Only show me hotels where a friend who has rented a car are staying (and give higher weight to a convertible)"

This would be a special case of using your social network to help find services of interest and value, as in the diagram below (which I cant remember if I created, stole, or adapted)

In Liberty People Service, the rough flow would be

1) Expedia.ca, helping me book travel, discovers and queries my People Service to see my 'Travel Friends'2) Expedia.ca uses info it gets from People Service to discover and query the 'travel calendar' of each of those friends3) Expedia.ca uses info in my friends travel calendars to filter out hotels in my search4) I ride for free

Do you not think that, given that 90% of people's photos are of the same people (either young & drooling, or older and intoxicated) over and over, that this privacy protecting process is somewhat irrelevant?

In Drummond's macrame demonstration, Asa's ability to end the relationship with a single snip was portrayed as key.

In the absence of e-scissors (now there is a business model and domain name packaged up for you), how might relationships be ended?

Follows are some of the 'relationship termination reasons' asserted to myself over the years, almost all of which might be used to severe an identity relationship.

- Work is really busy these days- Let's still be friends- You know, I was really drunk- You're really awesome, but ....- I like you, but not in that way.- I'm not looking for a big commitment- It was Spring Break!

Saturday, May 10, 2008

- Privacy Constraints- Reconciling OpenID PAPE & SAML AC- Profiling WS-Trust for security token issuance within ID-WSF- a 'multi-device' SSO use case, where a user starts watching a video on her mobile, but then transfers the security & application context to her set-top box so that she can watch the remainder in HD- a RESTful/like binding for ID-WSF- Orange APIs

Friday, May 09, 2008

Flying back from the Liberty Alliance TEG meeting at AOL, I endured the tangled web that is the security screening lines at Dulles Airport. I felt like a rookie running back, more motion sideways and backwards than forward.

I take one consolation from the experience. Where ever my future travels may take me, whether the Sudan or some back-water single runway airport in Thailand, I am confident that I have already seen the worst organized security check that bungling incompetency can devise.

Liberty Alliance TEG yesterday voted out for public review a 'Privacy Constraints' specification.

From the introduction

Privacy constraints describe fundamental constraints on the propagation, usage, retention, storage and display ofidentity data. Increasingly, there is concern regarding appropriate use of identity data and Privacy constraints allow the expressions of constraints over the processing of such data.

This document describes a small set of atomic privacy constraints. They are not meant to be exhaustive and we fully expect that communities will define additional assertions based on geography, industry and law.

Using policy frameworks such as WS-Policy, authorities (custodians of identity data, end-users) and consumers (applications, enterprises) can use Privacy constraints to describe composite constraints on identity data. For authorities, this takes the form of indicating the conditions under which data is being released; for consumers this takes the form of indicating the conditions that will govern their use of data.

Privacy constraints describe conditions under which identity data is sought or released. Exactly how Privacy constraints would be used in practice is outside the scope of this work. Depending in business context, they may be added to message flows in protocols or viewed as meta-data associated with identity data.

Generally, when a privacy constraint is bound to a request for some attribute, it is interpreted as a ’commitment’ the requestor is making with respect to its actions should it receive the attribute, when bound to a response carrying an attribute, a constraint is interpreted as an ’obligation’ attendant upon the recipient.

While Liberty kicked this off, my personal view is that subsequent work needs to happen in the wider community - wherever the right place for that may be.

Thursday, May 08, 2008

I'm watching the Fox morning show in the hotel room. The host's banter is so real, they obviously really like each other.

One story is about the debate over students from some Minnesota high school traveling to Spain on a class trip.

Apparently, the law in Spain will allow 17yr old students to drink alchohol should they so choose - even though they are not of age in their home domain and so can't legally quaff Bud back home.

The teacher in the debate (who travels with the kids) made the point 'the kids travel to Spain, our laws do not travel to Spain'.

Timely. In Liberty Alliance TEG's discussion of IGF's CARML yesterday, we talked about a use case in which an application used CARML to express a need for a user's age, actually not the age itself but whether the age was above some threshold.

How the threshold is expressed will impact on the students imbibing.

If the drinking policy is expressed as 'isAgeGreaterThan19', then the students will not be drinking overseas. The policy is bound to a specific locale by hard-coding the threshold in.

If however the policy were expressed 'isAgeLegalForDrinking' then the policy can be localized appropriately - the wine can flow (assuming parental consent etc) when in Spain but not in Minnesota.

There was also a story about a prison in Louisiana that uses black bears as prison guards. I did say I was watching Fox.

Monday, May 05, 2008

Notwithstanding that it enables an arguably anti user-centric modality, the British governments 2004 policy of authorizing torture provided that they

“neither procured the torture nor connived at it.”

would appear to be a perfect application of federated identity, i.e. you want the info, but don't want to concern yourself with the messy details of how it is obtained?

I see the need for a 'Torture Context' syntax. This would give to RPs the extra information they need to assess the assurance level of the confessions - everybody knows water-boarding is far more trustworthy than sleep exhaustion for instance.

In a previous life, I dealt with Feynman diagrams, a visual tool of theoretical physics.By modelling a particular interaction between sub-atomic particles in this way (straight lines are particles that make up matter, wavy lines are the particles that mediate the forces between the matter particles), and using experimentally determined values for the coupling strengths (e.g. 1/137) of the different vertices between the lines, you would (after alot of horrid math and tracking of 'i's and 'e's), calculate the probability of that interaction occurring.

The above shows two electrons colliding to create a photon which, after a short delay, disappearing with two quarks emerging from the debris (a back of the envelope calculation shows that the probability of the above is 'sometimes').

Now I deal with swimlane diagrams

The math is much easier - the probability of any given interaction occurring isn't determined by fundamental constants but rather by market forces.

Eve considers the risk of new identity systems, by facilitating the flow of identity, exacerbating the problem of identity flowing unnecessarily.

In her proposed best-practices, Eve presents an iterative identity collection model - applications ask only for what they need right now, and not what they expect they might need in the future.

Not wanting to preempt Eve's next post

More thoughts soon on some solution opportunities in all this…

but ...

Liberty's CARML, through use of <ws-Policy> elements on the <Interaction> , would allow an application to indicate priorities for the various identity attributes it required (or simply desired). So, for instance, a tee time booking application (tieing back to Eve's story) could indicate that it absolutely required the golfer's handicap but that it merely wanted whether they were right/left handed.

I'm not sure that priority labels alone are sufficient to support an incremental collection model. The tee time application may absolutely require the golfer's favorite beer, but only at such time as the beer girls cart draws near them on the back nine.

Friday, May 02, 2008

From Marco, a great HP paper on Identity-Aware Devices, describing some PoC work HP did with Intel around the Liberty Alliance's Advanced Client specifications.

Current users’ experience with mobile devices, in networked and federated services, is difficult and painful: users need to create (one or more) user accounts, disclose profile information, authenticate against service providers, get additional credentials to access services and ensure that these credentials are stored in a safe and secure place.

Thursday, May 01, 2008

John Gerard was an English Catholic Jesuit priest imprisoned in the time of Queen Elizabeth I, for perceived treachery and treason against Elizabeth's government and reign.

While in the Tower of London, he contrived to send secret messages to another prisoner John Arden. Gerard would write his messages in orange juice on the wrapping paper of parcels he would bribe his gaolers to deliver to Arden. Invisible to the messengers, once warmed by a fire, the messages would appear.

The first time the system was used, Arden was unaware that there were any hidden messages at all, and promptly disposed of the wrappings. Clearly incompatible security expectations.

It was only when the two (through a pantomine of squeezing and writing from their separate regions of the Tower) were able to agree on the encryption algorythm to be used that they were able to organize their escape.