Feedback to prevent ID Theft

Researchers at Stanford are looking at ways in which drivers could be encouraged to not speed.

The domains covered in the idea space included foregrounding of information to increase awareness, visual and audio notification, providing haptic feedback (accentuating real-world effects), reputation systems (publicizing driver reputation / behavior), offering trade-offs (gas consumption, speeding tickets), rewards and incentives (insurance incentives for monitoring), and playing on emotions.

Assuming that this sort of feedback wouldn't do much to discourage a phisher from sending an attack (it would be difficult to convince them to attach electrodes to their fingers for instance), perhaps it could be used to alert the recipient of the potential dangers of "clicking on the URL"?

As the idea of simple visual indicators to show the risk level of emails has been done, perhaps:

1. mouse vibration alerts recipient of risk (maybe for really obvious phsishes the mouse just refuses to work and sits their shaking crazily?)
   
2. paying users to NOT click on URLs in suspicious emails.
   
3. dynamic graphic showing their bank account balance dropping
   
4. publicly listing those who do fall prey
   

Liberty ID-WSF is an identity metasystem

Already with ID-WSF 1.1, but to a greater extent with upcoming ID-WSF 2.0, Liberty's Web Services Framework meets the logical requirements of (at least part of) an identity metasystem.

From Microsoft's whitepaper explaining their vision (my emphasis below):

The Identity Metasystem is an interoperable architecture for digital identity that assumes people will have several digital identities based on multiple underlying technologies, implementations, and providers.

and

The metasystem enables identities provided by one identity system technology to be used within systems based on different technologies, provided an intermediary exists that understands both technologies and is willing and trusted to do the needed translations.

In ID-WSF, the 'technology' that is (currently) allowed to be different between the two providers, and that can be 'translated' to some extent, are security tokens. The web service provider (WSP) can, when it registers its service at the Discovery Service (DS), indicate which security token formats it expects (e.g. SAML, X.509, bearer, etc). When a client WSC) subsequently queries the DS for available services, it can also indicate which token formats it can support. It is the DS that looks for an intersection between the two different sets of security tokens and (acting as an STS) provides an appropriate token format to the WSC for inclusion in its subsequent request to the WSP.

Additionally, the DS may need to perform some translation between the security token that the WSC presents it as part of its discovery query and that which the DS returns to the WSC for inclusion in the request to the WSP. For instance, the WSC may present in its discovery query a SAML 1.1 assertion that it received from an IDP through ID-FF based SSO. If the relevant WSP (that being discovered by the WSC) only supports SAML 2.0 assertions, then the DS will have to translate from SAML 1.1 to SAML 2.0 to ensure that this WSP gets what it needs.

Admittedly, this level of flexibility on security token formats is not the wide-open freedom of different providers being able to choose different protocol stacks. But there is a price to be paid for that freedom.

Social lists

I use Webjay alot for streaming music. The site allows you to define playlists of (legally) downloadable MP3s. The playlists you create are connected to others that share the same songs. The resulting network is a great way to discover new music - there is a better chance that I'll like a song that somebody else likes if I know that we already share tastes in music.

So I get exposed to lots of great new music and artists. Oftentimes, as I listen, I think 'X would like that' where X is some friend of mine. As it stands now, I manually send an email to X with a link to the song in question. This is less than ideal as there is no record of the connection for future reference and X has to keep track of these sorts of 'invitations'.

I think there is value in the idea of people defining lists (songs, bookmarks, radio stations, geolocations, etc) FOR others rather than themselves.

A system which exposes people to new things (e.g. music, sites, etc) would be valuable - that's the problem with sites like iTunes - you have this wealth of great music that you just know has songs you will love, but but don't know how to get to them.

What your friends think would be interesting "to you" would be a valuable entry point (far more than some untargetted 'Whats popular')

TUID (Torah Unique Identifiers)

This Wired article discusses how, to complicate the trafficking of stolen Torahs, two rival registries have been established.

Historially, it has been the "anonymity" of Torah scrolls that facilitates the fencing of stolen scrolls.

Torah scrolls are inherently anonymous. Jewish law dictates that not one character can be added to the 304,805 letters of the Torah's text. That means no "property of" stamps, no serial numbers, no visible identifying marks of any kind.

Because in the past there has been no way to verify whether or nor a particular Torah is 'hot' (because there has been no way to label it), thieves have had an easy time selling stolen scrolls to unsuspecting congregations.

The two registries, the Universal Torah Registry and the International Torah Registry take different approaches to identifying individual Torahs in a manner that doesn't violate rabbinic law - the first by a unique pattern of pin pricks, the second by an analysis of various distinguishing features (e.g. line spacing etc ).

These TUIDs (Torah Unique Identifiers) are global. Do not Torahs also deserve privacy protection? Seems there would be an opportunity for federated identity management between the two registries.

What SPF factor would you use?

Sun's Eve Maler followed up on a Tim Bray (also of Sun) post on 'research' that indicated that sun exposure wasn't necessarily bad:

I have long been suspicious of answers to the question of how much sun exposure is good/bad for you.

I expect this is neither the official Sun line:

