RE: Use Cases and Requirements -- Strawman Draft 2

["Ahmed, Zahid" <zahid.ahmed@commerceone.com>]

Here are some quick inputs to the latest Strawman Draft of the 
Use Case Requirements set.

I basically have 2 use cases that seem relevant to include
in the "Group 2: B2B Scenario Variations":

1) B2B Transaction using Message Oriented Middleware and S/MIME
A B2B Transaction oriented scenario using a message oriented
middleware (MOM) protocol, possibly over a secure transport like
SSL, that employs S/MIME to protect the message payload and 
involves a B2B portal exchange that authentictes the message sending 
party via processing of Credential, producing a Named Assertion 
and any applicable entitlements. 

2) B2B Transaction using different protocols
A B2B Document Exchange Transaction that involves two trading
parties such that sending party (e.g., Buyer) uses one
messaging/transport protocol (e.g., OBI) and receiving party 
(e.g., Supplier) uses a another messaging/transport protocol 
(e.g., ebXML). A B2B exchange service provide must provide
relevant interoperability services such that authenticated
Named Assertions and Entitlements can be propagated from one
messaging protocol onto another, preserving the security semantics 
of the the transaction between the two parties across two 
protocols and via atleast one intermediary portal exchange.

3) B2B Transaction over mutliple Portals
Same as Use Case#3 with variation of a multi-hop portal
scenario where the messages may end up traversing over between
possiblly more than 2 intermediary portals, involving two
trading parties.

Last use case was discussed a few ago in the Security Binding
Conf Call.

I can elaborate on both of these use cases further in our Use Case 
tele-conf tomorrow. Furthemore, I'll be happy to formally expand 
on these use cases/issues in the future.

Any comments/feedback welcomed, and sorry for the late response.

thanks,
Zahid

Zahid Ahmed                     Commerce One, Inc.
Commerce Security Architect
email: zahid.ahmed@commerceone.com
v:   (408)-517-3903

-----Original Message-----
From: Evan Prodromou [mailto:evan@outlook.net]
Sent: Friday, February 09, 2001 11:05 PM
To: security-use@lists.oasis-open.org
Subject: Use Cases and Requirements -- Strawman Draft 2


Attached is a copy of the 2nd straw man version of the use cases and
requirements document. It has some fairly significant changes
including the following:

	* Added set of high-level use cases to capture the
	  similarities between many of the scenarios. Maintained a
	  group of detailed use-case scenarios.

        * Changed diagrams of detailed use case scenarios to use
	  interaction diagrams instead of use case diagrams.

        * Added a description of each use-case scenario and list of
          requirements flowing from the scenario.

        * Added draft glossary (as link). Thanks, Jeff!

	* Added issues list (as link). Collected from Darren's
          high-level list and re-formatted. As many issues as have
          come up on 

	* Gave requirements labelled names for easier
          reference.

	* Incorporated and merged requirements list from Core
	  Assertions subcommittee of Oasis Security Services
	  TC (by Philip Hallam-Baker).

        * Corrected various editorial mistakes.

By far, the most text and time have been put into the issues list, and
I encourage people -- no, I BESEECH people B-) -- to check that list
to make sure that 1) issues they have brought up have been addressed
and 2) that the characterization of issues is clear, fair, and
accurate.

If I was to characterize the lifecycle of our output as a
subcommittee, I'd say that we began with an outline and generated a
large number of issues. I think that our next step, before the first
draft that will go to the main TC, is to resolve these issues and
squeeze them back into the main document, as best as possible.

We've talked a bit about how to resolve issues on the list. One part
is breaking up the issues into digestible chunks -- what the issues
list is about -- and posting one email per issue to the list, for
response.

I think the next part we have to decide is how to -resolve-
issues. Perhaps, using Robert's Rules, at some point in the discussion
someone can make a motion that we vote on one or more of the potential
resolutions for the issue, and we can use the evite voting system to
close the items. Another possibility is that someone move that we have
consensus and that we resolve the issue without a vote, unless there's
an objection. (Crumb, looks like I need to read R's R again).

Anyhow, I plan on posting emails for each issue this weekend, to meet
the first requirement. I guess we can talk about resolution at the
next concall.

~ESP