[MERGE] authentication ring specification

[Vincent Ladeuil]

>>>>> "aaron" == Aaron Bentley <aaron.bentley at utoronto.ca> writes:

    aaron> Vincent Ladeuil wrote:

    >> +.. [#ignored_realm] The true purpose of realms is to
    >> +allow the same credentials to be reused for disjoint
    >> +hierarchies. Ignoring them in this specifications aims to
    >> +simplify the user experience.

    aaron> I don't really see a simplification in ignoring realm.
    aaron> I think it would be a much better identifier than
    aaron> "path".

Look at it from the opposite point of view then: specifying realm
will complicate the user job for no added value. My point in
ignoring realm is that in nearly all the cases one user will have
access to one or several trees *all under the same realm*.

The only case I can imagine is a tree inside which several realms
are defined for several set of directories (gee, even trying to
express it...). A complicated setup far easier to declare as
separate trees.

I'm sure realms have value... but not for organizing a source
tree or a source tree collection.

Realm is really any string the server admin choose, a
prompt. It's specific to http. It's even possible, via the
.htaccess files to use the same realm even if the credentials are
different.

I really think path is a far better identifier, it's common to
all schemes, it's really what the user see, I'm pretty sure that
only a few people can spot the realm when prompt for a password
from a browser and they don't care ! All they have to know is
their user/password/path.

    >> +  * while ``locations.conf`` is intended to describe *local* branches,
    >> +    ``authentication.conf`` is intended to describe *remote* branches or
    >> +    servers.

    aaron> locations.conf is intended to describe both local and
    aaron> remote branches.  In particular, it provides a way to
    aaron> override the branch.conf settings in a remote branch
    aaron> that you do not have write access to.

Ok, that was poorly expressed then, what I wanted to say was that
locations.conf describes properties organized by local branches
(and indeed can specify settings for remote branches) whereas
authentication.conf describes properties organized by remote
branches (or even remote servers).

    >> +  * What about using ``seahorse`` on Ubuntu or ``KeyChain Access`` on Mac OS X ?
    >> +
    >> +    * ``svn`` use some native APIs to encode its cached
    >> +    credentials, that may provides examples on how this
    >> +    can be done for bzr, then these services could be
    >> +    used to encrypt the passwords and define a new
    >> +    ``password_encoding``.

    aaron> It seems worth investigating the seahorse or KeyChain
    aaron> Access APIs before finalizing this spec.  Such
    aaron> analysis would ensure that our spec is compatible with
    aaron> them, and reading about their APIs could reveal issues
    aaron> that we need to address.

Ok, I'll investigate them then,

    Vincent