RE: Use Cases and Requirements -- Strawman Draft 2

[Darren Platt <dplatt@securant.com>]

Thanks, Ahmed.  You'll have to forgive me if I don't have any comments on
these right now, as I've been concentrating on the first few issue groups we
have decided to try to resolve - 1 (SSO), 3 (sessions), and 5 (AuthC
protocols).  Once we have come to some resolution on these areas, I'll bet
we'll choose to work on Group 2 next.

This input will no doubt be very useful then, and I look forward to
benefiting from your expertise in this area.  In the meantime we should
start tracking these scenarios on the issue list.  You suggested that you
could provide more details - could we ask that you please do so, perhaps
providing interaction diagrams if possible, so that we can add them to the
issue list for Strawman 3?

Regards,

Darren





> -----Original Message-----
> From: Ahmed, Zahid [mailto:zahid.ahmed@commerceone.com]
> Sent: Tuesday, February 13, 2001 3:02 AM
> To: 'Evan Prodromou'; security-use@lists.oasis-open.org
> Cc: 'Darren Platt'; 'security-bindings@lists.oasis-open.org'
> Subject: RE: Use Cases and Requirements -- Strawman Draft 2
>
>
> 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
>