capaths questions

[Ken Raeburn]

On May 14, 2004, at 14:32, Sam Hartman wrote:
> Can you come up with examples where the current code gives you
> flexibility that the new code does not and where this flexibility is
> needed?

As Sam, Jeff and I just discussed in person:

If two paths are available to two service realms:

C -> A1 -> B -> S1
C -> A2 -> B -> S2

... and S1 allows authentication through A1 but not A2, and S2 allows 
authentication through A2 but not A1, expressing merely that S1 and S2 
are reached through B, which in turn is reached through A1 or A2, is 
not enough.  I have no idea if that situation comes up in real life, 
though.

We also realized that even if S1 and S2 both accept authentication 
through either A1 or A2, we're not sure of how to properly express the 
two available alternatives in the client's config file so as to get 
optimal results -- or if we can get results that would be considered 
optimal.  (For the server, all that matters is that A1 and A2 are 
listed, it won't care that one of them was omitted.)  If anyone wants 
to try to work this out, remember that each of A1, A2, and B above 
could instead be a sequence of multiple realms.

It's pretty clear that in the server-based referral scheme, we can't 
express "you can go through A1, or if that doesn't work, through A2".

Ken