> Agree on the lack of authentication and authorization issues, these are 2 > items OPES is proposing to address. Several of us have long believed that > with an OPES framework, multiple existing remote procedure call > protocols including iCAP and SOAP can be added to an authenticated and > authorized intermediate proxy model. By applying AAA in the form of an > Admin Server, where authorization is classically a policy model with PRC > modules and the like and authentication is capable of using protocols > such as SSL, we have the opportunity to disarm the bomb. The missing feature is security between endpoints. You cannot get there by adding AAA, admin servers, and yet more proxies. That is like trying to prevent your car from being stolen by loading it up with several tons of steel. Why not just lock the door? Object based security techniques ought to do the job.
- Comparison of ICAP and SOAP Wanghong Yuan
- Re: Comparison of ICAP and SOAP Mark Nottingham
- Re: Comparison of ICAP and SOAP Lee Rafalow
- Re: Comparison of ICAP and SOAP Roy T. Fielding
- Re: Comparison of ICAP and SOAP Lee Rafalow
- RE: Comparison of ICAP and SOAP Manoj Dhooria
- Re: Comparison of ICAP and SOAP John Martin
- Re: Comparison of ICAP and SOAP Randy Bush
- RE: Comparison of ICAP and SOAP Tomlinson, Gary
- RE: Comparison of ICAP and SOAP Tomlinson, Gary
- Re: Comparison of ICAP and SOAP Bernard Aboba
- Re: Comparison of ICAP and SOAP Brian E Carpenter
- Re: Comparison of ICAP and SOAP Jim Fleming
- Re: Comparison of ICAP and SOAP Mark Nottingham
- Re: Comparison of ICAP and SOAP Michael W. Condry
- Re: Comparison of ICAP and SOAP Mark Nottingham
- Re: Comparison of ICAP and SOAP Michael W. Condry
- RE: Comparison of ICAP and SOAP Hilarie Orman
- Re: Comparison of ICAP and SOAP Hilarie Orman
- RE: Comparison of ICAP and SOAP Carr, Wayne
- Re: Comparison of ICAP and SOAP Mark Nottingham