Saturday, June 30, 2007

Gadget of the Week #12

My latest gadget is my new Dell Latitude D830. This replaces my older Dell Precision M70 and includes all the available bells and whistles. 2.4GHz Intel Core 2 Duo processor, 160GB 7200RPM drive, 4GB memory, 802-11a, g, and *n*, thumbprint reader, TPM, theoretically long battery power, and, of course, Windows Vista Ultimate. It is also thinner and lighter than my former laptop (and the Dell latitude D810's we have here).

The battery life is nowhere near the claimed "up to 9 hours" (which I didn't expect it to be, given how I use the system), but it does last about twice as long as my former laptop with the same relative workload -- about 5 hours now, easily going the entire cross-country flight either direction which I tested last week. With the old laptop I had to bring along a spare battery and used them both up pretty well on the same trips (or I brought a power adaptor).

This is a screamer of a system. About the only thing I can say negative about it is that it only came with the integrated graphics card (they did not offer an option for an enhanced graphics card at the time I ordered -- they do now, but there doesn't seem to be an option to add it to an existing system).

So far Microsoft Vista has been OK. There are some things I like (recent places). There are some things that I miss from Windows XP (hardware profiles being one of them). I'll make a separate report later on Vista as I get more used to it and figure out the tricks.

One other note of interest: While the system does have 4GB of memory installed, the fact that I am running a 32 bit operating system (Vista) which can only address a total of 4GB and has memory reserved for hardware i/o mapping (and some shared memory for the graphics card), the net amount of memory I have is around 3.4GB. Much lower than I thought. I'm thinking about making the jump to a 64 bit OS next time.

I did come like this close (picture me with my thumb and index finger almost touching) to jumping on the Macbook Pro bandwagon this time. I just couldn't give up the 1900x1200 display and the availability of real docking stations. Perhaps next time.

As part of this upgrade, I have done my part for the tech economy, choosing to buy/install upgraded versions of most of my like 5 billion utilities that I use. I guess Microsoft does cut a wide economic swath within the tech industry.

This is the first system upgrade in more than 2 years for me and it was worth it. I've been looking for a while and waited for Intel's Santa Rosa platform to become available.

Tags : / / / / / / / / /

Monday, June 25, 2007

You know you're an addict when....

Back in February, I wrote about getting hooked up with Where's George after finding a dollar bill in my change with some strange markings on it.

I quickly went out and got my stamps and started marking some bills.

Well, 4 months later (today), I am totally hooked on it. So far I have:

  • entered 727 bills worth a total of $5,177 (many of them are $1s).
  • gotten 44 hits on my bills, most of them coming in the last month or so (seems you need to build a certain amount of inertia before the hits start rolling in)
  • achieved a "George Score" of 637.36, placing me above the 85th percentile of Where's George users!!!!!
  • joined Friends of George where I get to pay extra money for the joy of entering my bills and tracking them :-).
  • started paying cash for many transactions that I had been paying with credit cards (so I can mark more bills and cause money to flow).
  • learned that it is better to mark small bills ($10s, $5s, and $1s) as they circulate alot more than $20s, $50s, and $100s which frequently just go to the bank awaiting a future withdrawal.
  • learned that it is better to get a stamp that needs little to no alignment (rather than the nice circular stamp I bought that goes around the treasury seal and must be aligned somewhat carefully -- taking way too much time when trying to stamp a stack of 100 or 200 $1s).

The real signs of my addiction:

  • The anticipation that I have when checking emails looking for hits.
  • The groans that I hear from my "friends" when I pull out my wad of marked bills trying to exchange them for unmarked bills in their pockets.

In any case, I still find it lots of fun and my friends seem to be mostly amused with my addiction. If you're interested, go get a stamp and enjoy marking your bills!

Tags : /

Sunday, June 24, 2007

Perhaps not so much Bashing...

Kim responds to my note about SAML Bashing:

...which is, by the way, absolutely NOT my intent. I’m simply trying to understand how SAML relates to linkability, as I am doing for all the other major identity technologies. I can’t take up all the points he raises, but encourage the reader to look at his piece…

Perhaps I reacted too negatively, but the analogy of some unknown clerk reaching into my pocket really irked me as that clearly isn't what happens and it appears to be written to instill unreasonable fear in an implementation of a browser-based SSO protocol.

I’m not criticizing or discussing the profile for an Enabled Client/Proxy. I was talking about SAML as we know it - in the mode which has been widely deployed in portals all over the world.

I think such analysis should be based upon the capabilities of the protocol and not about what some deployments have chosen to do within their environment (where they clearly felt that browser-based SSO meets their needs (and in many cases is mandated by the deployment scenario).

I think Conor is misunderstanding my intentions. I agree that with a completely trustworthy Identity Provider following best practices for end user privacy, Conor’s b) and c) above would apply. But we are looking at linkability precisely to judge the threats in the case that parties to identity transactions are NOT completely trustworthy (or are attacked in ways that undermine their trustworthiness.) So arguing that the identity provider will behave properly has nothing to do with what I am exploring: risk. I’ll try to build Conor’s concerns into my ongoing discussion.

I'm sure there's some misunderstanding here. I normally find that I agree with most of what Kim has to say and really respect his opinions.

As far as the trustworthiness is concerned, there's nothing that is completely trustworthy, not even if I make the decisions myself and hand-code the response messages from the keyboard (I'm sure that I will make mistakes of judgment and or typos).

