Last May at IIW I put together a demo that bootstrapped an ID-WSF 2.0 environment from OpenID using attribute exchange powered by an ID-WSF 2.0 enabled OpenID Provider. Over the past several months I have been working with a Community Interest Corporation (CIC) in the U.K. called Mydex, building out a proof of concept Volunteered Personal Information (VPI) system. VPI is a VRM concept currently being explored as a Liberty SIG. Part of this PoC is providing an Information Card (i-card) called a VPI Card.

The Proof of Concept

We kicked off work on the PoC in London at the end of November 2008. We decided that we would be developing a VPI system and demonstrating change of address. We then decided on the technologies that we would use for delivery. This was highly dependent on who was in the room, of course, and we all left feeling happy. The building blocks would be:

• The Mydex Personal Data Store (VPI)
• Several Sample RPs
• Azigo CardPress in ‘auditing card’ mode”
• Azigo Air ICM i-card Manager and i-card Selector
• Higgins i-card Service (RPPS)
• Conor Cahill’s ID-WSF 2.0 Server Toolkit
• openLiberty Wakame
• Custom developed ID-WSF/i-card clients

Sitting in London it felt like a lot of things to wire together, but completely doable, and beers later in the evening helped to bury the hatchet. Several months later we have a working PoC with more in it than originally intended and a clearer understanding of the role that ID-WSF will play. From the user perspective the PoC is relatively simple, as it should be:

• 1. User creates an account at Mydex and is offered a VPI card.
• 2. User downloads the card and installs it in the Azigo Air ICM (new version just released!)
• 3. User goes to one of several dummy organization pages, logs in with the VPI card, and the card delivers the data from the The Mydex Personal Data Store.

When signing up for MyDex, users automatically receive a so-called Community I-Name in the form =mydex*yourname. I-Names are based on OASIS XRI technology. With every I-Name comes a set of identity services such as OpenID, a spam-free Contact Page, and the ability to unify other addresses such as a domain name, e-mail address, Skype ID, MSN number, etc. under a single identifier. I-Names are designed to represent an individual’s identity on the Internet and therefore complement the MyDex vision of user centricity and choice.

But that is not where this Proof of Concept ends. Information Cards are fantastic for providing user agent attributes at card submission. In this case, an encrypted SAML assertion is delivered through a browser plugin. Azigo uses a hosted card service, therefore your cards are available to you wherever you go. Every time the MyDex card is used, a customized token is minted for that specific request. The data comes fresh from The Mydex Personal Data Store. In our PoC, this data includes a freshly brewed ID-WSF 2.0 Endpoint Reference (EPR) — hey, that’s why I am blogging about this!

The ID-WSF Part

If the RP requests an EPR and the user allows the EPR to be sent, then an encoded discovery EPR is delivered through the i-card login. ID-WSF accounts are created on the fly at the request of the The Mydex Personal Data Store. The ID-WSF system is comprised of eight elements:

• *The Mydex Personal Data Store
• An Authentication Service - ID-WSF 2.0 WSP
• An “IdP” wrapper for the Authentication Service - ID-WSF 2.0 WSC, OpenID Provider
• A Personal Address Manager - ID-WSF 2.0 WSC, i-card RP, OpenID RP
• A Discovery Service - ID-WSF 2.0 WSP
• A Personal Profile Service - ID-WSF 2.0 WSP
• A Telephone Company - ID-WSF 2.0 WSC, i-card RP, OpenID RP
• *An Interaction Server

*indicates not id-wsf at the moment

The Mydex Personal Data Store

Not yet an ID-WSF component in the future it will likely play a WSP role. For understanding this PoC, this component is crucial. The identity starting point and data hub. Among the roles it plays are URU address verification, account creation, and integration with both the ID-WSF components and the Higgins/Parity/Azigo services. Primary Ingredients: PHP, MySQL.

Authentication Service (AS)

All WSP services are inside of Conor Cahill’s Server Toolkit. The AS comes ready with the toolkit and uses SASL over ID-WSF 2.0 messaging layer to vend a discovery EPR. This EPR is then handed off to the IdP wrapper WSC. Primary Ingredients: Java, Axis/Tomcat, Conor Cahill’s Server Toolkit, Postgres.

An “IdP” wrapper for the Authentication Service

Mydex VPI Service contacts this IdP to obtain an EPR. If there is not ID-WSF account, then this service creates one and all of its attendant bits. Primary Ingredients: Java, WebObjects, Wakame, OpenSAML, Postgres.

A Personal Address Manager (P.A.M.)

This is the same thin client that I demoed as PAdMan at IIW May 2008. It is a pure WSC and uses an EPR to bootstrap into ID-WSF. This client can be bootstrapped through an OpenID AX containing an EPR. The new work has been two fold 1) Localize for U.K. 2) bootstrap with an i-card. The user presents a Mydex VPI Card and the Azigo plugin delivers an encrypted SAML assertion containing an Discovery EPR. Ah, the power of great base frameworks, I was able to use the OpenSAML libraries that I used as the XML Tooling platform for Wakame to decrypt and deserialize the assertion! Primary Ingredients: Java, WebObjects, Wakame, OpenSAML.

