Benjamin Kaduk <[email protected]> wrote: >It's not clear what reading to apply to a "combined combined token", >that >is, a Tn where one of the source T0 or T1 was already the result of a >CombineTokens() operation.
>"list of identities is the union of those in the original tokens" would > >seem to imply that there is not a concept of nested list/pairs, just a >flat space. Actually, "union" would seem to imply a set-theoretic >concept, *without* order. So given your above interpretation, that >would >be a bug in the spec. Yes, I would say that "union" is not the right word. I think you end up having these options: 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. >Okay. I would pick (1) from that, and prefer that the client indicates > >its preferences. Sounds good to me. _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
