- From: David Nicol <davidnicol@gmail.com>
- Date: Wed, 8 Mar 2017 08:12:23 -0600
- Cc: "public-interledger@w3.org" <public-interledger@w3.org>
- Message-ID: <CAFwScO-3uEhS0c0kP2GoxWMi1TOjOA0-J43Qp8FUqupshDZz=Q@mail.gmail.com>
On Tue, Mar 7, 2017 at 3:15 AM, Evan Schwartz <evan@ripple.com> wrote: > We are definitely interested in supporting cases where the receiver has > multiple accounts on different ledgers. The main question is what layer to > address this at. > > How about supporting these cases strictly at the application layer via user interface sugar? Because "the receiver has multiple accounts on different ledgers" presupposes a working standard for identity, authentication, authorization instead of making those per-ledger policy decisions. From the ILP protocol's perspective, there should be no difference between a transaction involving three accounts in ledgers when the three accounts are controlled by three, two, or one agent entity. (reading this makes you an agent entity.) If two of those accounts happen to authenticate their instructions with the same key pair, or have the same e-mail address, or the same name, birthday, birth-location tuple, that's curious, but the authentication mechanism for each should neither care nor notice nor know about the details of the others. Given the above security and simplicity concerns, how to address the use case? Via shortcuts in the application software, that is, the thing the human end-user works with. Ledg-O-Matic could easily group all of User's accounts everywhere in ways hiding the complexity of pulling verifiable claims out of multiple distributed stashes. Adding these kinds of scenarios to what is supposed to be an easily implementable protocol (such as SMTP, which is an easily implementable protocol, and unlike VXML, which is not) will add complexity, raising the implementation ease barrier, and introducing potential security problems, possibly involving effectively pretending someone else's account is Attacker's Other Account. Is "The System Is Vulnerable To Social Engineering Attacks" a supported use case? I don't think so.
Received on Wednesday, 8 March 2017 14:12:56 UTC