Wednesday, February 14, 2007

SPML Decision Followup

Ian responds to my response to his questioning about Liberty's decision to not use SPML in the Liberty Alliance Advanced Client work with a question:

Can someone summarize the “strangeness” in the Advanced Client spec? It seems to me that the Trusted Module is a bit like a PSO in SPML. That still doesn’t feel right, but I am having a hard time trying to be more specific than that.

The advanced client work (which isn't a single spec, but a set of specs covering different capabilities -- provisioning being one of them) addresses the problems involved in provisioning functionality to a secure container that is associated with a user somewhere nearby. In developing these protocols we did look at SPML and felt that SPML was more targeted at the case of server to server account provisioning (and we are working with using SPML for that use case in another in-progress specification).

I would say the specific differences include:

  • The recipient of the provisioning isn't a server that the provisioning party has a relationship with (contrary to the normal case for SPML).
  • The thing being provisioned is functionality, not an account -- there is no "account" on the target system (although the functionality being provisioned can be used to access accounts on other systems -- those other systems may have been provisioned with SPML).
  • The protocol has to deal with the fact of connecting the user to the interaction (in this case, that's the hand-off of the provisioning handle to the PMM).

And while I was looking more deeply at the messages I thought I would add a few things to note:

  • Ian seemed to connect this work to Cardspace, Higgins, and OpenID. I am not aware of this connection. The Identity Capable Platform is a research project at Intel, the Advanced Client work is a set of specifications being developed by the Liberty Alliance, the proof-of-concept was a joint effort by HP, BT and Intel. Of course, since the result of the Liberty work is open specifications, any party can make use of these protocols in their implementation.
  • Ian seemed to think that this provisioning was just about provisioning a credential. That isn't the case. The proof-of-concept involved provisioning functionality that included a credential (as well as the functional means to use that credential in EAP-SIM protocols), this isn't a restriction on the protocol and we expect that many different kinds of functionality will be provisioned this way -- not just credentials.
  • I don't think that the ICP would be within a TPM (although I would expect that the ICP would make use of the TPM to establish the ICPs secure environment).

All of that said, I should point out that the specs are currently an early draft release and any and all feedback is welcome. So if you look though what we've done and have suggestions for how we could do it differently (hopefully better), we are all ears.

Tags : / / / / / / / / / /

No comments: