wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsrp] EventDescription.requiresSecureDistribution
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Wed, 15 Dec 2004 13:07:32 -0500
It was commented at the F2F that much
as we have these fields relative to markup, we would need them for events.
Without much discussion, everyone agreed and my notes say to add the fields.
I think the following may provide a base use case for them:
A Consumer incorporates a pair of remote
portlets (P1 & P2) on a page where:
P1: The Producer only offers unsecure
ports (e.g. http)
P2: The Producer only offers secure
ports (e.g. https)
1. If P2 generates an event that does
not require secure communication during distribution, how to tell the Consumer?
2. If P1 generates an event that it
determines does need secure communications and determines it can securely
send it to the Consumer (either by network topology or message security),
can it insist that it only be distributed in a secure manner?
Obviously a Producer offering both types
of ports just complicates the logic (but not the fundamental questions)
by throwing in the question of whether of not the transport layer will
make the current communications with the Consumer secure. Message level
security just adds another equivalent wrinkle to the logic side of things.
I think both of the above situations
will happen and that the protocol should make it easy to signal to the
Consumer the security concerns related to distributing an event. I suppose
we could remove the field from the event description and require on the
event, but this would move valuable information from design time to runtime.
Rich
Andre Kramer <andre.kramer@eu.citrix.com>
12/15/2004 11:52 AM
|
To
| wsrp@lists.oasis-open.org
|
cc
|
|
Subject
| RE: [wsrp] EventDescription.requiresSecureDistribution |
|
A producer that wishes to return
an event securely can not publish a http binding (i.e. only an https binding
so that SOAP responses are secured) if transport level security is to be
used, or use message level security for responses. Given we start from
this position, is it not more a question of the producer possibly granting
the consumer the right to forward an event on a less secure channel? How
useful is such a feature as opposed to just mandating that a securely returned
event be always forwarded securely? I think the end goal should be for
end to end security to be used to secure the event payload so do we really
need these flags?
Regards,
Andre
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 15 December 2004 15:07
To: wsrp@lists.oasis-open.org
Subject: Re: [wsrp] EventDescription.requiresSecureDistribution
Rereading this on the OASIS distribution reminded why the event field did
not have a default specified in the schema ... its default is whatever
was specified in the EventDescription.
Rich
Rich Thompson/Watson/IBM@IBMUS
12/15/2004 09:20 AM
|
To
| wsrp@lists.oasis-open.org
|
cc
|
|
Subject
| Re: [wsrp] EventDescription.requiresSecureDistribution |
|
Good point on the possibility of tampering ... I'll add a sentence in section
9 of draft 04 to point this out.
The reason the field exists in both places is that some events will always
require secure distribution and some will only require it when sensitive
information is being carried in the payload (i.e. dynamic payload contents).
We deliberately named the equivalent fields in v1 as simply requiring security.
This allows evolving security standards to be used as they become supported.
Thanks for catching the .xsd overlook of the default value. Has been updated
relative to the next version.
Rich
Andre Kramer <andre.kramer@eu.citrix.com>
12/10/2004 05:15 AM
|
To
| wsrp@lists.oasis-open.org
|
cc
|
|
Subject
| [wsrp] EventDescription.requiresSecureDistribution |
|
We should note that basing
security decisions
on
EventDescription.requiresSecureDistribution
only makes sense if the EventDescription
was itself was
retrieved securely.
The
threat
here
being
Tampering.
I do not
see why we would want to
duplicate
the flag in the Event
type itself, even if we include it in
the event
metadata.
IMHO
A consumer should either use (securely
determined) metadata to
determine
the security level
for event transmission
or use the same security level
at which an event was received to re-distribute
the event (Event.RequiresSecureRedistribution?).
Would it be simpler to use the same rule as
for getMarkup to distribute all events? i.e.
If a producer
publishes a secure binding (i.e.
SSL) then the consumer should make use
of it? Or, better, provide
and encourage
means for the event data to be signed/encrypted
by sending portlets?
Regards,
Andre
PS.
In any case,
the
Event.requiresSecure(Re)Distribution declaration
XML
schema
could do with a default="false"
to match the
EventDescription convention.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]