rxgk CombineTokens and enctypes (was Re: [AFS3-std] Re: afs3-rxgk-updates for 03)

[Benjamin Kaduk]

On Sat, 3 Nov 2012, Simon Wilkinson wrote:

> 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

Option 4 is attractive for this document, which is not intended to be 
application-specific, but I do not think we can push all concerns off into 
application-specific territory.

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.

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.

> 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.

I am trying to avoid doing so except when necessary as well.

> 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.

Okay, I will go review AFSCombineTokens again and think about it.

-Ben