Conor has graciously explained the “strangeness” I felt in the Advanced Client scenarios. He explains that this part of advanced client work:
addresses the problems involved in provisioning functionality to a secure container that is associated with a user somewhere nearby
That snippet was enough for me to grasp it. Read the rest of what he has to say for more.
I wanted to clarify on two points he made. First:
Ian seemed to connect this work to Cardspace, Higgins, and OpenID. I am not aware of this connection.
Agreed. This was a case of my braining running ahead of my hands. I started with the ICP stuff and somewhere along the line my brain hopped on to a different topic… sorry, lack of conversational turn signals. This (barely) provides a little bridging between my thoughts.
Ian seemed to think that this provisioning was just about provisioning a credential. That isn’t the case.
That would be my user provisioning baggage. Account/credential = functionality. Dogmatic on my part. The reality is that a collection of attributes can (and do) define different sets of functionality and/or access. We used to call them virtual accounts in my IBM days.
Thanks to Raj, Paul, and Conor for all chiming in on my previous post of SPML in the CardSpace world.
However, we also decided that this “model of provisioning looked a bit strange” to try to shoehorn into SPML as the problem we were solving was just different. There was at least one contributor to SPML in the room while this disucssion was going on and the decision was being made, so I presume they also felt that the model was “strange” for SPML.
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.
I was reading about Conor Cahill’s workshop at RSA on secure provisioning of network credentials over the wire. It was a joint proof of concept between Intel, BT, and HP using Liberty’s ID-WSF Advanced Client. They talked about how to get credentials from service providers down into a client environment. (Although it is not a requirement, clearly Intel would love it if the client environment was a TPM-like object.)
One aspect of all this is a provisioning service, one for which Liberty has cooked up a spec. As a user provisioning guy this model of provisioning looked a bit strange to me. Think telephone service provisioning, not enterprise user account provisioning. The funny thing is, I thought there already was a perfectly good provisioning service standard out there – Service Provisioning Markup Language (SPML).
That got me thinking. Provisioning is an aspect of the identity lifecycle that you don’t really hear about in talks on Higgins and CardSpace and such. This is a bit of history repeating itself. Back in the day, the authentication guys got all the glory, all the publicity, and when it came time to make sure there were actually credentials in back-end services, they waved their hands. It was the lowly user provisioning system, the late-shift janitor of the identity world, that actually had to do the dirty work. Who is this janitor in the user-centric identity world?
Before I go on without a better understanding, I’m looking for comments on this one. Where does SPML fit in this brace new identity world? Is the intention that SPML will be passed as part of a larger SAML assertion to establish credentials? Is the PSTC working on scenarios like this?