RE: Resend: ISSUE:[UC-8-0*:Intermediaries*]

>>Hal:
> The other issue about Intermediaries is controlled delegation. I don't
>> remember if it was after Dave left, but at the F2F I deliberately asked
>> about delegation in the hope of provoking the reaction I got. Bob Blakely
>> commented "Delegation is the spawn of the devil." I agree with Bob, although
>> perhaps not for exactly the same reasons. Most people who have been down
>> that road also have scars.
>
> Carlise:
> I was still on the call when Bob said this and thought about
> interjecting but figured no one would hear me. I can only assume he
> was trying to be provocative himself (note that he has expressed the
> same feeling about attribute certificates, but how could he really
> feel this way about ACs and yet support SAML assertions, which are
> attribute certificates by definition?).
>
> The reality is that we all see, use, and live with delegation every
> day. How many times have you received a bounce-back e-mail message
> saying, "I'm on vacation until some_date; if you really need 'X', call
> Josephine at this number..."? This is delegation in action. Somehow,
> nobody seems to get confused by this, get mired down in the complexity
> of it all, or emerge from "down that road" covered with scars.
>
> There is no question that delegation can get complex; nobody is
> arguing that point. However, I contend that if we can't mirror in the
> electronic domain what we are all accustomed to in our current
> business practices, then people won't be satisfied with it. We will
> need this functionality eventually (at some level of complexity)
> because customers will demand it. Why can't we accept that and plan
> for it now?
>
I agree with Carlise here. We built an implementation of SPKI and
found delegation to be very useful. Here are a couple of other places
I think delegation would be useful in SAML.

1. Given not all attribute authorities will be created equally, we
   will need a way to express what an authority is trusted for. (This
   may be out of scope, but to use SAML in practical multi-domain
   application you will need to solve the problem.) One way to do this
   is to use delegation. If Alice wants to trust Bob to issue
   assertions in some set X, she can issue him an assertion delegating
   him authority over space X. If Alice receives an assertion issued
   by Bob to some third party, her verifier can combine this assertion
   with the original delegation assertion to see if Bob's assertion is
   valid. The point is that no special mechanism is required in
   Alice's verification engine to express what Bob is trusted
   for. This will only work if there is a meaningful notion of sets
   over assertions, otherwise the verifier has no way to tell if what
   Bob issued is greater or less than the power granted to him by
   Alice.

2. A second use of delegation would be to solve the problem of having
   to have maximum privilege enabled all the time. This was recently
   discussed on the core-assertion list. In the example Phill
   Hallam-Baker decribed, Alice had an assertion granting her $12M
   purchasing authority. Given this is so sensitive she probably does
   not want it enabled all the time. If this assertion is issued by
   Bob, to Alice's public key, PK1, she can use delegation to scope
   down the authority. She does this by creating another key pair and
   issuing a delegate certificate to the new public key, PK2, for
   $1000. This delegate certificate is issued by Alice PK1 to Alice
   PK2. Alice can then safely remove the device storing the PK1 key
   pair, so that the $12M authority is not enabled. However, using the
   PK2 key pair, she still has the $1000 authority. A relying party
   (assuming they trusted Bob, but not Alice directly), would need
   both assertions (the one issued by Bob to Alice; and the one issued
   by Alice to herself) to verify Alice's authority for purchase up to
   $1000.

security-use message