I would ad that the same "attacked in ways that undermine their trustworthiness" applies to client implementations that try to enhance privacy protection. They too are subject to being attacked. Nothing is totally foolproof and I'm not sure which has more likelihood of successful attack, a service maintained under contractual agreements or open software systems in the hands of end user.

I certainly have chosen to put my money in a bank rather than store it under my mattress. Yes, the bank is more likely a target for a robbery, but they are legally obligated to maintain my funds, even if they are robbed. Similar decisions will be made by many people in the identity space (and yes, some out there will always keep their funds in their mattress).

Tags : / / / /

SAML Bashing

Kim writes about SAML's use of redirection protocols.. To start with, he forgets to mention a few important facts as part of his discussion:

  • SAML defines a profile for an Enabled Client/Proxy (ECP) which is an evolution of the Liberty Alliance's LECP protocol. This protocol does *NOT* involve redirection, but instead supports an intelligent client directed by the user driving SSO transactions (a similar model to that adopted by Cardspace).
  • The Browser-Profile that Kim is referring to is one written based upon a use case requirement that the profile work out-of-the-box on unmodified browsers. There is NO other possible solution that will work in this scenario that will protect the users credentials at the IdP.

That said, there are still several statements in Kim's analysis that I feel obligated to respond to. These include:

Note that all of this can occur without the user being aware that anything has happened or having to take any action. For example, the user might have a cookie that identifies her to her identity provider. Then if she is sent through steps 2) to 4), she will likely see nothing but a little flicker in her status bar as different addresses flash by. (This is why I often compare redirection to a world where, when you enter a store to buy something, the sales clerk reaches into your pocket, pulls out your wallet and debits your credit card without you knowing what is going on. (”Trust us.”)

First off, the user only see's nothing if a) they are already authenticated by the IdP, b) they have previously established a federation with the relying party, and c) they have told the IdP that they don't want to be notified when an SSO with this party takes place. I, for one, want things to work this way for me with providers that I trust (and yes, I do trust some providers). The inability to do this type of automatic operation is one of the shortcomings in Cardspace's implementation that I think will eventually be fixed. There is no need to have repeated confirmations of operations that I say may occur without my unnecessary participation.

Secondly, the analogy is way off base, trying to make this seem like I'm bing pick-pocketed by someone I don't know which Kim knows is absolutely not the case. A more proper analogy would be something along the lines of "I give one of my providers permission to reach into my bank account and withdraw money to pay my bill". I do this all the with providers I trust, such as my electric company, my telephone company (both wired and wireless) and may other companies.

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.

The IdP does not "see all". The IdP only sees that you have visited a particular relying party. It does not see what you do at the relying party. Knowing that I visited Amazon, is not the same thing as knowing what I looked at and/or purchased at Amazon.

Secondly, my choice of an IdP (as with most others) would be made based upon the appropriate policies and auditing capabilities at that IdP (just like I don't choose to use Johnny down the block as my bank, I choose a reputable firm and just as I would require the exact same policies and auditing in any client that I chose to use to act as my identity selector (yes, I have to *trust* Cardspace's or Credentica's implementation of policies just as I have to trust an IdP's).

In fact all versions of SAML include an “artifact” binding intended to facilitate this. The intention of this mechanism is that only a “handle” need be exchanged through the browser redirection channel, with the assumption that the IP and RP can then hook up and use the handle to “collaborate” about the user without her participation.

That isn't the intention at all. The intention, as Kim surely knows, is to pass a message by reference rather than by value. For the non-programmers in the audience, this means that I have a message that I need to send to the relying party (in this case that message contains an assertion, which can be big and complex and which has additional security requirements if passed through someone else's hands -- yes, the user can count as someone else). Instead off sending the token to the client to have the client then send it up to the relying party, I can send a small artifact that the relying party then presents to the IdP to get the token. The protocols explicitly define what the artifact is exchanged for -- it was never intended as, nor can it be used within the protocol definitions, as a general collaboration handle.

