W3C home > Mailing lists > Public > public-interledger@w3.org > October 2015

Re: Identity and the need for security

From: Frédéric Meignien <frederic.meignien@cantonconsulting.fr>
Date: Tue, 27 Oct 2015 17:55:20 +0100
To: adrian@hopebailie.com
Cc: public-interledger@w3.org
Message-ID: <562FAC78.1020301@cantonconsulting.fr>
Hi Interledger members,

- ISO 20022 defines all the data required to identify an entity and an 
account. So we can reuse that.
- However, the difficulty is to route the message to the appropriate 
target. For cards, the problem is solved through the BIN directories, so 
I imagine there is a concept of this kind to elaborate, except that any 
kind of payment instrument may be used on the interledger network. The 
solution should then be more elaborate than the BIN one.
(question: does the interledger also creates a new payment instrument, 
which is converted at the end point...let's say, into a transfer, for 
instance ?).
- Another question is to define how Chloe, who wants to send a payment, 
gets in touch with the system: can we imagine that she uses any device, 
and chooses any affiliated "contact point" to start her payment ?
- When this contact is established, the next thing is to find, on the 
network, the institution where her "money" (scriptural or crypto...) is 
booked.
Am I right ? I imagine that this institution has to authorize the 
transaction (question: at which precise moment in the process is it done ?)
- Then, do we consider that this institution must have implemented some 
part of the interledger logic ? I mean, if an institution is stuck in 
its good old system, can it however participate to the interledger 
network, which would then be relayed for her by some existing payment 
framework ?
If the investment cost is low for an institution to get involved in the 
network, things will go very fast (just a few developments...and great, 
I am participant): today, all payment schemes require very high 
investments and long development + test projects. An important part of 
this investment is related to the data protocols: mapping and converting 
messages from one scheme to another is always a source of diffculty. So, 
the capacity to offer to a participant the possibility to use its 
existing protocols make things much easier...Which means that the 
connectors have getways doing the mapping job.
- a part of the security problem depends on the previous question: if an 
institution has to develop something to become a participant, the 
security protocol is necessarily part of this development.
Expressed more directly, my question is: does the interledger network 
disrupts all the other payment schemes, and any participant should go on 
board as soon as possible, whatever the development cost, or does it 
offer getways to the existing schemes and makes its way smoothly among 
them...?

Is all this consistent with what you imagine ?

Thanks a lot

Fred

Le 26/10/2015 16:45, Adrian Hope-Bailie a écrit :
> Last Arie question:
>
> In the case of Identity being critical, would there not be a strong 
> case for Security?
>
>       * dynamic keys?
>       * 3FFA?
>
> By this I assume the question is about transactions where the parties 
> must be known due to regulations (KYC/AML)?
>
> I wouldn't conflate security and identity. A system like ILP will 
> require that all messaging is done very securely with guarantees of 
> authenticity a given. What this ends up being specifically is yet to 
> be decided I think.
>
> Is a secure transport like TLS and signed messages using a unique 
> keypair for each entity enough. Do the keys need to be part of a chain 
> that is rooted at some specific entity (perhaps for regulatory reasons)?
>
> Lots of models and architectures to consider.
>
> What will be required is establishing some standards for how identity 
> data will be conveyed and here we should probably look at how this is 
> already done in message standards like ISO 20022 rather than re-invent 
> the data dictionary?
Received on Tuesday, 27 October 2015 16:55:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 27 October 2015 16:55:59 UTC