Title: 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.
Regards,
Nigel.