A Discovery Service (DS)

Another ready for use service from Conor’s toolkit. Using TLS Bearer security mechanism, the DS vends an EPR that provides access to the User’s Personal Profile. Primary Ingredients: Java, Axis/Tomcat, Conor Cahill’s Server Toolkit, Postgres.

A Personal Profile Service (PP)

This service is built on Conor’s toolkit and is the datastore for the user’s profile and address information in the ID-WSF environment. The PAM and the Telephone company both access this store on the user’s behalf. Primary Ingredients: Java, Axis/Tomcat, Conor Cahill’s Server Toolkit, Postgres.

A Telephone Company

ID-TELE from the May 2008 IIW, but completely redone. The app is now entirely AJAX based, bootstraps from i-card, uses an interaction server to request permission from the user to subscribe to address and profile information. Primary Ingredients: Java, WebObjects, Wakame, OpenSAML, FrontBase.

An Interaction Server

This is not an ID-WSF Interaction Service, yet, but it contacts the user to obtain permission for ID-TELE to subscribe to address and profile information. Primary Ingredients: Java, WebObjects.

Demo at SXSW

Iain Henderson is at SXSW and will be showing the PoC, so if you want to see it, find Iain. The demo walks through a subscription/notification model that demonstrates the user in control with the vendor receiving up-to-date and accurate information when profile changes are made and when a future address is added.

(Thanks to Markus Sabadello for help writing the i-card and i-name portions of this post)

The Wakame Project is now using the latest OpenSAML libraries which are now in version 2.2.3, released December 21, 2008. The update was relatively painless and provides improved memory usage:

This release contains a few minor bug fixes and a significant
improvement in memory usage. This improvement is especially profound
for metadata which is usually kept in memory. An average metadata file
should see about a 60-70% decrease in consumed memory when it is loaded.

Wakame is now being used in an interesting project based in the U.K. - as soon as this becomes public I’ll tell you more. We are now working on completing the People Service Client. Once this has been completed, Wakame will be a fully functioning ID-WSF 2.0 WSC Library.

If you live in New England, I hope you are enjoying the cold snap. I just returned from balmy Oslo where there seems to be an almost perpetual sunset during the 6 daylight hours this time of year.

IIW Spring 2008 was excellent. The energy was all about collaboration. Cardspace/Infocard, OpenID, and Liberty (SAMLv2/ID-WSF 2.0) were all represented well. The focus was on how to pull these technologies together, leveraging the best parts of each. So the setting was perfect for the convergence demo that I had prepared, bootstrapping ID-WSF 2.0 with OpenID. The demo was 4 applications: RED-ID an OpenID Provider (OP) and an ID-WSF Client, providing attributes through OpenID Attribute extensions which originated from the user’s ID-WSF Profile Service.

Take a look at the presentation overview

There has been a lot of activity lately on the Attribute Services API (IGF). Since milestone 0.2 was published, we have recently checked in updates to reflect the new IGF-CARML-09 draft and checked in a first implementation of WS-Policy support for the API. Milestone 0.3 is well on its way to completion!

We still have yet to implement a provider to a full function protocol adapter like Higgins IdAS, but that should come in Milestone 0.4 or so.

For now, I’d like to encourage folks to check out the API. We’re looking for was to further simplify the developer’s experience and make it attractive. You’ll notice, after declaring the data used by the application that using the API is dramatically trivial compared to older APIs like JNDI or JDBC. Still there is more that could be done.

Enjoy.

This is the official announcement for the beta release of the ID-WSF 2.0 ClientLib! We have been working like mad to get this release out (hence the photo with this post). Lots of new code was cut, lots of old code was gutted or reworked, and there are many new features.

This release marks excellent progress, but there is still a lot of work to do. The beta is not bug free nor is it thoroughly tested. It is ready for other people to sink their teeth into and give feedback, make requests, or write some code. For development purposes we are currently testing against two ID-WSF WSPs and have access to a third (HP Select Federation) which we hope to have working with the library before Version 1 release planned later this year.

This beta would not have been possible without help from a number of people. Notably Conor Cahill, Sampo Kellomäki, and Scott Cantor & the OpenSAML guys. Luckily these people also wrote many of the specifications documents.

What’s New:

• Liberty SOAP Bindings fully implemented
• Handling of CredentialsContext
• Handling of EndpointUpdate
• Added WSFMessageSigner
• TLS and ClientTLS support
• Bearer & SAMLv2 Support (Signing!)
• CRAM-MD5 SASL Authentication
• Addition of ID-SIS-DAP XML Tooling and basic Service Client
• Addition of WSCUtilities to simplify basic ID-* operations
• Simplified approach to creating OpenSAML XML Tooling classes (Element, marshaller, unmarshaller, and builder as a self contained unit)
• javadoc now available
• sample code available
• switched from HttpURLConnection to not-yet-commons-ssl for transport
• Added BaseServiceClient
• Reworked the website to get you to the code faster
• Testing has begun with Symlabs Federated Identity

