OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Notes from 1-31-2001

Not formal minutes, but a set of notes. I'll try to boil this down to
decisions made and important points.



1. Agenda Bashing

2. Attendance

Bob Blakley
Evan Prodromou
Darren Platt
Nigel Edwards
Jeff Hodges
Kelly Emo
David Orchard
Robert Griffin
Bob Morgan
Prateek Mishra
Taylor Boon
Hal Lockhart

3. Notation/Format

        - Interaction Diagrams?

HL questioned use of use case format rather than interaction
diagrams. Discussed previously between DP and EP.

DO: recommend using both formats. Interaction diagram and deployment

BB: What are we intending to convey? Interaction diagram imposes
intended solution on the reader.

BM: A lot of mechanism, need to have more high-level coverage.

PM: Use-cases are bound too closely to usage.

BM: Recommended to make info to other subgroups.

DO: Where to capture design issues? Models (pull, push) are more
important to entire TC than to one subgroup.

HL: Some design, data flow is part of the use cases.

BB: Use case names are better for indicating interactions than

JH: Two layers of abstraction mixed together. Core list has some good
requirements already going.

DO: Core assertions committee is now "core committee."

HL: Core carries much of the semantics.

DP: Bob Blakley should coordinate this effort.

BB: More for the rest of the group.

HL: Need to have sufficient detail to say what's in and what's out.
Should be useful for driving design.

BB: F2F will be a good mechanism for merging and rationalizing

DP: Restructure: high-level use case, interaction diagrams side by

DO: Add req'ts, and indicate if all designs meet all req'ts.
Different scenarios have different requirements. 

KE: Need req'ts for justifying design decisions.

JH: Add in Shibboleth requirements, delta of requirements.

DO: Grouping of requirements, categorized.

HL: Difference between use case and scenario?

DO: Use case: single sign on, single sign-off, timeout. Scenarios:
more fine grained.

BB: Use case: activity from user's point of view. Scenario: more info
on how system works.

DO: Use cases first, req'ts second. Mark req'ts by # (R1, R2).

        - Abbreviations - Please, Please Don't Use 'Auth'!!!

DP: "Auth" is difficult as part of discussion, can't differentiate
authentication and authorization.

BB: AuthN, AuthZ. (Ac and Az are too close, sound the same).

HL: Glossary?

BB: Glossary is an appendix for full document.

JH: Glossary in the works. Can get it to work by next week (week of
the 4th).

BB: Covers PDP, PEP?

JH: Internal doc, added to the group.

BB: AznACI glossary, others to be added.

BB: Don't invent new terminology unless.

        - Open issues section

DO: Issues and notes. Document notation issues.

HL: Keeper of issues.

DO: Some XML format for storing issues and notes. Markup that links
issues with parts of document.

DP: Issue section with names (champions) involved.

DO: Issues should be listed where they occur in the document. Have all
issues referenced at end, embed issues in body, with possible

JH: Issue suggesters list as co-authors. Hal keeps issues, forwards to

DP: Considers issues part of role.

DO: Label issues, issue tracking will cascade to other sub-committees.

BB: Authors and contributors?

JH: Co-author should be used like in IETF -- all people with
significant contributions are authors.

BB: Authorship question should go to Karl Best of Oasis.

DO: There are subtle distinctions between editors, contributors,
w.g. members. Separate sections for each level of contribution.

TM: Anonymous authorship?

PM: Adding names to document gives group lead some responsibility,

JH: Seems like consensus is that W3C-style.

4. Suggestion roll call - 'Triage'

DP: Go over the issues submitted the security-use list. Also, need to
point out this info to the full TC. All suggested use cases should
come to security-use.

NE: Need to get PH-B's issues into security-use.

EP: Question: is it time to submit the straw man?

PM: Idea is to make a point of having work come in from TC, make
security-use a single point of contact.

JH: Objection, there is an artificial difference between separate
mailing list.

DO: Surely use case and req'ts discussion should occur on use-case

BB: Copy overlap issues to main list.

DP: Bring up issues on main list, discussion stuff on use case list.

BB: How will we bring in other req'ts issues?

HL: Have chairman ask for submissions on TC list.

[general consensus]

DP: Summary: make an announcement asking people to join the
list. Major questions should be sent to DP for people not on list.

BM: BM and DO should pull out use-case and req'ts stuff and re-send
them to use-case list.

DP: Make announcements of particular issues discussion on TC list.

DO: Need to make another document that has a minority report, rejected
EP: Separate documents for minority objections?

DO: Yes.

        - Identify Major Threads/Related Issues

DP: Triaging issues, not full discussion of issues.

HL: Give list of issues, not to full discussion.

DO: Call for missing issues?

DP: Ask for written issues rather than spoken issues, not full detail
of items.

[Ask Darren for list].

DO: AuthZ information in with AuthC data? Extension.

DP: Try to keep focussed on issue listing & grouping, not on

DO: Add in extensibility requirement. Requirements subsection for

DP: Enveloped vs. enveloping assertions/messages.

PM: What is this req't?

DO: AXCES message can be embedded in other document, or does AXCES
envelop other document.

BB: Asks for more detail on this issue, use of terms tokens,
assertions, messages.

MH: Submit ebXML issues to the list.

DP: Schedule calls for disagreements?

BB: Need to have discussions on-list about disagreements.

DP: Continue discussion of issues?

General: DP to send a strawman issues list.

PM: Are we going to further discuss issues? What about the notion of

PM: Do we need to add services information?

DO: Parallel with XML Protocol, services definitions included.

DO: Use case for adding services to the framework?

PM: Two major issues: sessions and security services.

5. Plan next meeting and next steps.

DP: 11 PST Monday 5 Feb 2001. Particular discussion of sessions,

DP: EP to send out minutes, DP to send out outstanding issues list. 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC