Folks, haven’t heard much feedback from
participants – is everyone ok with making these changes?
thanks
From: Kirill Gavrylyuk
[mailto:kirillg@...] Sent: Tuesday, April 05, 2005
12:52 PM To:
WS-Security-Workshops@yahoogroups.com; WS-RM-Workshops@yahoogroups.com Subject: [WS-Security-Workshops]
Proposed updates to SC+RM scenarios document
Based on the comments received so far on the document, we
propose the following updates to the SC+RM scenarios. What do folks think?
Ordering elements inside Security header. An issue was
raised around scenarios text prescribing specific elements order inside
Security header, for example requiring Timestamp to be the first element.
We believe the best way to proceed is to remove any ordering requirements
text from the scenarios doc – follow what WS-Security and BSP
prescribes.
SignatureConfirmation. We introduced SignatureConfirmation
on the secure session initiation (RST/RSTR handshake). Given that this is
a protection mechanism applicable to the entire message exchange, it would
make sense to use it on all messages.
Encrypted Signature. Scenarios document currently
prescribes encrypting signatures on RST/RSTR and app messages, but not
WS-RM infrastructure messages. Similar to #2, given that encrypting
signature is a protection mechanism that is applicable to the entire
exchange, it would make sense to either do it for all messages or not do
it for any.
Attached is the scenarios document with the proposed changes
applied, marked with change bars. thanks
We agree with Doug - testing on secure RM
is the core objective of the workshop, but we are ok with testing unsecure RM
scenarios provided it does not detract from that core testing.
In our experience, testing the baseline
(non-secure) RM scenarios is a useful initial step in debugging and testing
secure RM scenarios anyway, and as Doug mentions we will almost certainly have
spare time.
Microsoft already has both secure and
non-secure RM endpoints available for online testing, and we will be bringing
the same code to the workshop meeting too.
thanks
From: Doug Davis
[mailto:dug@...] Sent: Tuesday, April 05, 2005
11:31 AM To:
WS-RM-Workshops@yahoogroups.com Subject: Re: [WS-RM-Workshops]
SAP's RM Workshop participation in April without SC/T
Steve,
Its ok with us if we use the gathering to do additional RM interop testing but
we should do that only after the objectives of the workshop have been met -
which means focusing on the composibility of SC/T and RM first. If
previous events are any indication we should have plenty of time for additional
fun afterwards. In the meantime, several participants are already hosting
endpoints that are available for test now - people could leverage those before,
during and after the event too. thanks, -Doug
"Winkler, Steve"
<steve.winkler@...>
04/05/2005 11:42 AM
Please
respond to
WS-RM-Workshops
To
<WS-RM-Workshops@yahoogroups.com>
cc
Subject
[WS-RM-Workshops] SAP's RM Workshop
participation in April without SC/T
Hi
All,
SAP
is working very hard to prepare for the interoperability workshop in April.
However, due to several internal dependencies on timelines, it looks like
we will not be able to have implementations of SecureConversation/Trust by the
time of the workshop. Since the focus of this workshop is on the
composability of these specifications, we would like to check with the greater
group as to whether others would be interested in testing non-secure RM
scenarios at the workshop as well. This could be used as an opportunity
for those who were not able to attend the previous workshops to play catchup.
Additionally, If we were to do this before the secure scenarios, it may
help in debugging interop failures (if it works without security but
doesn’t work with security, it could narrow the scope of the problem).
What do people think about using the certificates
pair from the OASIS X509 interop demo (Alice and Bob) that Jan has this
morning for all clients and services?
It would simplify client testing if we can
agree on a single cert pair…
What do people think about using the certificates pair from
the OASIS X509 interop demo (Alice and Bob) that Jan has this morning for all
clients and services?
It would simplify client testing if we can agree on a single
cert pair…
Based on the comments received so far on the document, we
propose the following updates to the SC+RM scenarios. What do folks think?
Ordering elements inside Security header. An issue was raised
around scenarios text prescribing specific elements order inside Security
header, for example requiring Timestamp to be the first element. We believe
the best way to proceed is to remove any ordering requirements text from
the scenarios doc – follow what WS-Security and BSP prescribes.
SignatureConfirmation. We introduced SignatureConfirmation
on the secure session initiation (RST/RSTR handshake). Given that this is
a protection mechanism applicable to the entire message exchange, it would
make sense to use it on all messages.
Encrypted Signature. Scenarios document currently
prescribes encrypting signatures on RST/RSTR and app messages, but not
WS-RM infrastructure messages. Similar to #2, given that encrypting
signature is a protection mechanism that is applicable to the entire
exchange, it would make sense to either do it for all messages or not do
it for any.
Attached is the scenarios document with the proposed changes
applied, marked with change bars. thanks
Steve,
Its ok with us if we use the
gathering to do additional RM interop testing but we should do that only
after the objectives of the workshop have been met - which means focusing
on the composibility of SC/T and RM first. If previous events are
any indication we should have plenty of time for additional fun afterwards.
In the meantime, several participants are already hosting endpoints
that are available for test now - people could leverage those before, during
and after the event too.
thanks,
-Doug
"Winkler, Steve"
<steve.winkler@...>
04/05/2005 11:42 AM
Please respond to
WS-RM-Workshops
To
<WS-RM-Workshops@yahoogroups.com>
cc
Subject
[WS-RM-Workshops] SAP's RM
Workshop participation in April without SC/T
Hi All,
SAP is working very hard to prepare for the
interoperability workshop in April. However, due to several internal
dependencies on timelines, it looks like we will not be able to have implementations
of SecureConversation/Trust by the time of the workshop. Since the
focus of this workshop is on the composability of these specifications,
we would like to check with the greater group as to whether others would
be interested in testing non-secure RM scenarios at the workshop as well.
This could be used as an opportunity for those who were not able
to attend the previous workshops to play catchup. Additionally, If
we were to do this before the secure scenarios, it may help in debugging
interop failures (if it works without security but doesn’t work with security,
it could narrow the scope of the problem).
SAP is working very hard to prepare for the interoperability workshop in April. However, due to several internal dependencies on timelines, it looks like we will not be able to have implementations of SecureConversation/Trust by the time of the workshop. Since the focus of this workshop is on the composability of these specifications, we would like to check with the greater group as to whether others would be interested in testing non-secure RM scenarios at the workshop as well. This could be used as an opportunity for those who were not able to attend the previous workshops to play catchup. Additionally, If we were to do this before the secure scenarios, it may help in debugging interop failures (if it works without security but doesn’t work with security, it could narrow the scope of the problem).
The guys from the Apache project in Sri Lanka will not be able to join us in person for the RM Interop Workshop due to visa
complexities, but they would like to join in virtually.
In order to facilitate this type of remote
testing, I need to make sure the network connections are set up correctly with
the necessary ports open. The connections will be internet-accessible (no NAT),
but behind a firewall.
Please let me know which port numbers your
implementation will use, so we can get the maximum amount of cross-testing
done.
The list I have so far is:
All,
in preparation for the upcoming
RM+SC/T composibility workshop I've updated our RM endpoint to include
the option of asking for the messages to be secured using a secure conversation.
If you want it to use your endpoint I've also included some links
to some keys and certs that you can download and use - they appear when
you choose the "Use SecConv" option. As always, please
let me know if things don't behave as they should. The web site is
still at: http://wsi.alphaworks.ibm.com:8080/wsrm
thanks
-Doug
WS-ReliableMessaging
and WS-SecureConversation Composability Interop Workshop Invitation
BEA Systems Inc, International Business Machines, Microsoft Corporation
and TIBCO Software Inc., co-developers of the WS-ReliableMessaging
specification, are hosting a 2-day Composability Interop Workshop on April 13 and 14, 2005 at Microsoft's Silicon
Valley Campus in Mountain View, CA from 9:30am to 5pm with breakfast available
from 8:30am.
To attend this event, the attached feedback agreement MUST be reviewed
and signed by each attendee - either before or at the workshop event. The
purpose of the feedback agreement is to ensure that everyone involved in
influencing the specifications is committed to keeping the specification
royalty free. Also, as this is an Interop Workshop, participants will need to
bring an implementation based on the specifications below.
The 2-day interop workshop is an ad-hoc, open forum for companies who
have WS-ReliableMessaging and WS-SecureConversation implementations, and who
want to test their implementations with other companies' implementations.
Attendees bring their own laptops, their implementations and any other tools
they feel would be needed; testing among all attendees will occur throughout
the day. A scenario document for use in the Interop Workshop is provided
in the attached invitation pack.
As with previous WS-* workshops, these events are open to anyone who
desires to participate and who can bring an implementation based on the
specifications listed above.
Feel free to pass this invitation along, either within your company or
elsewhere. This is an open forum. No invitation is required, but an RSVP is
appreciated by the event hosts to facilitate accurate logistics planning.
If you are interested in participating, please reply to Jorgen Thelin, jthelin@....
A signed feedback agreement must be faxed to Jorgen Thelin, fax
1-425-708-0533.
Thank you and we look forward to your participation.
We received feedback that attendees would prefer January instead of
December for this event, so we are rescheduling it. We now plan to
hold it January 18-19, 2005, instead of December this year.
The previously uploaded zip file with the invitation, feedback
agreement, and scenarios is still there -- everything in that zip is
still correct except the workshop date.
Sorry to change plans on you if you were planning to attend in
December and hadn't yet let me know. Everyone who contacted me about
attending is OK with the change (or they are unable to make both
December and January).
Regards,
Dan House
IBM
A zip file was just uploaded containing an invitation to an Interop
Workshop for the WS-Coordination, WS-AtomicTransaction, WS-
BusinessActivity specifications. The workshop will be held Dec. 14-
15, 2004 in Research Triangle Park, NC. It will be hosted by IBM on
behalf of the authoring companies: BEA Systems, IBM, and Microsoft.
Also in the zip file are test scenarios and a feedback agreement.
All participants must sign a feedback agreement.
We hope to see you there!
Dan House
IBM
Several
of you might be interested in participating in the WS-SecureConversation
and WS-Trust Interop event in October. Attached is information with
the event details.
WS-SecureConversation / WS-Trust Interop
Workshop – October 5-6, 2004
The authors of the WS-SecureConversation and WS-Trust specifications are
hosting a 2-day Interop Workshop on Tuesday October 5th and Wednesday
October 6th 2004 from 9am to 5pm with breakfast available from 8:30am.
Note that in order to attend this event, the attached feedback agreement
MUST be reviewed and signed by each attendee - either before or at
the workshop event. The purpose of the feedback agreement is to ensure
that everyone involved in influencing the specifications is committed to
keeping the specification royalty free. Also, as this is an Interop
Workshop, participants will need to bring an implementation based on the
specifications below.
The interop workshop is an ad-hoc, open forum for companies who have WS-SecureConversation
and WS-Trust implementations based on the WS-SecureConversation and WS-Trust
specifications published in May 2004, and who want to test their implementations
with other companies’ implementations.
Attendees bring their own laptops, their implementations and any other
tools they feel would be needed; testing among all attendees will occur
throughout the day. A scenario document will be provided to attendees
of the Interop Workshop before the event, and progress of interoperating
implementations will be tracked throughout the event.
This workshop will be held at the University of Texas Commons Center in
Austin, TX, see below for location details.
For more up-to-date information on the location please visit one of the
following sites:
An internet connection will be made available during the workshops.
Breakfast, lunch, and afternoon snacks will be served, but participants
will be responsible for their own dinner arrangements. Please make any
special dietary requirements known in advance, and every effort will be
made to accommodate them.
As with previous workshops, these events are open to anyone who desires
to participate and who can bring an implementation based on the specifications
listed above.
If you are interested in participating, please reply to fellerj@...
A signed feedback agreement will also need to be faxed to John Feller at
+1-919-486-0574.
Feel free to pass this invitation along, either in your company or elsewhere.
This is an open forum. No invitation is required, but an RSVP
on or before 9/23/04 is appreciated by the event hosts to facilitate accurate
logistics planning. The list of attendees and general workshop results
will be made public after the workshops.
Thank you and we look forward to your participation.
BEA Systems, Inc., Computer Associates International, Inc., International
Business Machines Corporation, Layer 7 Technologies, Microsoft Corporation,
Netegrity, Inc., Oblix Inc., OpenNetwork Technologies Inc., Ping Identity
Corporation, Reactivity, Inc., RSA Security Inc., VeriSign Inc., and Westbridge
Technology, Inc.
------------------------------------------------------------------------------------------
Workshop Location Details
October 5-6, 2004 (WS-SecureConversation/WS-Trust
Interop Workshop)
University of Texas Commons Center
MCC Building (Hill Country
Room 3.1004)
3925 West Braker Lane
Austin, TX 78759
UT Commons Center Phone: (512) 471-5898
For Maps, Area Hotels, and additional
attendee information visit - http://www.utexas.edu/facilities/commons/attendees.html
Nearest Airport: Austin, TX (AUS)
-----------------------------------
Attached to this note: WS-SC/Trust Scenario
document
From: gardeap
[mailto:gardeap@...] Sent: Wednesday, May 26, 2004 9:09
AM To:
WS-RM-Workshops@yahoogroups.com Subject: [WS-RM-Workshops]
WS-RM:SPEC:Minor typos?
http://Business456.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546817 shows up as a duplicate wsa:MessageID for the
following messages: "Create Sequence",
"Message 3" and "Terminate Sequence" and the retransmission of "Message 2"
using Message 3's wsa:MessageID.
http://Business456.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546817
shows up as a duplicate wsa:MessageID for the following
messages: "Create Sequence", "Message 3" and "Terminate Sequence"
and the retransmission of "Message 2" using Message 3's
wsa:MessageID.
Petru.
The spec is clear that the last one to arrive wins (it says: Its presence
MUST override any previously established expiration). However, the
problem you mentioned (about the sender and receiver being out of sync if
messages are lost) is a valid.
-Dug
Please respond to WS-RM-Workshops@yahoogroups.com
To: <WS-RM-Workshops@yahoogroups.com>
cc:
Subject: RE: [WS-RM-Workshops] Minutes from second RM interop workshop -
May 12-13,
2004
I would also like to get clarifications on the following issue.
There is an expires element on the wsrm sequence header.
/wsrm:Sequence/wsu:Expires
This optional element indicates the point in time at which the Sequence
will expire. Its value is a dateTime. Its presence MUST override any
previously established expiration. Expiration should be established as
described in Section 4.3. A SequenceAcknowledgement that covers the
MessageNumber of the message that carries a <wsu:Expires> element indicates
acceptance of the new value.
Theoretically, each message can carry a different expires value. So on
the receiving end, which value should take precedence? The last received
message or the message with the highest message number? It would seem to
make sense to use the last received message (I believe that's the
assumption we made during the interop event), but then that causes
non-determinism because of retries and causes sending end and receiving
end to be out of sync in terms of the expiration time.
An ack hardly helps if its range covers two messages with a <wsu:Expires>
element.
Lei
Yahoo! Groups Sponsor
ADVERTISEMENT
Yahoo! Groups Links
To visit your group on the web, go to:
http://groups.yahoo.com/group/WS-RM-Workshops/
To unsubscribe from this group, send an email to:
WS-RM-Workshops-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
I would also like to get clarifications on the following issue.
There is an expires element on the wsrm sequence header.
/wsrm:Sequence/wsu:Expires
This optional element indicates the point in time at which the Sequence will expire.Its value is a dateTime.Its presence MUST override any previously established expiration.Expiration should be established as described in Section 4.3.A SequenceAcknowledgement that covers the MessageNumber of the message that carries a <wsu:Expires> element indicates acceptance of the new value.
Theoretically, each message can carry a different expires value. So on the receiving end, which value should take precedence? The last received message or the message with the highest message number? It would seem to make sense to use the last received message (I believe that's the assumption we made during the interop event), but then that causes non-determinism because of retries and causes sending end and receiving end to be out of sync in terms of the expiration time.
An ack hardly helps if its range covers two messages with a <wsu:Expires> element.
I agree that the Fault was intended to be sent back reliably on
the same response sequence, so let's just drop the FaultTo EPR.
I'll try to update IBM's site as soon as I can.
-Dug
--- In WS-RM-Workshops@yahoogroups.com, "georgecopelandmicrosoft"
<gcope@m...> wrote:
> The RM Fault Generation scenario (3.1) was not specified in enough
> detail, just based on the fact that different people are reading it
> differently. Eg, on the Microsoft RM endpoint, I originally
assumed
> that the Fault message was not reliable, since FaultTo could be
> different from ReplyTo.
> After talking with others about this, I think the intent was for
the
> Fault message to be reliable, so I suggest the following:
> - The Fault message is reliable.
> - The Fault message is sent on the same sequence as the other
> response messages.
> - To facilitate the above, the request messages should not have a
> FaultTo, so the ReplyTo is implied per the WS-Addressing spec
rules.
>
> I changed the Microsoft endpoint to reflect this. Thanks.
>
> George Copeland
The RM Fault Generation scenario (3.1) was not specified in enough
detail, just based on the fact that different people are reading it
differently. Eg, on the Microsoft RM endpoint, I originally assumed
that the Fault message was not reliable, since FaultTo could be
different from ReplyTo.
After talking with others about this, I think the intent was for the
Fault message to be reliable, so I suggest the following:
- The Fault message is reliable.
- The Fault message is sent on the same sequence as the other
response messages.
- To facilitate the above, the request messages should not have a
FaultTo, so the ReplyTo is implied per the WS-Addressing spec rules.
I changed the Microsoft endpoint to reflect this. Thanks.
George Copeland
From: Mitko Iliev
[mailto:imitko@...] Sent: Wednesday, April 28, 20048:58 AM To:
WS-RM-Workshops@yahoogroups.com Subject: Re: [WS-RM-Workshops]
WS-RM Interop Endpoint
Thanks for the quick response.
Doug Davis wrote:
> oops - ok I've fixed it but it might not be
until tomorrow before the > fix gets migrated to the endpoint. > One question though - since there are no
parameters on that operation > shouldn't the encodingStyle attribute be
ignored? > The CreateSequence is defined in WS-RM XSD as
<xs:element name="CreateSequence"/>; thus no
attributes are allowed AFAIK.
Best Regards, Mitko
> -Dug > > Please respond to
WS-RM-Workshops@yahoogroups.com > > To: WS-RM-Workshops@yahoogroups.com > cc: > Subject: Re: [WS-RM-Workshops] WS-RM Interop
Endpoint > > > Hi, > > When trying the demo client I noticed an
"encodingStyle" attribute in > CreateSequence SOAP request: > >>> excerpt > <ns1:CreateSequence > soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" > xmlns:ns1="http://schemas.xmlsoap.org/ws/2004/03/rm"/> > << > > This IMHO is not supposed to exists in
CreateSequence as it's > document/literal encoded SOAP message? > > Regards, > Mitko > > > Doug Davis wrote: > > > IBM's
WS-RM endpoint at: > > http://wsi.alphaworks.ibm.com:8080/wsrm/index.html
supports the > > scenarios described in the interop doc
(except the security ones). If > > anyone gets a chance to try it out or
even to put up their own > > endpoint before the interop please let
me know. > > thanks, > > -Dug > > > >
------------------------------------------------------------------------ > > *Yahoo!
Groups Links* > > > > * To visit your group on the web, go to: > > http://groups.yahoo.com/group/WS-RM-Workshops/ > > > > * To unsubscribe from this group, send
an email to: > >
WS-RM-Workshops-unsubscribe@yahoogroups.com > > <mailto:WS-RM-Workshops-unsubscribe@yahoogroups.com?subject=Unsubscribe> > > > > * Your use of Yahoo!
Groups is subject to the Yahoo! Terms of > > Service <http://docs.yahoo.com/info/terms/>. > > > > > > > -- > Mitko Iliev > Developer Virtuoso Team > OpenLink Software > http://www.openlinksw.com/virtuoso > Cross Platform Web Services Middleware > > > > > > Yahoo!
Groups Links > > > > > > > > >
------------------------------------------------------------------------ > *Yahoo!
Groups Links* > > * To visit your group
on the web, go to: > http://groups.yahoo.com/group/WS-RM-Workshops/ > > * To unsubscribe from
this group, send an email to: >
WS-RM-Workshops-unsubscribe@yahoogroups.com >
<mailto:WS-RM-Workshops-unsubscribe@yahoogroups.com?subject=Unsubscribe> > > * Your use of Yahoo! Groups is subject to the Yahoo!
Terms of > Service
<http://docs.yahoo.com/info/terms/>. > >
I've attached an update to the Scenarios document for the interop testing. It
has the new legal notice and the URI changes for security and addressing.
Cheers,
Dave