Notes from 1-31-2001

[Evan Prodromou <evan@outlook.net>]

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

~ESP

---8<---

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
diagram.

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
diagrams.

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
requirements.

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

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
resolutions.

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

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,
accountability.

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
list.

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
items.
       
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
specifics.

DO: Add in extensibility requirement. Requirements subsection for
extensibility.

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
sessions?

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,
services.


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