Tuesday, October 31, 2006
Roger makes his first posts to TrayTable.
Not an auspicious start.
It's not the fact that the tray table is on the Shinkansen as opposed to an airplane that I object to, but rather the occupant of the seat.
And it looks like we have another Business Class flyer. How nice.
So, what to call this sort of IDP?
As the new functionality is quantitative rather than qualitative, 'merely' a new layer on top, the 'marketing' answer to the question is clear. We need a name that suggests the exact opposite, i.e. that this sort of IDP is nothing like the old type, a name that sends the message 'New and Improved!', 'Gets Whites Brighter', 'Low on Carbs', etc.
We need a name that even suggests these new type of IDPs won't even work with old-style SPs, this is no dot-release for which we can guarantee backwards compatibility.
If only there were an example of such branding in the identity-space to guide us.
Perhaps just change the emphasis of the letters of the spoken acronym to distinguish old and new, as in 'ShinaGAWA' and 'ShiNAGawa'.
I also need to smile more. I was talking about exciting stuff but the look on my face makes it seem that I was describing the state of convergence in the Web SSO space. Is that a tear in the corner of my eye?
Monday, October 30, 2006
My team of wily veterans was outplayed by a combination of youth, skill, and speed. The outcome was completely fair and appropriate. The best team won.
Consequently, I have filed a petition with the International Corporate Lunch Time Sports League to have the result overturned on account of shabu-shabu induced lethargy amongst key members of my team.
Loyalty, both to NTT (my employer) and to the Liberty Alliance (the SDO where I spend much of time), would have me fly JAL at every opportunity.
But, JAL is not a member of the Star Alliance (the airline alliance of which the airline I'm pulled to through patriotic loyalty is a member), instead their competitor ANA is.
Flying ANA gives me miles, flying JAL gives me only a nice feeling. What to do?
This past Saturday, I flew ANA from Hong Kong to Tokyo.
Saturday, October 28, 2006
How can our little ratings race compare to that between two notables like Kim Cameron and Kim Jong Il?
One of them has the power to:
- destabilize global politics.
- cause untold damage to the world's financial markets.
- create fear and stress amongst the civilian population.
The other model I availed myself of is "pre-emptive translation", get an English/Cantonese speaking doorman or concierge to write out the destination, and then present this 'token' to the driver when getting into the cab.
In a city where any given cabbie might speak any of a number of languages (like Ottawa), the second model would suffer as it implies the translation service (the doorman) is able to anticipate the necessary "token format". Maybe cabbies could advertise their language capabilities metadata on a flag above their ride so that the translation service wouldn't have to guess.
Of course, it's easiest if everybody just speaks Canadian English eh.
Speaking of translation assistance, somebody obviously had to have helped with this. The polite beginning was a giveaway.
Wednesday, October 25, 2006
<?xml version="1.0" encoding="UTF-8"?>
<xs:element name="Letter" type="LetterType"/>
<xs:attribute name="value" type="xs:string" use="required"/>
<xs:attribute name="uppercase" type="xs:boolean" use="optional"/>
<xs:element name="Punctuation" type="PunctuationType"/>
<xs:attribute name="value" type="xs:string" use="required"/>
<xs:element name="Spec" type="SpecType"/>
<xs:choice minOccurs="10" maxOccurs="unbounded">
Monday, October 23, 2006
I tried to hand him some money but he wouldn't accept it.
I felt I had to give something in return so I told him I was helping to define an identity management infrastructure that would benefit all humanity (well at least those with internet access).
Despite the language issue, I really think he understood. When I said 'user-centric' he said 'Like in Dick's video?'
When I replied 'And more', he touched my arm and said "Gunga galunga... gunga, gunga-galunga".
Which is nice.
Sunday, October 22, 2006
This sequence, in which the user takes temporary control over their luggage in between two separate secure channels (during which the luggage is stored safely in the holds of the two respective airplanes), feels much like the protocol flows that have identity tokens flowing through the browser. Both introduce a gap into the security context.
Additionally, if upon arriving at your destination, your checked luggage doesn't - the baggage claim receipt plays (in a sense) the role of a SAML artifact for the luggage itself. Like the SAML Artifact Binding, you arrive without the 'token' but then present a claim ticket that facilitates its retrieval - allowing the the luggage to be eventually (hopefully) delivered to the relevant address.
In-seat Personal Video Systems act as an effective load balancing system for airplane washrooms. When every passenger can choose their entertainment options, you don't get the rush for the facilities that happens when a movie shown on the big screen ends. If passengers could serve themselves their meals from a buffet the load would be smoothed out even more.
Air Canada has outfitted bulkhead seats with airbags. Fitted into the seat belts of those seats, they are designed to compensate for the lack of a tray table in front of you (into which your head would otherwise slam)
I saw the sign below at Ottawa Airport.
Quite the relief as I had been worried about the permanence of that particular piece of nondescript, beige-coloured, industrial carpet
I enjoy watching people come into an airplane and start to peer closely at the number above each row of seats. I think the thought process is something like 'OK, let's see, I'm in row 42 - 2, 3, 4 let me just check my boarding pass, yup, still 42 - 5, 6, 7. 8, oh wait, did I miss 42? Nope, still good - 9, 10, 11, check boarding pass again, 12, 13 .......39, 40, 41, 42, 43, 44, hey just a sec, ....
Flying from YYZ to HKG, missed the North Pole by 120 miles.
As an experiment, turned on my GPS during the flight. Clocked at 850 km/h. That's going to bump up my weekly running total distance and average speed nicely.
Saturday, October 21, 2006
- the e-card - the leader in what could be a series of similar efforts by other companies - is part of a feature called Cardspace.
- if the user wants to buy a product from a website, the website simply sends payment information to Cardspace. The Cardpace program forwards that to the bank.
- All personal data are kept on the home computer - it's never catalogued in a company server
- Microsoft said it's planning on making the e-cards portable so that people can use them from any computer on which they may be working
- Ontario's privacy commissioner, Anne Cavoukian, said the situation has led to "password fatigue"
- Ms Cavoukian spoke about the upcoming release of the new technology at the International Association of Privacy Professionals conference in Toronto this week
- Other companies are creating similar programs
Friday, October 20, 2006
Well that's nice but right now I'd much rather have the privacy of one of those fully-reclining bubble first-class seats (I'd even accept a couple of thin blankets covering my stretched out form on 2-3 side-by-side economy seats).
Knowing Conor will be comfortable will be some consolation.
When I first heard this I expected I'd be able to log-into my Technorati account with an OpenID but it seems not - they are using OpenID for the use case (as I understand it) for which it was originally designed, i.e. to allow a user to lay claim to some URL.
Blogger doesn't support OpenID so I wasn't able to test the mechanism but it worked for David Recordon.
Unrelated, www.openid.com =/= openid.net (unless OpenID is expanding into insect identity use cases?)
Thursday, October 19, 2006
If the user is once (or twice removed) from the provider trying to determine if the user is 'OK with this', things are trickier.
As an example, if a user SSOs into an online movie rental provider (MRP), the MRP might want to obtain the user's 'Favourite Genres' from other provider (FGP) in order to customize the selections they are displayed. The MRP can ask the FGP but, if the FGP needs clarification from the user before releasing the identity, they're all the way over at the MRP and so isn't available for interaction to clarify their wishes. What to do?
The Liberty Alliance ID-Web Services Framework defines a number of related mechanisms designed to address this issue:
- Allow the FGP to respond to the MRP request and indicate 'Sorry, I need to talk to the user before I can give that out. Please direct their user agent to this address so I can get the clarification I need." After the user's browser is directed over to the FGP, they can be authenticated and asked for their consent to the release of identity. They can then be directed back to the MRP- which can then resend its original request for the user's preferred genres, this time with an expectation of success.
- Allow the MRP to indicate within its request that it is willing to pose any consent requests the FGP might have back to the user. If the FGP does need to interact with the user, it sends the questions it has back to the MRP. As the MRP already has a session with the user, it can pose the question "FGP would like to know 'Are you OK with this?'". After the user answers, the MRP returns the approval (or not) back to the FGP as input to its authorization decision. As it is the MRP that is asking for the attributes in question, having them also attest that the user is 'OK with it' may not be appropriate in all situations.
- Like #2 above, have the FGP send a request for interaction with the user , but to a dedicated Interaction Provider (IP) rather than the MRP itself. The IP, on receiving this request from the FGP, would use whatever channels it had available (e.g. SMS, email, IM, etc) to contact the user and pose the consent question. If the user approved, the IP would send that response back to the FGP, which would then process the original request from MRP appropriately (approve/deny).
Update: Pete comments:
Why is the obvious 4th option missing?Fundamentally, ID-WSF is a 'web service framework' and so the preferred channel for provider communication is a direct SOAP call rather than a browser-mediated front-channel. Justification includes:
Send the user to FGP straight away, the FGP sends the user back with the request information, if the FGP requires something over the MRPs say so it has its interaction point right there.
- the assumption that MRP will potentially be asking FGP for the list over and over (into the future) and so any efficiencies gained by using a front-channel redirect (in that consent can be obtained that first time) are outweighed by the advantages of using a direct call when consent needn't be obtained
- A server to server web services protocol can be much richer from a functionality point of view as well as a security point of view.
- related to the above, many of these messages are too big to reliably be handled via redirects and in many cases too big for browser-post
- user experience and speed implications of the redirects
- the limitations of the browser as a secure intermediary
- the relevance of use cases where the user in question isn't even online, much less visiting the MRP
The great uncertainty (some doubt and a tiny bit of fear) I've been experiencing for the last little while has been resolved - the identity system I will use to avail myself of my province's online services appears to have been decided.
Update: $@^&$*# I knew it was too good to be true - the irony was just too sweet. www.gov.on.ca does work in Firefox. So, the para below is moot.
Give us a land of lakes
and a land of snow
And we will build Ontario
A place to stand, a place to grow
Wednesday, October 18, 2006
He recommends a 1-10-1 rule should you fall into icy water. 1 minute to get your breathing under control before attempting to get out, 10 minutes of useful efforts at escape before you run out of energy, and then finally 1 hour before your heart stops. How cheery.
Is there a comparable rule for identity theft victims?
- 1 hour of uncomfortable questioning the wisdom of giving your password to that nice person from 'tech support';
- 2 days spent with bank customer support determining if they did indeed contact you;
- 3 years to deal with the consequences.
Unrelated, how serious a breach of blog etiquette is it to ask somebody (making vague and in no way binding committments with respect to Hong Kong Ultimate tournament discs as incentive) to be added to such a list? I'm asking for no particular reason of course.
In the paper we proposed a taxonomy of privacy language types for identity services, examined the relevance of various XML-based policy languages for supporting these different aspects, and considered how the Liberty Alliance's ID-WSF <UsageDirectives> SOAP Header can be used to move such policies around.
Robin's slides are available here.
Tuesday, October 17, 2006
Pat and I are also connected on LinkedIn. And AIM. And through the social mechanisms of the Liberty Alliance Members Site.
If he and I fall out because of a late night whiskey drinking session in some Hong Kong opium den, it will take a not insignificant amount of work for both of us to eradicate the electronic manifestation of the relationship.
If only there were technologies by which a social relationship, once established, could be leveraged across multiple applications.
Pat appears to be big into The Clash. I've got this mental image of him in tight leather pants that I'd appreciate help in dislodging.
Update: Pat reminded me that in certain parts of the world (those lacking air conditioning mostly), 'pants' refers to undergarments. This little tid-bit of localization has only exascerbated my mental imagery issue.
Most people associate the <AuthnConext> element with capturing the specifics of how the user authenticated to the IDP, e.g. either using a password or (more meaningfully for maximizing the value of the SSO) some stronger authentication technology like a OTP or smartcard. This information can be important, all else being equal, an assertion issued after a smartcard authentication to the IDP is likely 'better' (from the SPs point of view) than one issued based on a password.
But Authentication Context is far more powerful than merely describing this aspect of the authentication (SAML 1.0 had an AuthnMethod mechanism that would have sufficed for this). Authentication Context gives IDPs and SPs a language to discuss many other aspects of the context of the authentication, including:
- The initial user identification mechanisms (for example, face-to-face, online, shared secret)
- The mechanisms for minimizing compromise of credentials (for example, credential renewal frequency, client-side key generation)
- The mechanisms for storing and protecting credentials (for example, smartcard, password rules)
- The authentication mechanism or method (for example, password, certificate-based SSL)
For instance, the mobile oriented classes, in addition to distinguishing whether the user authenticated to the IDP with one or two factors, also distinguishes whether the IDP (likely the operator) has an account (and contract) for the user in question or whether the user is unregistered (using pay as you go cards etc). The former, with the implied opportunity for physical verification of identity that might be unavailable for a pay as you go user, might present a very different risk profile for an SP considering accepting an identity assertion from the operator IDP.
I've seen some object to the idea of Authentication Context, the view seeming to be 'Why doesn't the SP just trust the IDP to do the right thing?' If the IDP can only do one 'right thing', then that's fine. If your IDP does password authentication only and your use cases don't demand (or your security doesn't warrant) anything beyond, then all actors can be on the same page without any special mechanisms. If however the IDP has more options, then in many cases the SP will both need to be able to express its requirements of such options, and be informed as to the results.
The article points out that there are different ways of calculating the risk associated with flying.
You can calculate the risk of flying by:I can imagine similar variations in how an SP might determine the risk associated with accepting identity assertions from IDPs.
1. Dividing the number of people who die into the total number of people, which gives you the risk for the average person;
2. Dividing the number of victims into the number of total flights all passengers took, which gives the risk per flight;
3. Dividing the number of victims into the total number of miles all of them flew, which gives you the risk per mile.
For some SP's the analogous "risk fraction" might be dividing the number of dollars lost (as a result of damage to reputation from fraud, legal costs, etc) into the dollars gained (from increased user retention etc); for other SPs dividing the number of users lost through identity portability over the number of users kept/added might be a more useful metric. An SP that does lots of low value transactions would probably have a different view of risk than another that engages in fewer higher-value transactions.
I bet there is an MBA thesis in here.
The article points out that the majority of flying risk comes from take-offs and landing. For identity, it's authentication that skews the distribution.
Monday, October 16, 2006
Last.fm allows the songs that you play to be recorded. You can download plug-ins for iTunes etc that record the songs you play and then upload the list to Last.fm. You can then embed this list as a widget in your blog so that the whole world (or at least that fraction that reads your blog) can learn about your Barry Manilow problem.
Pandora is a (separate from Last.fm) streaming music service. You might want the songs that you listened to through Pandora to also be recorded into your Plast.fm playlist (in order to de-emphasize the show tunes etc that would otherwise swamp out anything else). Last.fm has an API to allow other applications to add songs but it requires authentication.
The easiest solution would be to give your Last.fm account details (username and password) to Pandora and then have Pandora use the Last.fm API to push your played songs into your playlist there. A variation on this model is to give your credentials to a 3rd party, and have them do the integration between Pandora and Last.fm. Either way, you're handing out your password. This is of course the current default mash-up model.
The other available alternative is to keep your credentials close, and rely on an extended client to authenticate to the Last.fm API and to then push your Pandora songs. Of course, you have to pretty much take it on faith that the extension isn't sharing your password inappropriately (protestations to the contrary notwithstanding)
Everything sent by this extension goes directly to the Last.fm servers and nowhere elseOf course, the best solution would be for Last.fm to accept a security token attesting to my identity in its API and not require the password itself.
You could build some really cool social apps with a 'Playlist Service' defined on top of Liberty Alliance ID-WSF. I'd love to be able to define things like 'If 2 or more friends of mine play a certain song (that I haven't listened to) within the last month, put it on my "Consider listening to" list'. I find that the challenge for me with music these days is how to get exposed to new material that I'm likely to like. I want a system that automates the e-mails I currently receive from friends with subject lines like 'you should give this a try'.
Nobody has yet defined such a service interface for music playlists (AFAIK) but all the social, privacy, and security plumbing is already in place in ID-WSF.
E-Loan Inc. customers worried about safeguards when data get outsourced to India can choose to have loan applications processed domestically, though loans in such cases would take two additional days to close.Not only is the customer given options for controlling how/where their data is processed, but importantly they are explained the consequences of the choices they make.
The same idea as demonstrated in this Flash.
I wonder if those who opt for local-processing are making an informed decision, i.e. basing their choice based on objective analysis and not some xenophobic gut reaction. I expect E-Loan doesn't disclose which data centers, US or Indian, have better records for employee retention - always a factor in privacy goodness.
2-day difference in loan processing times, hmmm. North America will never be able to compete until we get computers that are equally as fast as those being used in Asia.
Friday, October 13, 2006
At first glance I was worried about the privacy implications of OpTag but I'm reassured by the stated motivation
Oh well that sounds just fine.
Up to 5% of aircraft departure delays are caused by late passengers or late bags at the gate, and the impact of this in missed slots and subsequent costs will increase as the number of flights increases. The OpTag system will enable the immediate location of checked-in passengers who are either missing or late, and thus reduce passenger-induced delays and speed up aircraft turn around.
Oh wait, perhaps there is an alternative. Why not forget the privacy-invasive necklaces and just pull back from the gate at the designated time. If Billy-Jim loses track of time in the 'Some Name Here Brewing Company', bad luck for him. He can catch the next flight to the Shriner's convention.
And, according to the European Institute For E-Learning (which I believe the ELgg activity is part of) EIfEL, they're working on integrating Liberty Alliance People Service for the social layer.
Users establish personal digital identities and connect with other people, collaborate with them and discover new resources through their connections. Plugins allow users on different social networks to collaborate, and provide specific functionality for tasks like project management, mobile browsing and collaboration through user-controlled wikis.The emerging ELgg support for Liberty Alliance ID-WSF components expands on the existing support for ID-FF (as well as OpenID it would seem).
Organizing education sessions in pubs should serve as an example to the industry. It definitely motivates me to learn more about ePortfolios and the potential relevance of ID-WSF to sharing CV information.
But, unless you were able to use an existing script created for a well-known page, or were willing to get in and edit a script by hand to create or tailor, GreaseMonkey hasn't been particularly accessible to the masses.
Enter Platypus, another Firefix extension. Platypus is as a WYSIWYG editor for creating GreaseMonkey scripts. After installing both extensions, when visiting a page that you want to customize (e.g. remove some screen components, rearrange components, etc), you use the Platypus toolbar
to make your desired changes, and then 'Save' those changes to a GreaseMonkey script. The next time you visit that same page it will appear as you customized.
As an experiment, I used Platypus to customize the login page at Sxore (chosen because it, in its unmodified form of supporting multiple identity systems/options, demonstrates the potential for user confusion about identity options). I removed all screen elements but the 'Log in with OpenId' option to remove some of this confusion. The result is below.
Irrelevant (for me) options are removed. Others would tailor to suit their tastes.
Beyond removing some visual identity clutter, allowing users to tailor the identity components of pages would act as a poor-man's anti-phishing mechanism. If I were to visit a phish site purporting to be Sxore, the GreaseMonkey script would not kick-in and I'd see the default interface, possibly clueing me into alertness.
The platypus belongs to the monotreme family of mammals, distinguished from other mammals by the fact that in the monotremes a single opening (the cloaca) serves for urination, defecation, and reproduction. Perhaps then the relevance of Platypus's name to identity is to hilite the danger of overloading a single interface.
Monotreme's are also characterized by the fact that females lactate from openings in their skin as opposed to defined nipples. No analogy comes to mind.
Thursday, October 12, 2006
The fact that it ignores other standards may be true but one of the design goals is to do for data transfer what OpenID has done for single sign-on; light-weight, simple, easy-to-implement, etc. Think of the proposal as a best-of-breed of those heavier technologies.To my mind, best-of-breed implies that the old and new are still of the same breed. But, were OpenID to continue down this road, DTP and the existing XML-based messaging stack would be completely separate species with no chance of successful intermixing.
To Do: make some analogy on how whippets and St. Bernards, bred for very different applications over generations of artificial selection, can still interbreed. ...
The same can be said of OpenID as it relates to SAML ...I agree.
Regardless, a comment from Grant Monroe on my original post indicates that the next rev of DTP will ditch XML completely and instead build on MIME and S/MIME. So, it seems this particular concern is moot.
Wednesday, October 11, 2006
Deafening email silence from most conscripts followed.
I did receive the following from one inventive friend.
Thank-you for your email. I will be out of the office until February 18 2007. I will reply upon my return.It might have worked if the reply hadn't taken 3 hours. If you're going to run a mock MITM attack you have to be faster than that.
The above heat-map graphic is very informative. It tells me a number of things about my blog and how people interact with it:
- I was more interesting a year ago than I am currently.
- There is nothing more pathetic than a cold heat-map.
- My profile has not changed since I last checked
Now, if the Air Canada booking system were to receive an assertion as to a passenger's size and strength from a trustworthy source, then the need for a visual once-over from the agent would disappear. If Dr Jones says you can lift the exit door, that would be good enough.
An advanced system could balance the plane based on weight, assign skinny people seats next to those with a tendency to spread beyond their allocated space, or put me right next to a chatty Grandmother with multiple photos of her family (oh wait that already happens).
Tuesday, October 10, 2006
These alternatives are admittedly somewhat obscure in the industry, little known specs like SOAP, WS-Addressing, WS-Security, XML Signature, and XML Encryption.
Fortunately there appears to be no duplication between this proposal and WML. Consequently, at least for mobile markup we don't have to worry about convergence. Bullet dodged here for sure.
Consequently, I'm really looking forward to being able to combine an upcoming trip to Hong Kong for a Liberty Alliance meeting with an Ultimate Frisbee tournament. The Hong Kong Ultimate Players Association is hosting the Hong Kong Pan-Asian Ultimate Tournament October 28-29 in Aberdeen Stadium.
I noticed that the Hong Kong league site would require me to create an account in order to post to the forums or comment. Maybe I can convince the Liberty Alliance to pay for my tourney fees and a disc if I can make a sale?
Sites considering hiring consultants & lawyers could save themselves some money by simply agreeing to abide by Ultimates' Spirit of the Game' guidelines
1. The golden rule: treat others as you would want to be treated.I try to follow #3 in all aspects of my life.
2. Control: SOTG takes real effort.
3. Heckling and taunting are different.
4. SOTG is compatible with championship play.
5. Don't "give as you got."
7. When you do the right thing, people notice.
8. Be generous with praise.
9. Impressions linger.
10. Have fun.
1) Step 3 is as follows:
3: Consumer associates with server (option 1) - In order to communicate securely with the server, the consumer gets an association with the server discovered in step 2, using an existing association if it is available, otherwise visiting the server and using Diffie Hellman to negotiate a shared secret with which to sign communication.As written here, the consumer uses an existing association in order to get an association? I believe the intent of the above para is something more like
If necessary, the consumer establishes an association with the server discovered in step 2. If the consumer already has an association with the server, or is capable of dumb-mode only, it MAY skip this step.2) Step 4 indicates
The OpenID server URL accepts a query, containing all the information the server needs to check the user's identity and redirect the user back to the consumer. The server checks the authentication of the user. If the user is signed in (has an auth cookie) and has already authorized sending their identity to the consumer, step 5 may be skipped.and Step 5 includes
The user authenticates to the server with a cookie or a username and password, and the server asks the user for permission to send their identity information to the consumer.Both steps refer to the user authenticating to the server and the result is confusing. I think the intent was more something like
Step 4 - user agent is redirected to server (along with information the server may need to direct the browser back to the consumer)
Step 5 - user authenticates to server, either with existing cookie or, if not present, with a password etc. At this point, the user is asked if they consent to their identity being sent to the consumer. If the user has already authorized identity being sent to the consumer, this previous consent declaration may be used.
From the original TechCrunch article on IMSafer came this line:
While multiple screen names can be tracked at home, the company is working on a tool to associate different screen names across school and home to notify parents.A not insignificant piece of SAML 2.0 deals with the establishment of connections between such disconnected accounts in order to facilitate subsequent identity-driven interactions, whether those transactions be SSO, attribute sharing, or 'dangerous chat language notification'.
If the child had two different IM handles or used different systems, then a connection could be established between them in the form of a persistent & opaque identifier (different from either IM name) to ensure that the appropriate parents can be confident that they are covering all "conversation bases". Likely better would be to establish multiple identifiers, one between each IM provider and IMSafer. SAML defines how these connections can be established, nothing about the specifics of how you build a notification system for dangerous phrases using these connections.
Build the system on Liberty Alliance ID-Web Services Framework and you get alot more - parents could specify their own favourite dangerous phrases for monitoring, use a People Service to manage the privileges for creating and managing accounts, and build on the WSF notification framework.
Kaliya then asks:
Who said anything about doing this without the knowledge of the kids? SAML could definitely be used in an underhanded way to establish the connections between IM accounts (just as IMSafer can be run in covert mode - the FAQ 'advises' parents to tell the kids it's installed). SAML can also be used in an open, privacy-respecting user-centric manner to do the same (like the multiple identifier model above in which the kids could be involved in the establishment of the identifiers and so be completely 'in the loop'.) Is there any identity system that we can't say the same thing about?
Isn’t the whole point of the Laws of Identity that people should not have there identifiers aggregated across contexts without their knowledge.
With respect to privacy, it seems there are more fundamental issues. From the IMSafer FAQ:
How do you know what IM accounts to monitor?Now that's informed consent!
When a user on a computer onto which you have installed the IMSafer client software uses IM, we automatically detect it and start monitoring the account. You don't have to do anything. How nice is that?
Friday, October 06, 2006
Something like 'rolling' or 'stairway' or 'champion'. Valid hits would be swamped by the noise from the more common alternatives - you can't download what you can't find.
I have absolutely no idea what made me think of this.
When searching for 'friends', no longer will you need to describe the desired physical characteristics, you'll just sketch them out.
A tool for drawing circles would be a significant usability boon for many men.
My analysis of the results when searching on identity-related terms (raw data below)
- Ideally, the numbers for identity & privacy wouldn't be different by an order of magnitude.
- Everybody always goes on about how much Scott Cantor has does for SAML but he's only got 50 more hits than me!
- There are far fewer 'stupid users' than we might otherwise have assumed.
- Similar to 'existentialism', 'user-centric' doesn't appear to manifest itself in code (this one was a shocker to me).
- Many American developers use snippets of the Declaration of Independence as a test string.
identity ~ 301,000
privacy ~ 57,000
shib - 31,500
liberty ~ 28,600
SAML ~ 14,000
OpenID ~ 10,000
pseudonym - 6,000
liberty alliance ~ 5000
ID-FF ~ 100
stupid user ~ 100
YADIS ~ 100
user-centric ~ 100
existentialism ~ 50
scott cantor ~ 50
WS-Federation ~ 7
paul madsen ~ 0
Thursday, October 05, 2006
Given the danger of mismatch, would anybody ever be willing to take this assertion on face value and not directly verify my blood type? If I told the nurse my type when I went in to donate she'd smile at me and say "That's nice dear, but let's check anyways shall we?". The claim as to type on the card might as well be similarly self-asserted.
So, what purpose does the blood type assertion on the card serve?
Maybe it's some sort of confirmation method for the token. If my tested type matches that on the card then that's some evidence that I am indeed the valid owner of that card (further evidence probably provided by separate identification).
Apparently, only 6% of the Canadian population has my blood type. It's like I'm like an online banking site with exclusive criteria for which IDPs I'm willing to accept assertions from. In this case I think I'd prefer to be more like some "universal recipient" blog site.
Update: Anon's comment makes sense. The blood type is there for me, and not for the 'relying party'. Is there an electronic analogy? Perhaps a friendly name on a long-lived token stored on a smart device in order to remind the user of its applicability?
Update 2: Pam trumps my 6% with her 2%. Big deal, it's not like I had any sort of emotional investment in my relative uniqueness .... I do think I'll demand a recount though. Maybe the chads were hanging.
KCP: I had the feeling at Digital ID World that some people are using the term user-centric to describe sort of the next big thing after federation, implying that federation was yesterday. Doesn’t that worry you?
Durand: That’s my point. However, I understand the marketing aspect of it. Its about creating a new category and dominating it and attempting to disconnect it from the prior category. That’s all happening on the marketing front. I just don’t want the technicians and customers to buy into the marketing jargon that’s been fairly self-serving for those that are looking to create a new sandbox to sell from. The reality is that when we’re talking about identity you can’t have a break in the chain. Identity transactions are going to be chained together and most of them either start or end in a business, so you can’t separate the business infrastructure from the consumer infrastructure in terms of the ability to do business with the business. It’s just one big continuum and if we need to add capabilities such as privacy and user mediation in the transaction, then so be it, but that’s not something completely separate.
YASNs would benefit from something comparable that showed the calculated reputation of the referenced individual.
I think I'll start collecting icons in anticipation. Here's the first in my collection.
It's from these documents that the Technical Expert Group worked (and often cursed), the use cases and derived requirements guiding us in the development of protocol specifications that met the requirements. So, for instance, you can see a 1-to-1 correspondence between the sections of the WSF 2.0 MRD and the spec'd out People Service and Subscription functionality.
The MRDs make for interesting reading. One use case from the WSF 1.0 MRD stands out for me. In Section 184.108.40.206:
An SP may wish to provide basic personalization services to its visitors/customers without requiring them to have an account at the SP or even identify themselves at the SP. Hence a user may anonymously share certain attributes with such SPs. For example, an SP may not require any sign-in by the user on their initial visits. Nor does the SP require the user to have an account at the SP. Yet, the SP may want to provide basic personalization based on attributes such as preferred language, gender, geo-location, time zone, etc. The user, when visiting the SP, may see content personalized to the user's preferences. Such personalization is the value-add provided by such SPs to attract customers and increase airtime and online time usage.This use case, the derived requirements, and the resultant support in WSF may not fit the image of "hard-coded federations" that some seem to have about the Liberty Alliance's architecture.
Note the anonymity is intended to protect the identity of the user. The SP never gets an identifier for the user, not even a repeatable pseudonym. Therefore, even if the user re-visits the SP a minute later, the SP would not know if it is the previous user visiting again. However, such anonymity (privacy) does not exist if the user willingly gives the permission to anonymously share his/her PII (Personally Identifiable Information) such as social security numbers, driver's licenses, passport numbers, etc.
Wednesday, October 04, 2006
The 'SimpleSign' in the name refers to the binding's use of a (if signatures are used at all) 'sign the blob' model for message integrity and authentication rather than using XML Signature (as is the case in the existing SAML HTTP POST Binding).
XML Signature is part of the 'weightiness' that some associate with SAML. The 'un-wanted pounds' that SAML supposedly carries are seen as an artifact of the formative years it spent in an enterprise cafeteria eating subsidized lasagna and drinking watered-down Coke.
Even with its love-handles, SAML has had no trouble getting dates. But I think of this binding as SAML flexing a bit, showing off a new leaner bod, and getting ready for new relationship opportunities (such as
SAMLv2 Lightweight Web Browser SSO Profile). And of course, the tall-n-husky SAML is still around as well, should you be looking for a more secure relationship.
I guess if I was married to someone known as a 'she-wolf' I might be looking to stay over the Saturday night whenever possible as well.
During his reign, Edward II lodged at more than 4,000 places in England.
Details of what this release is about are available here.
I'm doing a webinar on WSF 2.0 along with Ericsson's Carolina Canales-Valenzuela (some other long name here) tomorrow. Carolina will be the one with the charming accent who doesn't end every sentence with 'eh'.
InternetNews thinks it took a long time. Believe me when I say it felt even longer from this side of the PDFs.
Lawyer 1: My client is willing to provide first name.
Lawyer 2: C'mon, that would be like milking the horse before the cow, my client absolutely needs email address.
Lawyer 1: What if we threw in postal code?
Lawyer 2: For home address? or shipping address?
Lawyer 1: My client would be willing to give both if you got rid of the ridiculous request for their sexual preference.
Lawyer 2: It's not ridiculous, my client needs that information before deciding whether or not to proceed with this relationship.
Lawyer 1: C'mon, we're in a gay bar, get it from the context!
Lawyer 2: Ok, ok, we can bend on this. But not on email address - that's a must have.
Lawyer 1: (after whispering with client) Ok, here you go.
Lawyer 2: What the &$%@# is this? I said we wanted an email address!
Lawyer 1: It's a URI. It's like an email address but protects my client's privacy. Your client would go that web page and leave a message.
Lawyer 2: Where did you learn your law? I didn't say we wanted something 'like' an email address. I said we needed 'an' email address. Jeez, go read PIPEDA before wasting our time like this (packing up papers).
Lawyer 1: C'mon, sit down and relax. My client will provide her real address on the condition that it not be shared with anybody else and thrown away after a week (whispering with client) Oh, wait, clarification, not shared with anybody ugly.
Lawyer 2: (after whispering with client) Would writing it on the bathroom wall be considered acceptable usage?
Lawyer 1: (more whispering) My client says yes, but only in a small font.
So it's an end-run around sites that don't themselves provide APIs. You use Dapper to scrape their pages and effectively create your own API. The key difference is that you define what gets scraped rather than somebody else.
As an example, I created a 'Dapp' from this blog, using the Dapper interface to specify that I wanted only the post titles and following metadata (e.g. posted by, # of comments etc) scraped. I chose to have XML as the output format and the result is here. No programming necessary (although some would be required in order to use the 'feed').
Inherent to screen-scraping, it's fragile - as soon as I change the blog template, the Dapp could break. I also wonder how long the window of opportunity will remain open - if Blogger had an API and gave me (or others) control over what data was relevant then the need for Dapper disappears.
Tuesday, October 03, 2006
From that article, the following caught my eye:
While multiple screen names can be tracked at home, the company is working on a tool to associate different screen names across school and home to notify parents.If only there were technology to help.
Eve has uploaded a new version of her excellent deck to the OASIS SSTC public page.
It's available in both OpenOffice document format and PDF (the source format is supposed to have some animations but I couldn't see them).
For me, it's the graphics that steal the show (isn't there some saying about graphics and their worth etc?), especially the callouts on the various XML structures.
Cardspace would allow a Zuner (can I trademark this?) to specify which identity aspects get advertised in which contexts. I might show a different set of songs in an after hours (I hear they can be open till midnight!) club than I would in an airport terminal. Other Zuners could define ACLs for their playlists and songs in terms of the required identity characteristics of potential recipients (e.g. if you advertise that you like 'Broadway Show Tunes' then you should just keep searching).
I'd be interested to hear Microsoft's story on how they see Cardspace working in a social world.
A photo site dedicated to her son, and her desire to inform far flung friends and family of it's existence and location, has forced her to deal (albeit from a distance) with the technology she so successfully avoided up till now.
Of course she doesn't have email, so the communication channel by which she broadcasts the above address is good old Canada Post. Consequently, there have been many a phone call along the lines of:
Mom: Can I get that address for Jamie's photos again?
Me: Sure, it's 'w w w'
Me: doesn't matter , but no, no capitals.
Mom: OK, 'www'
Me: 'dot flickr dot com'
Mom: Got it
Me: Now a line starting from bottom left and ending top right
Me: 'photos' and another line like above
Me: 'jamiemurraylife' and that's it
Mom: Got it. Any dot at the end?
Me: Nope. Now it doesn't change so you could write it down and save it for next time
Mom: Oh, I'd probably just lose it. I'll just call you back.
Me: Righto. Talk to you tomorrow.
Using the POTS to communicate a web address for snail mail forwarding. Now that's convergence.
Monday, October 02, 2006
Patrick reintroduces his 'passive' and 'active' distinction, expressing the varying abilities of clients for enforcing the user's wishes for identity sharing (and probably other identity functions like IDP discovery too).
One issue. Patrick writes
The caveat here is that active federation implies that the user is an active participant in the flow of identity (if not necessarily aware of it because of stored privacy policies). So, active federation requires that the user be 'online' (e.g. be sitting at their desk, looking at their phone, or having inserted their USB dongle into an airport kiosk).
I would argue that active federation is superior to passive federation when the requirements of user-centricity are to give the user the ability to independently enforce control and privacy stuff.
Lots of use-cases have the users online so that their client can actively mediate their identity flow, lots of others don't.
This pic shows Whobar in action at Sxore.
I guess the user would see the same interface at any other site that implemented Whobar.
Note: the use of 'Homesite' on the left, while perhaps appropriate for Sxore, seems to tie it too closely to Sxip for the general case? I wonder if this is configurable?
The above pic hilites the usability challenge of how to present log-in and/or registration options to a user. I'm no UI designer but have to question whether the above is optimal. As the number of options for logging-in grows, and the opportunity for confused users grows accordingly, maybe we need to separate out the possibility of registration, rather than intermixing the two as the above does?
Whatever does turn out to be the best (in the sense of minimizing user confusion) interaction solution, the Whobar model could make practical the reproduction of that sequence across sites.
It's the 'PASSWORD' as authentication context that confuses me.
I didn't authenticate to the IDP with a password, I did so with Cardspace. More precisely, I authenticated to the IDP (acting as a Cardspace RP) by proving I had a key through an XML-Signature. So, strictly speaking, the appropriate SAML Authentication Context class should be 'XML Signature'.
A Cardspace user will sometimes be required to authenticate with a pin or similar to a local key store (and so it could be conceivable that there would be a password in the mix). In such cases, just saying 'XML Signature' wouldn't adequately describe the authentication context. The options would appear to be to use combinations of existing AC class URIs or define new SAML AC class defined specific to Cardspace.
Update: Patrick Harding reminded me that Cardspace uses SAML 1.1 so doesn't have the full expressiveness of SAML 2.0's Authentication Context available. The conjecture is that Ping's Ashish Jain, because of this lack of expressiveness, had to fall back on 'password'.