On Tue, 6 Nov 2012, Andrew Deason wrote:
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:
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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
