[AFS3-std] Re: rxgk CombineTokens and enctypes

[Andrew Deason]

On Wed, 07 Nov 2012 11:43:15 -0500
Jeffrey Hutzelman <jhutz@cmu.edu> wrote:

> > There are elements of CombineTokens that are not application
> > specific - the way we generate the combined key, the limits on
> > lifetime, bytelife and expiration time.

I don't think so.

> In fact, really the only application-specific behavior is the
> combining of identities.

Yes, but how you combine identities dictates how the whole thing works.

So, for example, in AFS we have one way of combining tokens, for the CM
and user tokens. For that case, you want the combined expiration time to
be the lesser of the expiration times of the input tokens, right?

Say I have another application, where I want to combine tokens such that
the combined token means "try the given operation with identity0, then
try with identity1 if that fails", or something like that. I would think
that the expiration time of the combined token would then not be the
lesser of the input tokens. Since, even if one of the input tokens would
have expired, the other may be usable, and in such a combination scheme,
you don't need both input tokens to be valid at the same time. No?

> I'd rather not see the generic operation go away just because one
> component of one application chooses for convenience to do the same
> thing in an RPC that also does two other things.  More generally,
> while AFS is certainly a driving force for Rx, as someone who has
> written a number of other Rx-based applications, I think there is
> great value in maintaining the notion that Rx is its own protocol with
> AFS as one application, rather than just some of the common bits of
> the various AFS protocols with no concept of layering or abstraction.

Sure. What I'm saying is, any application, AFS or not, needs to define
what this RPC means; it's not usable on its own. So, if you have this
generic RPC that is used by different applications, I see two
annoyances/issues:

 1. You have the same RPC with the same name, code point, and arguments,
 which does potentially very different things. That could be confusing.

 2. Each application needs to specify the behavior of the CombineTokens
 RPC for that application anyway. And if you need to add any input or
 output arguments, you need to make an entirely new RPC. So trying to
 define an application-agnostic one seems like it might be a waste of
 time.

It just doesn't seem like reasoning about the details of the result of
"combining tokens" is meaningful, when "combining tokens" is
intentionally undefined and could be _anything_.


This doesn't seem worth the time spent on it, though. I'm just trying to
explain what I mean; if people just plain disagree, I won't push it. If
nobody else wants to go in this direction, I'm fine enough with any of
the suggested additional text from Ben/Simon/me on this. (The "the new
identity is an application-specific combination [...]" stuff.)

-- 
Andrew Deason
adeason@sinenomine.net