Re: [Taler] mint base URL subtleties

[Christian Grothoff]

On 12/08/2015 09:19 PM, Florian Dold wrote:
> Hi all,
> 
> we need to agree about some subtleties of the mint base URL.
> 
> 1. URLs without a schema part.
> 
> According to RFC2396, URLs without the schema part are considered
> relative URLs.  What should we do if the wallet-user enters such a URL?
> 
> a) Reject such URLs
> b) Have the wallet normalize those URLs (making them an absolute URL by
> adding 'http://') before storing them anywhere or using them in requests.
> 
> Note that we should never have relative URLs in any database / request
> because some libs / languages give unexpected or even stupid results,
> e.g. php with pecl-http:
> 
>   php > echo ( new http\Url("taler.net") );
>   http://tripwire/taler.net
> 
> What were they thinking??  Adding the local hostname?  Not even just
> 'localhost'?
> 
> I'm leaning towards option 1.b., since that's what browsers commonly do.

Tricky. How do you know it should be http://, and not https://? I think
if we don't do 1a, then at least we should default to https. Asking a
mint to run https or fail on auto-completion is better than using http
with a mint that does offer https.

> 2. URL joining
> 
> Joining an absolute with a relative URL has (in browsers and most
> libraries I know) very specific semantics, which might not match what we
> expect in Taler.  For example in Python3 (note the slashes):
> 
>   >>> urllib.parse.urljoin("http://taler.net/mint1";, "keys")
>   'http://taler.net/keys'
>   >>> urllib.parse.urljoin("http://taler.net/mint1/";, "keys")
>   'http://taler.net/mint1/keys'
> 
> This raises the question:  When we're given a base URL, should it matter
> that it ends with a slash or not?
> 
> Keeping the url joining semantics, we could have base URLSs like
> 
>   http://taler.net/mint/landingpage.html
> 
> and our '/keys' would still be http://taler.net/mint/keys.
> 
> However it's quite confusing to the user that the slash is so significant!
> 
> I see three options:
> 
> a) Normalize the mint URL to end with a slash when the user puts it into
> the wallet
> b) Implicitly add a slash (if it not exists) to the end of the base URL
> when joining things
> c) Make the slash 'significant'
> 
> Any opinions?
> 
> Gabor was leaning towards (2.b) I think; personally I don't really mind
> but we must agree on something.

I think Python 3 is technically correct, but would also lean towards 2b
(and expect sane mints to run top-level so that this doesn't matter in
practice.)

> 3) Multiple base URLs
> 
> How should multiple base URLs be handled?  Should there be a canonical
> mint URL that's given in '/keys'?  What is stored in our wallet database
> if the user adds a reserve with the same mint twice, but specifies
> different URLs that the mint both provides?

I'd say different base URL == different mint for the wallet. Otherwise,
you don't know under which URL to interact with the mint, so that'd be
bad.  If the same mint operator uses the same mint keys under two
different URLs, I see no problem with wallets that treat those mints as
separate entities. The only point is that we need to track the mint by
URL inside the wallet, instead of by the mint's master key. But that
seems fine.

> One possibility is to store for each reserve the mint base URL that was
> used, and for each mint in the DB the URL that we used last to update
> it.  Not sure if that's really necessary though ...

I think you'll need to track the URL per coin, as you cannot lookup the
URL from the DK alone.  So:

Table 1 (coins):
 coin (coin_priv, dk, amount, etc.) + mint base-URL

Table 2 (mints):
 mint-base URL + mint-specific data (/keys, /wire)

Table 3 (denomination keys)
 dk + mint-base-URL + fees, expiration times, etc.

so you'd literally select from the 2nd table by URL, and from the 3rd by
DK + URL.

My 2 cents

-Christian

signature.asc
Description: OpenPGP digital signature