On Mon, Jul 28, 2014 at 11:01 AM, Mark van Cuijk <m...@coinqy.com> wrote:
> Good to see that it has been discussed, but I see the idea has been
> postponed.
>
I'm not sure postponed is the right word. It wasn't in v1, but many useful
things weren't. It's more like, a bunch of people have to do work to
upgrade this and at the moment they're all busy with other things.
> I do like the idea coined by Mike that a PP can issue non-SSL certificates
> for the purpose of merchant identification, as long as a customer is free
> to determine whether he trusts the PP for this purpose.
>
I don't think I proposed this exactly? It's the other way around - a
merchant issues an extension cert to allow the PP to act on their behalf.
> Regarding the choice of how to authenticate the PP, I’m a bit
> undetermined. Disregarding backward compatibility, I think the extended
> certificate system proposed by Mike is cleaner. However, I don’t like the
> concept of requiring two separate signatures for old and new clients.
> Taking backward compatibility in mind, I tend to prefer my proposal.
>
I'm not sure I understand. Your proposal also has two signatures. Indeed it
must because delegation of authority requires a signature, but old clients
won't understand it.
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
