[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Use Cases and Requirements -- Strawman Draft 2
Evan, Thanks for using interaction diagrams instead of the UML(?) dittos. Much nicer! I have some objections to how user authentication is described. IMO it is a process consisting of an arbitrary number of steps. The important thing is that it (at least if we are talking web-browsers) ends in the client's browser as a success or error page (or starts a new set of actions in the source-web that eventually returns to the browser). In the diagrams it seems to end in the source web-site. Regrding this phrase: "Web user requests resource from destination Web site, providing authentication reference", I lack in the interaction diagram that this is an A2ML/OSSML object[it is?] and not just a plain vanilla HTTP GET URL. Regarding the "Issues" document: I would not characterize the modified Push an "AndersRundgren" thing [in spite of being flattering :-)] as I believe that Shibboleth (another non-goal or issue?) is just a tiny (well..) variation. Anders Rundgren The "Pusher" :-) ----- Original Message ----- From: "Evan Prodromou" <evan@outlook.net> To: <security-use@lists.oasis-open.org> Sent: Saturday, February 10, 2001 08:04 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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC