Strusts 1.1 RC1 is here.  Eclipse 2.1 RC1 is here.  Struts 1.1 final will ship "as soon as practical" according to their plan, and Eclipse 2.1 final will be released at end of March.

Eclipse 2.1 RC1 was built last evening and should be released soon.  Its has a few non-critical bugs but I am happy with it.  However, I suggest you wait for the Eclipse team to formally release it.  If you are impatient like me, the build is here.

[Update: RC1 was released and can be downloaded here.]

Also, Struts 1.1 RC1 is also close to being released.  Struts team is just going through last minute bug fixes and adjustments.  All the tests passed but there seems to be a lack of confidence in the test results.  I wish they would ramp up the pace.  Struts 1.1 has been in beta for damn too long.

"Authentication is more important than encryption.  [snip] Imagine a situation where Alice and Bob are using a secure communications channel to exchange data. Consider how much damage an eavesdropper could do if she could read all the traffic. Then think about how much damage Eve could do if she could modify the data being exchanged. In most situations, modifying data is a devastating attack, and does far more damage than merely reading it." [Bruce Schneier]

To me, validity of an assertion is as important as authentication.  Authentication has little value if the database is filled with invalid information.  It doesn't take much expertise to write a script that creates a million Hotmail accounts using randomly generated registration information, filling Hotmail user database with trash.  I can be Jack Frost living in Alaska or Don Juan living in Spain.  Garbage in, garbage out.  Authentication just means restricted access to garbage.

"The Liberty Alliance has published a White Paper (15 page PDF) about interoperability of Liberty with 3rd Party Identity Systems. Specifically, it talks about possible Liberty interactions with Passport, PingID, 3D-Secure, and Shibboleth." [Digital ID World]

Having participarted in the design and implementation of 3D-Secure and built several prototypes of Passport-enabled 3D-Secure ACS (run by card issuers), I was intrigued by this paper.  After reading the paper, I am disappointed because it is vague, trivializes critical issues, and avoids politically sensitive areas.

In its discussion of Passport, the paper describes a way to support Passport users in a Liberty domain and a way to support Liberty user within the Passport domain.  Level of discussion is, unfortnately, in the realm of possibility and not practicality.  I saw no incentives for Microsoft to integrate Passport with Liberty this way.

Its discussion of 3D-Secure was even worse, providing no answers beyond suggesting that two can co-exist by having merchants use Liberty to SSO and 3D-Secure as payment authorization.  As to other possibilities, it states:

"We believe it would be technically feasible to build a much deeper integration between the two protocols. However, the forces at play are commercial in nature, and involve the future development and adoption of both Liberty Identity Providers as well as the evolution and adoption of the 3-D Secure protocol. Therefore, we are reluctant to speculate as to whether any such deep integration will occur."

What is the point of SSO if customers have to use two different identities (one for Liberty and another for 3D-Secure) to buy something.  Isn't it more natural to have card issuers serve as Liberty Identity Providers?

At this point, I am disappointed by the lack of progress Liberty Alliance is making.  Liberty needs to move on and get real fast.

In his account of a massive power grid failure, Duncan Watts writes:

"The trouble with systems like the power grid is that they are built up of many components whose individual behavior is reasonable well understood but whose collective behavior, like that of football crowds and stock market investors, can be sometimes orderly and somtimes chaotic, confusing, and even destructive." – Six Degrees, Duncan Watts

I believe there are similarities between power grids and web service networks that could result in catastrophic cascades of unplanned collective behaviors.  We need to understand the problems better and build safety mechanisms in and around each nodes and, most importantly, key web service nodes such as those that bridges web service network clusters.  Web service orchestration problems are just the tip of the iceberg.  Who can claim to fully understand the problems of echos, oscillations, cascades, and bottlenecks inherent in a large network of web services?

XACML is now an OASIS Open Standard.  XACML, which stands for eXtensible Access Control Markup Language, is an XML spec for encoding information access policies.  XACML 1.0 was approved as of today (Feb. 18) and can be found here in Word format (PDF version is not yet available).  I plan to read it in detail and repot my findings here later.

Chris Heller informed me that PeopleSoft already implements a form of Time-Constrained Login.  Cool.  His post describes the feature in detail along with a screenshot.

 

This is an informal description of a possibly but unlikely new technique for secure authentication, designed to be combined with other technique such as passwords or smartcards to limit risk without additional cost other than possible inconvenience.

Identity authentication techniques may be divided into one of three categories:

1. something you know (password, pass phrase, PIN)
2. something you have (smartcard, hardware token)
3. something inherent to you (i.e. biometric)

Time-constrained login technique falls into the first category: valid login time and duration is something you know.  This technique is different from other knowledge-based techniques in that the required knowledge may be changed more frequently, possibly each time.  This is because, while people can't remember daily changing passwords, they can easily remember appointments.

With time-constrained login, authentication succeeds only at certain time.  A specialized form of time-constrained login is Time Capsule since it can only be opened after certain amount of time has passed.  Another example that is more appropriate for day to day use is CVS login restricted to 10-11am and 6-7pm.

Absolute time-constrained login uses specific time such as 1:35pm GMT or 7:12am PST.  Relative time-constrained login uses relative time such as 5 hours and 12 minutes from one or more event such as 'now' or 'after receiving SMS message containing the word 'Hollywood' from me'.  Time constraint can be specified by random, by schedule, or by combination (hours by schedule and minutes randomly).  Duration can be determined according to the need.  Specifying relative time constraint as one logs off may be useful to protect your workstation while going to a meeting or lunch.

This is all I have so far.  If you know of a similar techniques or have suggestions, please let me know.  If not — unlikely but possible – I may file an anti-patent if there are any patent lawyers interested in doing some pro bono work.  <g>

I woke up at dawn today realizing that I need to turn down righteous ass and turn up the path of least resistence.  I am done with complaining for  now, instead focusing on using what I got to build what I can.  Heck, if I can endure a personal back-massage from John Draper (aka Cap'n Crunch) to get a beta (alpha?) copy of Macintosh assembler back in 1984, I can wing it now.  Oh, boy that sure was an embarassing moment.