[AFS3-std] Re: rxgk CombineTokens and enctypes (was Re: Re: afs3-rxgk-updates for 03)

[Benjamin Kaduk]

On Tue, 6 Nov 2012, Andrew Deason wrote:

> On Sat, 3 Nov 2012 14:34:37 -0400 (EDT)
> Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>
>> If we agree that "union" is not the right word (it sounds like Simon
>> agrees?), then we cannot talk of a "list" of identities, either.
>>
>> But, going back and actually searching through the document, "list of
>> identities" only appears in this line where the "list of identities is
>> the union of", so the changes needed actually are localized.
>> Something like "[user] identity information associated with the tokens
>> are combined in an application-specific manner" should suffice, I
>> think.
>
> I agree with Jeff's (b) option in his reply, which I think is what
> you're actually going for, as well. Here's some text I'm just throwing
> out there, if you want to incorporate somehow or not:

Yeah, I am basically finding myself ending up in the (b) camp (quoted for 
convenience):
(b) treat the token as having a single, possibly complex, identity, and
leave it up to the application to determine how to combine them when
tokens are combined.

>
> [After the lifetime, byte-life, etc fields are specified]
> + The identity in the new "combined" token is an application-specific
> + combination of the identities of the input tokens; note that this
> + combination may not be commutative.

In particular the combined identity need not represent either the union 
nor intersection of the privileges associated with the two identities. 
(Right?  I had asked rougly this question earlier but I don't think I got 
a reply.)

> When thinking about this, it makes me wonder if
> CombineTokens/AFSCombineTokens warrants an input parameter to specify
> one of possibly many app-specific combination operations. That is, you
> could specify a different constant for generating a combined token that
> is actually a union of user identities, and a different constant for
> combining with a CM-specific token, and a different constant for getting
> a token for executing requests by proxy for another user, etc...
>
> But I think that may be going a bit too far / trying to do too much;
> it's easy enough to just define new RPCs for things like that, if they
> seem desirable in the future. I just mention it because it sounded
> interesting :)

It is slightly tempting, but I think the functionality is best relegated 
to new RPCs.  There does not seem to be a compelling need to build in all 
sorts of bells and whistles here.

-Ben