On Sat, 3 Nov 2012, Jeffrey Hutzelman wrote:
On Sat, 2012-11-03 at 14:34 -0400, Benjamin Kaduk wrote:
Simon trimmed the bit where Jeff wrote:
Yes, I would say that "union" is not the right word. I think you end up
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.
Ok, I don't think that's true. As you noted, "union" implies an
unordered set, and that won't do for some of the application needs. But
an ordered list would work just fine. The question is, do we
It was a bit hyperbolic. Requiring a (single-type) list would
unnecessarily restrict application freedom to have more complicated
structures, such as nested lists. While we *could* do so, I would not
like to see us do so.
(a) say that a token has an ordered list of identities, specify rules
for combining identity lists when tokens are combined, and leave it up
to applications to derive authorization from the identity list when a
token is used, or
(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.
I think either option is workable, provided we are clear that it matters
what order the tokens are presented in, because in (a) the application's
authorization function may not treat all identities in a token the same,
and in (b) the combine-identities operation may not be commutative.
I am not fully convinced that we need decide on one of these for this
document, if the identity information in the token is to be
application-specific. Which is not to say that we cannot talk about their
advantages and disadvantages now to get an idea for where we will go in
the future.
I don't really care for (a). If I write T0 = CombineTokens(Alice, Bob)
when I supply an identity for a token and T2 = CombineTokens(T0, T1)
otherwise, then a list of identity information would not be able to
distinguish between CombineTokens(CombineTokens(Alice, Bob),
CombineTokens(Charlie, David)) and CombineTokens(Alice, CombineTokens(Bob,
Combinetokens(Charlie, David))). An application may choose to care about
the distinction between those authentication paths, and I don't think that
we should remove the application's ability to do so.
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.
Yes, that sounds like it should work.
On my list of new changes to add.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