In many enterprise implementations, the artifact is used to allow the IdP to issue assertions to the Relying Party that don't need to be signed by the IdP. Clearly that isn't something I could do if the assertion was sent to the client (otherwise we'd be talking about how I took the token and edited it say I was Bill Gates when I sent it to his bank).

In considering the use cases for which SAML was designed, it is important to remember that redirection was not originally designed to put the “user at the center”, but rather was “intended for cases in which the SAML requester and responder need to communicate using an HTTP user agent… for example, if the communicating parties do not share a direct path of communication.” In other words, an IP/RP collaboration use case.

All SSO use cases (where one party authenticates a user and asserts an identity for that user at a relying party), redirection or not, would then be, by Kim's definition, an IdP/RP collaboration since the RP (Relying Party) is relying on the identity presented by the IdP. This has nothing to do with redirection or user involvement, or SAML in particular.

As Paul Masden reminded us in a recent comment, SAML 2.0 introduced a new element called RelayState that provides another means for synchronizing or exchanging information between the identity provider and the relying party; again, this demonstrates the great amount of trust a user must place in a SAML identity provider.

No. RelayState is designed for the RP to send information to itself, not the IdP, so that it can remember what the user was trying to access when the user is returned to the RP following a successful SSO operation. This is primarily used in the case where the RP is unable to set a cookie in the user's browser to remember that information. SAML even points out that as little as possible data should be included in the RelayState.

Paul's point in his comment was that if an RP used this incorrectly, they could leak information. The SAML specs contain exactly this caution.

I don't claim to say that SAML is the end-all for every use case. I do believe that we need to support multiple methods, some of which have different privacy implications. I also don't want some privacy weenies making life intolerable by the need for a confirmation of every thing that I already said it was OK to do. I do trust some of the parties that I interact with and want to be able to automate as much as I feel comfortable doing. I have no problem with the privacy weenie that wants to turn on the "let me approve everything" -- just don't force me to live that way as well.

Tags : / / / /

Saturday, June 23, 2007

You know you're late when...

Earlier this week, a computer glitch in United's sysytem caused hundreds of flights to be delayed or canceled. As my luck would have it, I was caught up in the delays. My flight was one of the last flights from San Francisco to Portland and was supposed to arrive at 11:59 that night. The arrival was delayed until around 2:15 AM and I didn't arrive at my hotel until after 3AM.

This was made worse by the fact that the previous night, my flight from Dulles to San Francisco was delayed by close to 3 1/2 hours by thunderstorms in the Dulles area (causing that 5 hour flight to be 8 1/2 hours as they didn't start the ground hold until we were already loaded onto the plane). Luckily, it was an internationally configured 777 and I had upgraded into business class, so at least it was comfortable.

I really knew I was late getting to my room at the hotel when I found that my USA Today for the next day was already delivered to the room.

Tags : / / / / / /

Wednesday, June 20, 2007

Updated Liberty Open Source

I've updated my Liberty ID-WSF Open Source implementation for both the server side and client side to include support for much of the the Advanced Client Provisioning Service specification.

The Advanced Client Technologies Overview is a good starting point for understanding what we're trying to do with the advanced client specs.

This release also includes some updates/fixes in the basis ID-WSF support.

Have fun!

Tags : / / / / / /

Tuesday, June 19, 2007

Concordia Schmordia

Next week, I will sit on a panel with Mike Jones of Microsoft and David Recordon of VeriSign. This panel will be a part of day spent on the subject of the Concordia Project.

One might ask, "What's Concordia?" and I, of course, would respond that that's a good question. My recollection (questionable, I know) of the sequence of how we got to where we are is as follows: The name originated in an earlier internal project at the Liberty Alliance where a number of us were examining potential paths towards convergence with the other technologies/protocols in the identity and web services space. Eve Maler can be blamed for the name as she brought it up given that Concordia was the Roman goddess of agreement, understanding, and marital harmony (not that any of us were getting married to each other) -- which, theoretically, is what convergence is about.

Anyway, as we moved forward on the project we eventually figured out that doing this ourselves would likely be a waste of time (why would anyone else listen to us). If we really wanted to talk about convergence we needed to bring the other players to the table. That led to more deep thinking (and perhaps a few visits to the neighborhood psychologist) and the eventual realization that many of the differences in the current approaches had to do with different use cases and with looking at the problem from different points of view.

So, here we are. Trying to organize an effort to bring together people interested in this space so that we can discuss our respective use cases and understand the problems that need to be solved. Liberty has tried to be very careful and very clear that this isn't a Liberty effort, but an industry effort (which Liberty supports). My hope is that we can use this common understanding to drive towards common protocols, features and capabilities so that those trying to use our stuff will have an easier time integrating with the rest of the world.

So come join us for the Concordia day at the Burton Catalyst Conference. At the minimum, it should be fun (though without Dick Hardt on the panel, I won't have someone to pick on :-)). The Concordia sessions are free, you just need to register here.

I look forward to seeing you all there!

Tags : / / / / / /

Monday, June 18, 2007

Business traveler Magazine

Partly from some of my writings here about my frequent trips on United, I was interviewed for this article in Business Traveler Magazine. Of course, the picture in the article was not a picture of me -- I think it might be Britta, there's some resemblance or, perhaps, that's just wishful thinking :-).

I should also point out that I wasn't the one to find the article. My sister, Theresa, was looking for our family web page (where I put up family photos) on google and she found the article and told me about it. Yes, I knew it might be coming at some point, but wasn't aware it was published. Now if I could only get a print copy to hang onto :-).

Tags : / / /

Annual Credit Reports

Not sure what brought this up now, but for some reason I thought to go get the "free" annual credit reports that we are entitled to here in the US at least once every year. I started with (the central clearing house setup by the 3 major credit reporting agencies) which asked me for the standard credit information (name, ssan, address, dob, etc.).

Once I entered that information they prompted me to select which of the 3 agencies I would like to review the report at (yes, you can select multiple). I selected all 3, but now, after thinking about it, perhaps I should have selected one only and rotated around the 3 agences throughout the year -- that way I can get a new checkup every 4 months rather than only one per year -- Oh well).

The web site then forwards you to each of the agencies where you will go through a different process at each of them to further verify your identity and get access to your credit report. My experience at each of them:

  • The first agency I was sent to was TransUnion where I had to create an account in order to get my report. I was then prompted for 2 account numbers (which I had to go find) and then the tried to upsell me a copy of my credit score for $7.95 before they would let me see my credit report. When I was done, the process had taken so $#@%ing long that my session at had expired and I had to start all over for the remaining two agencies.
  • On to Equifax, where they wanted to know which provider I opened an account with in 2005 and what was the payment (much easier to deal with), then they too wanted to upsell me my credit score for $7.95. No need to create an account. Got my report and printed it.
  • And, finally, Experian ((the last of the 3). This time, I went back to fairly quickly, so no need to re-enter all of my information. Experian started with verification of my ssan (last 4 digits), then they asked for verification of 2 accounts (who gave me a mortgage at a particular time and who gave me an auto loan at a different particular time) as well as the name of the county in which I live. Poof. I got to see my credit report. No need to create an account, no attempt to upsell me with the credit score (at least not as an intrusive click-through step -- it may have been there somewhere else on the page that I just ignored).

Moral of the story.... be tenacious and make them give you a copy of your report -- it IS free (as long as you don't fall for the upsell). Unless you think you have been a victim of identity theft, I would stagger the reports from each agency as many of them carry the same information as the others and this kind of gives you better coverage over the year (there's a lot someone can do in the 12 months between your annual reviews if you do all 3 at the same time).

Tags : / / / / / /

Monday, June 04, 2007

The Combo

Paul must be getting a little hard up for cash nowadays as he seems to be out moonlighting.