What remains:

• Lots of testing
• Liberty Certification
• OpenLiberty public testing environment
• compress the Tooling Objects that rely on 4 classes into 1 as per the new method
• sample application using the library
• more utility methods
• Build out: ID-SIS-DAP, People Service
• More Service Clients: ID-SIS SMS and MMS, Contact Book (ID-SIS-CB), SSOService …

If you have questions or interest, please send me a note at asa.openlibertyREMOVEIT@zenn.net (remove the REMOVEIT from the email).

Also, I will be in Santa Clara at the Liberty Alliance plenary meeting, all week. On Monday I’ll be presenting the library. If you are in the area or at the plenary and you want to check it out, do some coding, interop, anything just send me a note and I’ll send you my cell #.

The BETA deadline (February 16th) is rapidly approaching! With this in mind there are two major goals. The first is to have signing enabled and the second is to have an ID-SIS-DAP service client(SC) available. Development on the ID-SIS-DAP SC is going very well and has been a good learning experience. Here’s why:

The ID-WSF2.0 ClientLib uses OpenSAML xmltooling, ws, and saml libraries. There are no xsd code generators for the java-xmltooling classes, so I have spent a great deal of time becoming acquainted with the xsd for the various liberty specifications. I also spend a lot of time writing marshallers, unmarshallers, and builders. So for each element, there is the potential for 4 files. This gets big really fast. With the ID-SIS-DAP SC I began to embed the marshaller, unmarshaller, and builder inside the element class as static internal classes. Yay!! This has taken care of a tremendous amount of clutter, and generally helps with readability.

If you are using OpwnSAML’s java-xmltooling and you want to use this method, make sure that the classes are static, and reference the internal classes in the config file like this:

<MarshallingClass className=”org.openliberty.xmltooling.idsis.dap.DAPModifyItem$Marshaller” />

Notice the “$” between DAPModifyItem and Marshaller. This indicates that Marshaller is an internal class to DAPModifyItem.

Oh, and from Chad at OpenSAML:

The Java OpenSAML 2.0 Release Candidate 2 release is now available at the normal download site.

http://shibboleth.internet2.edu/downloads/opensaml/java/

This release includes minor bug fixes found in RC1 and includes the generated javadocs. This is the last release candidate and the next release will be the final 2.0 release.

The ClientLib tests fine with RC2.

Late news, but still very relevant. Earlier this month we took the alpha to Boston for a presentation at the Jan 8-10 TEG Interim, and interoperability testing with Symlabs Federated Identity Suite. We also made a visit to Parity Communications to meet with members of the Higgins Project to discuss some project synergies. Brett will follow with a post that has more details.

The presentation at the TEG Interim lasted about an hour and covered as many aspects of the project as possible. We discussed the website and the tools we’re using for collaboration, we went through some code, specifically the non standard DST 2.1 based Profile Service, and discussed briefly the trajectory of the project as a whole. Our next deadline (BETA), approaching quickly, is two days after Valentine’s Day, February 16th!!!! Not sure why we keep choosing deadline right around holidays, but there you have it.

The big news from going to Boston was having a chance to meet with Sampo Kellomäki, the Chief Architect at Symlabs. Sampo is extremely knowledgeable in the development and practice of ID-WSF and has written several Liberty specifications. He also has an open source project ZXID, which is aiming for a full stack implementation of all federated identity management and identity web services protocols. ZXID is written in c and supports PERL, PHP, and Java. It is 95% ID-WSF 2.0 feature complete. We are planning on testing with ZXID as soon as possible, using the Java support.

In Boston Sampo and I tested the ClientLib against Symlabs Federated Identity Suite. We successfully authenticated using the Symlabs AS and pulled a Discovery EPR. We then used the Discovery EPR to get another Discovery EPR from the DS. This was fun, and it all went off really well. So, we went to Boston and celebrated. The next day we did some more work and were able to use the DST 2.1 reference implementation to create a ID-DAP query and parse the response. ID-DAP (which is part of Symlabs Federated Identity) provides federated identity based access to an LDAP directory. It is a great example of an in production service that utilizes DST 2.1.

Overall it was a very successful trip. I learned a lot, did some testing, made some friends, and came back to Berkshire County in one piece. Keep your eyes open for the BETA an Feb 16th!

We are very pleased to announce that, after many setbacks and challenges, the ClientLib Alpha is now available online! As of this build, it is possible to use the AS client and the DS client with Conor Cahill’s WSP. The Personal Profile Service Client (operating on DST 2.1) is now complete — and there is now a shell of a People Service Client as well.

To enable you to begin experimenting with this build, we’ve put together a simple quick start, involving 5 simple steps. Please feel free to take a look and let us know what you think, but bear in mind that this is still Alpha code!