1. on being an employee, or
   
2. on the MSFT/Sun relationship
   

Personally, I value my sun exposure and so will not take any dramatic measures to protect myself in future standards meetings.

PAOS

Eve Maler suggested an alternative shibboleth for distinguishing the SAML community from others - namely the pronunciation of 'PAOS'.

Eve points out that the shibboleth I had proposed - 'back-channel' - was originally introduced by Liberty and so it doesn't serve to distinguish SAML from Liberty. While not ignoring the differences, I actually think of Liberty as part of the 'SAML tribe' - fundamental as SAML is to the LAP architecture.

Eve postulates that:

in SAML discussions, this is usually pronounced “pay-oss". But in Liberty meetings, it’s pronounced “paah-ose” – by some of the same people.

I'm at a Liberty meeting right now so I'm going to start keeping track of how people say 'paos' , results to come.

QWERTY

Never was a blog title easier to type. Of course, it was easy because the keyboard is arranged to make it so.

The name "QWERTY" for our typewriter keyboard comes from the first six letters in the top alphabet row. It was invented by C. L. Sholes, who put together the prototypes of the first commercial typewriter in a Milwaukee machine shop back in the 1860's.

As the (possibly apocryphal) story goes, the Qwerty design has little to do with modern efficiency - rather being optimally inefficient. The layout was designed to keep frequently used letter pairs (E and D or T and H) relatively far apart so that typists wouldn't hit them in quick succession, jamming primitive machines. Typists on early models were too fast!, by rearranging the keyboard Sholes was able to slow them down.

This interpretation of course misses the point. By arranging the keys in this manner Sholes almost certainly enabled faster typing as the typist wouldn't have to repeatedly stop and clear the keys. Qwerty was the (or at least one of) optimal design given the limitations of the striking technology at the time. It was only when the technology moved forward (e.g. those cool balls, and now PCs) that the designed limitation of Qwerty became irrelevant and sub-optimal. Until that point, the limitations of Qwerty enabled an overall more efficient system.

XML is almost certainly a sub-optimal syntax if the criteria are only on-the-wire speed and processing efficiency. Nevertheless, XML's advantages over binary formats (ASN.1 etc) in inspection and transformation outweigh the disadvantages. Overall, when taking into account design, development, testing etc, XML enables a more efficient system.

So XML is the Qwerty keyboard of this IT era. It may not be perfect but it's better than the alternatives.

Aromotherapy for ID Theft

Wired reports that users, when exposed to the neuropeptide oxytocin
are more apt to feel 'trust'.

Researchers at the University in Switzerland in Zurich put the theory to the test and found that 45 percent of the oxytocin sniffers displayed what the scientists determined to be the "highest level of trust" with their money. Only 21 percent of those in the placebo group were as trusting.

Other research confirms the findings.

This suggests a new tack on id theft. A Firefox GreaseMonkey script that, on browser access to a quesitonable site, releases a small puff of 'oxytocin inhibitor' (surely there is one?) The otherwis naive and trusting user, after inhaling, would experience a strong sense of fear, uncertainty, and doubt. Instead of obediently providing their password, they back slowly away from the computer, shaking their head in confusion.

Hopefully the effect wears off before their spouse gets home. That sort of refinement will have to wait for v2.

Art thou a SAML'ite?

Notwithstanding its most recent manifestation, a shibboleth is a word or phrase that can be used to distinguish one group of speakers from another, typically through pronunciation. In the Bible, the Gileads used the fact that the dialect of the people of Ephraim did not include the 'sh' sound. Consequently, when an Ephraimite was challenged to say 'Shibboleth', it came out as 'sibboleth'. The Ephraimite was thereby identified and quickly slain (slewed, smite ?).

In World War II, the Finnish underground took advantage of the complete unpronounceability of their language (e.g. Nokia) to ferret out infiltrators. Our Canadian border officers now use the pronunication of 'out and about' in a similar manner.

Shibboleths are not always used in such a prejudicial and divisive manner. By identifying differences they can serve as focus point for dialog and self-improvement. For instance, Americans pronounce the last letter of the English alphabet 'zee', the entire rest of the world, as was intended, says 'zed'. Throughout history, many awkward situations have been defused because of this humourous distinction.

In this spirit of the word, e.g. acting to bring people together through self-awareness of their differences, I propose here a shibboleth for distinguishing the SAML community from other federated identity management initiatives, namely the term 'back-channel'.

For SAML'ites, the term refers to a SOAP-message channel between providers, distinguished from a browser-intermediated 'front-channel'. Other federated identity proposals either have no corresponding channel in their architectures or, if present, do not describe it in this manner.

Other, less technical, interpretations for "back-channel" are also possible and thereby make 'back-channel' an option for the desired shibboleth between the tribe of SAML and others. If you are unable to say/write 'back-channel' without your mind straying to such alternative interpretations, then you cannot be of the SAML tribe.

With increased awareness of this fundamental differentiator amongst its members, the federated identity community can now move forward and tackle the more significant issues that confront us. As my analysts like to say, the first step to getting better is admitting you have a problem.