On 29 October 2012 00:43, Dennis Reedy <[email protected]> wrote:
> > On Oct 25, 2012, at 1255PM, Gregg Wonderly wrote: > > > On 10/24/2012 10:39 AM, Simon IJskes - QCG wrote: > >> Hello, > >> > >> a small questionaire. i hope anybody wants to participate by answering > the following questions: > >> > >> - are you interested in river running on the internet? > > At this time I have little interest in pursuing River running on the > internet. I think it's a great idea, but until the complexities of the > security approach and callbacks get straightened out, I dont think it is > sustainable. The semantics of River's security approach is based on the > premise of anonymous HTTP codebases, where you can never trust downloaded > code. We need to reconsider how trust is established. It would seem that > providing an approach where trust is established before hand makes better > sense, both the client and the service can authenticate before code is ever > downloaded. Then having mobile code installed on a client's machine > (perhaps from a trusted app store) would fit into an internet model better > (and also a LAN/WAN deployment). > > It is indeed possible, although managing it at scale is difficult. Having lots and lots of services with lots and lots of codebases has that effect. The web "simplifies" this by limiting arrangements to stuff on port 80 by and large, it's more coarse. You could do it for bits of the URL space but that's relatively rare. Service wise, it seems the typical model is one of centralised authentication where credentials are created. Individual services then hold permissions against those credentials judging locally what access is allowed. That's not to say I'm down on the above at all, far from it. Rather I'm saying we'd need to look seriously at our deployment aspirations, the sources for services (do we really need third party services separately certified? Most banks take a different approach where they certify third-party code themselves) and the general "market-place" we wish to create. Regards > > Dennis > >
