On Sat, 3 Nov 2012 14:34:37 -0400 (EDT) Benjamin Kaduk <[email protected]> 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: [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. 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 :) -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
