Clearly Kim Cameron doesn't understand Liberty Alliances's Identity-based Web Services Framework (ID-WSF) when he states:
One of the main advantages of WS-Trust is that it allows multiple security tokens to be stapled together and exchanged for other tokens.
This multi-token design perfectly supports strong identification of a service combined with presentation of a separate delegation token from the user. It is a lot cleaner for this scenario than the single-token designs such as SAML, proposed by Liberty, or the consequent “disappearing” of the user.
First off, I don't think hap-hazard combining of tokens is a way of ensuring that the user's desires are followed. So I presume there's something else going on that supports the correct combining of tokens within WS-Trust, not just the fact that I have the two tokens.
Secondly, in SAML (and specifically in ID-WSF's profile of SAML), the method used to connect the user token to the presenter is dictated by the Subject Confirmation within the token. Essentially this says that "to use this token, the presenter MUST meet the following condition" and that condition, in many circumstances, is the presentation of proof of possession of a key (thus securely binding the presentation of the token to the possession of a specific token by the provider). This is a clear, specific requirement that securely binds the presentation of the user token to the possession of a particular token by the provider.
Thirdly, we don't generally see the model of the user issuing tokens to a provider (most user's I know don't have a clue about how to create a token). The model we used is one of permission based identity sharing where there are appropriate controls provided by the various parties.
For example, the IdP would have a permission switch available to the user giving them control as to whether or not the service provider is allowed to obtain a token for the user when the user is not actively present (so, I would record at my IdP whether or not the service provider is allowed to get a token for me to talk to my payment service, perhaps because I setup automatic payments for that provider).
There are advantages to this model. First off the tokens used in any transaction would be short-term tokens rather than long lived delegation tokens (and as a security weenie, I always like shorter lived tokens better). Secondly, when and if the user would want to change this decision, they just needed to talk to the IdP and not go deal with tokens that they have lying about all over the place.
A second step in this permission based model is that the payment service itself would store permissions about what the other service provider is allowed to do in that context. I may have stored a permission that says the provider can do anything they want. I may have instead stored a more specific permission that says get OK from me for any transaction above $x. These permissions would be specific to the service that I'm giving access to.
In order to support the collection of these permissions, Liberty has identified specific methods used when the user is present to invoke a service indicating to the provider that the caller intends to invoke this service later when the user is not actively present. This allows the service provider to collect the necessary permissions from the user while the user is around.
One final note, Kim separately claims that the user is actually present when these transactions takes place since they consented to their operation at some point in the past. I disagree. Saying that the user is present just because a provider can identify me is a bit of a misleading statement. When my electric company charges my account for my electric bill each month, I am typically asleep and not in any way involved in the transaction. Any identity system that doesn't make that situation clear to all relying parties is, IMHO, wrong. The parties need to know if I'm sitting there instigating this particular transaction or if this is taking place when I'm asleep. Yes, it still should be able to take place when I'm asleep. Yes, it should securely identify who I am in the transaction. But no, it should not look the same as a transaction taking place in the context of a live authenticated session with me directly involved.
Tags : identity / liberty / Liberty Alliance / WS-Trust / delegation / SAML / liberty
No comments:
Post a Comment