Hello Jan,

> >  [ connected and authenticated ]
> > or
> >  [ disconnected using the cached rights on the cached objects ].
> > 
> > What is missing is
> >  [ connected and using the cached rights on the cached objects ]
> 
> You missed 'connected and not authenticated'. Which makes your missing
> state ambiguous.

true, [ connected and not authenticated ] state _is_ available,
I should have listed it as well.
The problem is that the user's cached rights are not used then.

> It is kind of like using an expired or stolen credit card, as long as
> nobody checks the purchases go through, until we go to a place that
> checks the expiry date or a list of stolen cards.

It is rather that way:
- the store checked my valid ID card yesterday, and they know for sure
  I did possess my creditcard and they took some goods for me into the store
  (charging the credit card, so there is no problem with a bad credit)
- today I come to pick up the prepaid goods, the store checks my ID
  against a police database over the phone and finds that today the ID is no
  longer valid (I should have visited a police office and got a new one
  last night)
- the store knows for sure that me is me,
  as they took my fingerprints yesterday! like they do with all customers :)
- they refuse to give me the goods, call police again and again but always
  get the same answer - they can not trust my ID _today_

the comical reality:

- several minutes later they find that the phone is cut and they can not call
  the police station. then they give me my goods as they know well who I am :)

I would be happy to tell them when I come:
- please do not check my account today, you have got my money yesterday,
  and I am not going to make more purchases than paid for,
  check my fingerprints, I _am_ the person who paid,
  give me my things which you were kind to keep overnight...

> The thing with bad credentials is that it is impossible to set up a
> working connection to the servers. So if we leave the authenticated user
> object around, that user would in effect stay disconnected from the
> servers even though other users can still fetch files and such. I don't

It is quite natural. Without a valid ID I can't make new purchases,
even when people around me do! Well, I cannot even see if there are some new
goods available? it is bad... but still better than to lose even the old ones.

> know how such a partly disconnected state would work reliably and it is
> possibly even more confusing to the end user.

I agree it _may_ be confusing - but not more than a sudden rights expiration.
If the rights do not come back while disconnected, it makes the disconnected
mode hardly reliably usable. If they do come back (as Venus behaves now), it is
not any more secure than to trust the ID checked yesterday.

In the worst case modified files will stay in the client cache and with
some luck will never be lost ;-)

It may be hard to implement in a correct way, don't know.

My practical compromize would be to try that at least for read-permissions,
as then a user could run software from Coda without the risk of losing
the access as time goes. The only risk would be when somebody else
with tokens fetches a new version of the same binary, and _then_ the
tokenless colleague loses the cached access rights.

[that should _never_ happen, as it is a very bad idea anyway,
to replace an executable file contents on a global file system :]

My best regards,
--
Ivan