Reply to Craig Burton

Craig Burton recently replied to my comments on his I Cry Post. While I generally agree with his sentiment on the metasystem, I have to take issue with the oversimplification of Infocard, Microsoft's implementation.

Craig states:

WS-* is not the encapsulating protocol. WS-Trust is the encapsulating protocol.

WS-Trust is actually just the encapsulating protocol for claims transformation. Microsoft's paper on the Identity Metasystem defines encapsulating protocol as the following:

"The encapsulating protocol provides a technology-neutral way to exchange claims and requirements between subjects, identity providers, and relying parties."

While WS-Trust may provide for claims transformation, it certainly does not provide provide the complete working pieces of an Identity Metasystem. In order to build a metasystem, you need a number of other critical pieces. In this case Microsoft is requiring:

• WS-SecurityPolicy and WS-MetadataExchange for declaration and negotiation of claims requirements
  
• WS-Security/dsg/encrypt and for message integrity, confedntiality, and claims presentation
  
• WS-SecureConversation for channel security and trust associations
  
• WS-Addressing for action, address, and message correlation
  
• SOAP for transport abstraction
  
• ...and some other tiny required specs...
  

Although not all of these are required components of an abstract metasystem, they all seem to be requirements of the Microsoft implementation, and that seems to run contrary to his call for an "architecture that is independent of mandated adoption" You gotta buy in.

Craig goes on to say:

What does WS-Trust do? It converts a token (in any format) into another token (in any format). You input an existing token, a request for a new token, and get back the new token. In otherwords, it is a token exchanger – between constituent systems.

Properly characterized, I'd say WS-Trust simply allows you to request this action to be performed. It's a simple request/response protocol, where the magic of any to any token transform is left out of band. At that point we're left up to systems that implement an Security Token Service (STS). I can name 1 commercial STS implementation (IBM's FIM), the Indigo Beta from Microsoft would allow you to build one fairly easily, and prototype code from sourceid. (Anyone know any others?) Unfortunately, given the above protocol requirements, there is some serious impedance in place of ubiquitous adoption.

Compounding the protocol requirements, in order for an STS to convert a token in any format, to any format, some sort of semantic equivalence between the two would need to be defined and implemented...something which is generally non-trivial, and sometimes not possible. Additionally, without a single canonical token format, and lacking a registrar of token formats and transforms, we're also left with a pretty serious scale issue. How does one know what the possible transforms are, and who can fulfill them? How do you incent the Supplying and Relying parties to negotiate (and by this I really mean implement) to a common set of claim formats?

Realistically, I think we'll probably end up in an environment where we negotiate to a limited set of common claims formats for the common stuff, and allow transport of a variety of vertically focused claims. Bridging between the participating parties is critical, but I'm not convinced that its the transform that's the killer app.


What I do think Craig really hits on here is that it's mandatory that a multitude of claims formats be supportable; a successful metasystem will neither be able to predict, nor prescribe the token/claim/assertion/attribute/etc formats which will flow across it. The transform is really just a facilitator, often necessary, but perhaps not a required one. I think Microsoft really nailed the decision to leave the token format out of band for the metasystem. This is critical to ubiquity, and I'm singing along with Craig on this. I am skeptical that they've got the right design center for adoption in the encapsulation protocol, when looked at in terms of it's complexity.


This does bring up a few outstanding questions I've got about Infocard:

• What is the metadata format for "cards"? A combination of a WS-Addressing Endpoint Reference and Ws-SecPol? Something else?
  
• How is it advertised and acquired? - Discovery seems totally opaque in the information I've seen so far. Kim Cameron alluded to the ability to advertise that one provides a card on a website at IIW this year, but what are the details?
  
• At IIW, Microsoft mentioned that in order to promote usability aspects of the system, they'd be binding a human readable explanation of the machine readable claim. What is that format, and how is this not a new mandatory claim format for us to adopt?
  

Anyone out there have the answers?