On 3 Nov 2012, at 00:37, Jeffrey Hutzelman wrote: > 1) accept a list of tokens, instead of just two > 2) define how things get composed when you combine combined tokens. For > example, say that tokens contain a flat list of identities, and combining > results in (@id1, @id2). > 3) disallow combining of combined tokens > 4) leave the identity/authz meaning up to the application, including the > question of what multiple combination means. > > I prefer option 4. Well, I prefer options 1 and 4 together, but that would > be a change which I don't intend to push for. >
I also prefer option 4. This document says nothing about the format of a token, which is what really determines what meaning you can attach to the group of combined identities. When we come to discuss AFSCombineTokens, we will need to address this point - but I'm trying to avoid broadening this discussion to incorporate the AFS specific draft at the moment. Before we all spend a huge amount of time on CombineTokens, I think its worth noting that it primarily exists as a building block for AFSCombineTokens. It may be more productive to consider what AFSCombineTokens should look like, and then which of those features are sufficiently generic that they should be back-ported into CombineTokens itself. Cheers, Simon. _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
