Subject: RE: Start on OPES protocol work

From: "Abbie Barbir" <[email-masked]>
Date: Fri, 14 Feb 2003 13:01:52 -0500

Given the latest trends in web services and in particular the work that has
been done in 
XML encryption/signature, I would like to suggest to start looking seriously
into adopting SOAP/XML (or OPES compliant SOAP envelop/Schema) for the
callout protocol.

Using SOAP, we can get the flexibility of defining a protocol that is
extensible and flexible. Using SOAP security extension can solve the
security requirements for OPES.
Having the ability of doing incremental signature is an important feature.
Tracing and notification can be provided as a service, that can take
advantage of the incremental siging ability of XML.

I know off hand that performance issues will be used aginst adopting SOAP.
However, keep in mind that performance is only one factor and it can be
argued that with continous improvments in CPU speed and Hardware
acceleration, this will not (or should not) be a major issue.

There is a lot of work that is being done now on SOAP security that can be
very usefull to OPES.

For OPES to be usefull, I think it should be able to interoperate with web
services. At the end of the day, OPES provide a service to the data
provider/consumer application.

I know that SOAP has been looked at before by OPES. As a start, do we have a
pointer on the previous work, if yes can someone please advice where we can
get it.

Thanks
Abbie

> -----Original Message-----
> From: Markus Hofmann [mailto:[email-masked]] 
> Sent: Wednesday, February 12, 2003 6:52 PM
> To: OPES Group
> Subject: Start on OPES protocol work
> 
> 
> 
> Folks,
> 
> with the first two WG drafts being approved by the IESG 
> (architecture, 
> protocol requirements), and three others under IESG review 
> (scenarios, 
> threats, policy requirements), it's time to get started on  the 
> protocol work!!
> 
> As a starting point, I'd suggest everyone to familiarize 
> herself/himself with the OPES Protocol Requirements Draft 
> (draft-ietf-opes-protocol-reqs-03). It will provide guidance on 
> fundamental questions we'll have to answer before trying to 
> settle/define a protocol, such as
> 
>    - what type of interactions need to be supported (e.g. pure
>      request/response, or request with multiple replies, or...)
>    - what type of data is exchanged in requests and replies
>    - what are the security requirements
>    - etc.
> 
> We also need to keep performance expectations in mind, which might 
> impact the decision whether to go binary, text, highly structured 
> (e.g. XML) etc.
> 
> Based on the answers to these questions, we can then discuss and pick 
> the most suitable protocol. I'm hesitating to list "candidate 
> protocols" since it would *not* be a good idea to talk about specific 
> protocols without having discussed the answers to above 
> questions, but 
> in the past the following options have been mentioned at some point 
> (without a specific order!!):
> 
>   - ICAP
>   - ICAP "next generation"
>   - SOAP/XML
>   - "Something" over BEEP
>   - Binary protocol
>   - more...
> 
> I would expect that we'll have some lively discussion on the protocol 
> issue here on the mailing list, and that we continue and 
> intensify the 
> discussions at a meeting in San Francisco.
> 
> Also consider this a call for agenda items for the next IETF meeting, 
> and send Marshall and myself agenda requests related to the protocol 
> issue.
> 
> So please, let's get started here on the mailing list, keep your 
> thoughts and opinions coming.
> 
> Thanks,
>    Markus
> 
>

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Fri, 14 Feb 2003 13:12:45 -0700

>  advantage of the incremental siging ability of XML.

I've got a book published late last year on XML security, and it does
not mention incremental signatures.  What are they, how would they be
useful to OPES? 

How can we keep track of this W3C work-in-progress from the IETF
vantage point?  I'm not a member of W3C, and I cannot judge the
maturity of their drafts, the likelihood of standardization of any of
the documents.  Can you and others promise to serve as liasons,
keeping us apprised of what's going on?  Or perhaps there's already someone
who does this for the XML security work, like Don Eastlake.

>  acceleration, this will not (or should not) be a major issue.

I'm not objecting to examining performance vs. ease-of-use, but it is
important to keep the whole picture in mind.  If a single CPU with no
special hardware enhancements can keep a 2 Gbps line busy, carefully
balancing CPU cycles and I/O, then you have to be very careful about
adding extra per packet processing that multiplies the CPU cycles by a
factor of 1000 - this would mean that an organization would need many
more CPU's to do the same job.  So let's be very specific when we
discuss performance and acceleration - the numbers are important
because they determine the cost of the deployed systems.

>  There is a lot of work that is being done now on SOAP security that can be

How can we know what that very useful work is?

>  provider/consumer application.

Can you tell us what it means to interoperate with web services?  I'm
not against it, but I've got only the vaguest notion of what it might
mean for OPES.

>  pointer on the previous work, if yes can someone please advice where we can

My memory of this is that Lee Rafalow was a strong advocate of looking at
SOAP, but there was no work beyond that advocacy.  Perhaps others have
done work since then, but have not reported it to OPES because we were
concentrating only on the initial documents.  We need to spread the word
that we are now in a new WG phase and it is safe to come back to the mailing
list.

Hilarie