[MERGE] Authentication Ring spec

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel wrote:
> Aaron Bentley wrote:
>> Aaron Bentley has voted resubmit.
>> Status is now: Resubmit
>> Comment:
>> You seem not to have noticed my mailing-list comments:
> 
>> 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.
>> I don't really see a simplification in ignoring realm.  I think it would
>> be a much better identifier than "path".
> 
> I actually disagree with you here, and agree with Vincent's statement.
> 
> There is no realm for "ftp", and for http it isn't obvious what realm would be.

I'm not saying ftp needs a realm.  But it's not clear that FTP has more
than one authentication regime per host.  And even if it did, I'm not
saying "realm" should be used for FTP, just http.

For http, it is completely obvious.  It shows up in every password dialog.

> And while I'm sure it is possible to set it up. I think for *users* they know a
> URL, which makes path blatantly obvious.

Maybe, but *machines* only know the realm.  They should be able to write
these config files automatically, but forcing them to use the path is
forcing them to guess.  They don't know how what portions of the path
hierarchy are covered by the realm.

Also, if bzr doesn't know the realm, it cannot detect when it changes
and give a good diagnostic.

>> It seems worth investigating the seahorse or KeyChain Access APIs before
>> finalizing this spec.  Such analysis would ensure that our spec is
>> compatible with them, and reading about their APIs could reveal issues
>> that we need to address.
> 
> I think it is worthwhile to look into them. This spec seems to mostly cover the
> possible file format spec, more than the internal apis.

This means that it discusses the kinds of data that are stored.  Since
the APIs will require some of that data, we'd better find out which data
they need.

> It does discuss how the
> api would be used. But that doesn't mean a lot about the specific calls, etc.
> Which would effect how seahorse/keychain apis would be connected. It even
> mentions looking at them as part of implementing this spec.

Yeah, which means to me that it's neither fish nor fowl.  Without
knowing whether this spec makes sense in the context of these APIs,
what's the point?

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGqkmV0F+nu1YWqI0RApzKAJ9H0EuQaYuxMzfkl2kgvRFnq1B6MQCfTP6S
drN0egaBlcKLZNUR2hdoRWE=
=WDLN
-----END PGP SIGNATURE-----