RE: Minutes of 18-19 April 2001 Security Services TC F2F #2

["Platt, Darren" <dplatt@securant.com>]

Hi all-

The 'only' action I got coming out of F2F2 was: 

> ACTION: Darren Platt to update the requirements document to 
> reflect F2F #2 decisions and publish as a consensus draft ASAP.

I just want to make sure that I have the same idea as to what this means as
everybody else.  I only see one thing in the minutes which requires a change
to the requirements doc, so I wanted to double-check with you.  It's related
to the session requirement - basically to apply the sentiments of the group
represented by the following polling:

 
> The TC extensively discussed the various issues related to sessions
> (including login, logout, timein, and timeout).  The notion of a
> session is baked into the validity interval idea, but some were
> advocating "rich" or "dynamic" sessions, where significant session
> state is stored.  Others felt that some aspects of this design problem
> presented significant schedule risk.  Phill Hallam-Baker presented a
> strawman design that would allow "pull" timeout, but not "push"
> timeout.  We did some straw polls to determine the sense of the body.
> 
> STRAW POLL (1->5): On a scale from 1 to 5, how comfortable 
> are you with
> the statement "We must finish by about September"?
> 
> 1  2  3  4   5
> 1  0  6  1  10
> 
> STRAW POLL (1->5): On a scale from 1 to 5, how comfortable 
> are you with
> the statement "If we fail to solve logout, then solving just login is
> acceptable"?
> 
> 1  2  3  4   5
> 4  5  2  1  14
> 
> STRAW POLL (Quaker): Out of the following choices, which *one* do you
> prefer most?  Which (one or more) can you live with?
> 
> 1. Finish assertions and transport (protocol and bindings) work
>     only by the September timeframe.  Do no prep work to ensure that
>     sessions will work with SAML 1.0.
> 
> 2. #1 plus do the prep work to ensure that sessions will not be
>     precluded from working with SAML later; commit to doing login and
>     logout design "next" after 1.0.
> 
> 3. #2 plus include a design for login, and do the prep work to
>     ensure that logout, timein, and timeout will not be precluded from
>     working with SAML later; commit to doing these other pieces "next"
>     after 1.0.
> 
> 3.5. #3 plus include a design for timein; accept the increased
>       schedule risk.
> 
> 4. Finish the design for assertions, transport, and full session
>     support and plan on finishing later than September.
> 
>           Prefer       Live with
> 1          0             11
> 2          4             22
> 3         18             23
> 3.5        2             12
> 4          2              9
> 
> MOTION: Should we accept option #3?  PASSES 25-5.
> 
> Jeremy Epstein stepped down as Security and Privacy Considerations
> subgroup chair, replaced by Jeff Hodges.
> 
> The TC agreed that the new Focus subgroup would meet on the weeks that
> the TC is not meeting, for two hours.  Eve Maler agreed to 
> act as Focus
> chair.
> 
> ??QUESTION??MOTION: Should we accept the Use Case report and direct
> the editors to insert appropriate non-goal language?  PASSES 
> 26-0 (with 4
> abstentions).

I think the only clear results are in the last poll, and the best way to
reflect that would be to basically take option 3 and represent it as a goal,
and options 4 and 5 as non-goals.  Here's a shot at it:

[R-UserSessionLogin] The SAML specification shall include support for the
Login scenarios described in Scenarios 1-1, 1-2, and 1-3 of the requirements
doc.  

[R-UserSessionLogout] In creating the SAML specification the TC will do the
prep work to ensure that logout, timein, and timeout will not be precluded
from working with SAML later, and commit to doing these other pieces "next"
after SAML 1.0.

[R-UserSessionsWillNotScrewThePooch] The TC will not design timeout/logout
mechanisms for the September release date because of schedule risk.

I will also need to change the second Scenario 1-3 to be 1-4 :).  I didn't
think I should remove the logout from this scenario (which will now be
called 1.4), as I believe that part of the work which needs to be done to
satisfy the second requirement above.  I realize that there may be other
opinions, though, and so ask for your feedback.

Thanks, and sorry for the delay,

Darren





> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@east.sun.com]
> Sent: Thursday, May 03, 2001 11:19 AM
> To: security-services@lists.oasis-open.org
> Subject: Minutes of 18-19 April 2001 Security Services TC F2F #2
> 
> 
> Minutes of OASIS Security Services Technical Committee F2F #2
> 18-19 April 2001
> 
> Thanks to Gavenraj Sodhi, Kelly Emo, and Gil Pilz for contributing to
> these minutes!  I have attached their raw notes, which 
> contain blow-by-
> blow descriptions of the proceedings.  Below I focus on the high
> points, straw polls, votes, and action items as an official record.
> If you have any corrections, please submit them as responses to this
> message.  Please note that there is a ??QUESTION?? about one of our
> votes below; I would appreciate hearing from those who recall the vote
> and its circumstances.
> 
> 
> Administrative
> ==============
> - Roll call
> 
>     Attendance list and membership status update appear at the end of
>     these minutes.  Quorum reached.
> 
> - Approval of minutes for the last telecon:
> 
>    http://lists.oasis-open.org/archives/security-
>    services/200104/msg00005.html
> 
>    Approved.
> 
> - Approval of/additions to this agenda
> 
>    Approved.
> 
> 
> Use Case and Requirements subgroup report
> =========================================
> Darren Platt reviewed the requirements document and the status of the
> outstanding issues.  Of 60 issues, 32 reached consensus (specially
> defined for that subgroup to mean 75% positive votes).  Several
> proposed scenarios (such as all the ebXML-related ones) did not make
> the cut, in some cases because they were too detailed.  There is
> interest in reworking and resubmitting some of these [we used the open
> mike session to list "live" issues].
> 
> Hal Lockhart presented the latest producer/consumer model.  The TC
> noted that the session part of the model was relatively unconnected to
> the rest, and there were questions raised about what Credentials
> Assertions contain.  These areas of the model are in flux because of
> pending decisions that we hope to take at this meeting [which we
> ultimately did].
> 
> Core Assertions/Protocols subgroup report
> =========================================
> Phill Hallam-Baker presented the beginnings of the assertion design
> work.  He noted that the subject/action/object structure was RDF-like.
> Some questions were raised about whether specific pieces (such as the
> Conditions element) satisfied specific requirements; in the case of
> Conditions, Phill said it met the extensibility requirement.  The TC
> discussed the need to have XML-vocabulary versioning information in
> assertions somehow; Eve mentioned current thinking among XML wonks on
> how to do this.  The TC discussed issues with allowing 
> references to be
> indexical (defined by context) instead of nominative 
> (explicitly naming
> the referent in some fashion); this was summarized as the difference
> between "dumb tokens and smart protocols" vs. "smart tokens and dumb
> protocols."  Some people mentioned a concern that the design is overly
> PKI-centric.
> 
> Carlisle Adams, presenting for Tim Moses, covered the Protocol section
> with an eye towards spelling out the assumptions in it; those that
> elicited significant discussion are highlighted here.  One assumption:
> that the AuthZ Decision Assertion is effectively eliminated because a
> binary "yes" vs. "no" could be conveyed by parroting back the question
> that was asked.  Several people were concerned that this eliminates
> "really dumb PEPs" as a possibility.  Another assumption: that the
> schema presented in this section is just a guideline for the bindings
> work.  This touched off a discussion about "enveloped" vs. 
> "enveloping"
> SAML messages and expectations about whether the SAML schemas will be
> normative; there is a definite desire to be normative wherever
> possible. There's some trickiness around parts of SAML messages that a
> particular binding pulls "out of band"; we wouldn't want the XML field
> to be truly optional, but rather switchable somehow per binding.
> Finally, the Protocol section outlined a method for forming SAML
> queries that is template-based.  This seemed to find favor 
> with several
> people.
> 
> 
> Editorial report
> ================
> Bob Blakley described how he produced the SAML specification draft,
> requirements document, and issues list document.  He exhorted
> contributors to adhere strictly to the document guidelines, to use
> vanilla Word styles, and to supply PowerPoint versions of graphics.
> 
> 
> Bindings subgroup report
> ========================
> Prateek Mishra presented the current status.  They intend to 
> define two
> kinds of bindings, assertion bindings and service bindings. It also
> intends to develop a framework for describing and registering proposed
> bindings; the TC had some issues with this, suggesting that this would
> make the dependencies with other efforts run the wrong way 
> and that our
> bindings should be normative wherever possible. The subgroup has
> contributed some requirements to the requirements document. We
> discussed some of the constraints imposed by the web browser/SSO use
> case, such as small cookie sizes (for intranet use) and the need to
> cram everything onto a URL line (for cross-domain use).  It was
> suggested that a set of "use case scenarios" that cross all our
> intended bindings (while keeping the other details as identical as
> possible) would be useful.
> 
> Jeff Hodges spoke briefly on BEEP (RFC 3080 and 3081), which is
> essentially a framework for application protocols.
> 
> 
> Conformance subgroup report
> ===========================
> Bob Griffin presented the current status for Krishna Sankar.  This
> subgroup is just getting started.  They plan to review the SAML spec
> for clarity of normative vs. non-normative material, to document
> conformance guidelines, to develop (or possibly just coordinate the
> development) of a conformance suite, and to work with other efforts to
> promote interoperability and adoption.  The TC commented that
> interoperability is the ultimate desire of all, so "conformance"
> without this wouldn't be too helpful.  While having too many options
> would harm interoperability, several ideas were raised for 
> levels/types
> of conformance we might have to have: for each type of authority, for
> each type of binding (possibly with a "floor" of required bindings),
> and for assertions vs. the protocol/binding aspects of SAML.
> 
> 
> Open Mike Session and Issues Resolution
> =======================================
> MOTION: Should the TC enter into a committee of the whole to do the
> open mike session?  PASSES 30-0.
> 
> The TC held an "open microphone" session, in which everyone had a
> chance to speak for five minutes and raise as many issues as they
> wanted.  We agreed in principle that any still-open issue in the Use
> Case and Requirements issues list *not* raised during this session
> would be considered to be closed, so that we could gain consensus on
> the requirements document during the F2F.  The issues were recorded,
> and in the recess between meeting days, the group leaders categorized
> them.  Highlights included:
> 
> - Much support for defining a very simple design and *then*
>    optimizing it (DarkNightOfTheSoul aka SimplifyFirst)
> 
> - A need for "design traceability" back to requirements
> 
> - Many people weighing in on the session question, e.g. signon
>    being not interesting enough if signoff isn't also included
> 
> - People raising issues with the amount of cross-communication
>    among the subgroups
> 
> MOTION: (ShouldWeDoSAML) Should we continue to do the work of 
> the OASIS
> TC to define the SAML specification?  PASSES 30-0 (with 1 abstention).
> 
> MOTION: (TCStructure) Should we dissolve the Use Cases and 
> Requirements
> subgroup and the Core Assertions/Protocols subgroup and in their place
> have a "Focus" subgroup that tackles the remaining issues and work in
> this area, with the TC in more of an oversight role?  PASSES 
> 26-3 (with
> 1 abstention).
> 
> MOTION: Should the TC accept the requirements document, except for
> issues raised during the open mike session?  PASSES 30-0.
> 
> The TC extensively discussed the various issues related to sessions
> (including login, logout, timein, and timeout).  The notion of a
> session is baked into the validity interval idea, but some were
> advocating "rich" or "dynamic" sessions, where significant session
> state is stored.  Others felt that some aspects of this design problem
> presented significant schedule risk.  Phill Hallam-Baker presented a
> strawman design that would allow "pull" timeout, but not "push"
> timeout.  We did some straw polls to determine the sense of the body.
> 
> STRAW POLL (1->5): On a scale from 1 to 5, how comfortable 
> are you with
> the statement "We must finish by about September"?
> 
> 1  2  3  4   5
> 1  0  6  1  10
> 
> STRAW POLL (1->5): On a scale from 1 to 5, how comfortable 
> are you with
> the statement "If we fail to solve logout, then solving just login is
> acceptable"?
> 
> 1  2  3  4   5
> 4  5  2  1  14
> 
> STRAW POLL (Quaker): Out of the following choices, which *one* do you
> prefer most?  Which (one or more) can you live with?
> 
> 1. Finish assertions and transport (protocol and bindings) work
>     only by the September timeframe.  Do no prep work to ensure that
>     sessions will work with SAML 1.0.
> 
> 2. #1 plus do the prep work to ensure that sessions will not be
>     precluded from working with SAML later; commit to doing login and
>     logout design "next" after 1.0.
> 
> 3. #2 plus include a design for login, and do the prep work to
>     ensure that logout, timein, and timeout will not be precluded from
>     working with SAML later; commit to doing these other pieces "next"
>     after 1.0.
> 
> 3.5. #3 plus include a design for timein; accept the increased
>       schedule risk.
> 
> 4. Finish the design for assertions, transport, and full session
>     support and plan on finishing later than September.
> 
>           Prefer       Live with
> 1          0             11
> 2          4             22
> 3         18             23
> 3.5        2             12
> 4          2              9
> 
> MOTION: Should we accept option #3?  PASSES 25-5.
> 
> Jeremy Epstein stepped down as Security and Privacy Considerations
> subgroup chair, replaced by Jeff Hodges.
> 
> The TC agreed that the new Focus subgroup would meet on the weeks that
> the TC is not meeting, for two hours.  Eve Maler agreed to 
> act as Focus
> chair.
> 
> ??QUESTION??MOTION: Should we accept the Use Case report and direct
> the editors to insert appropriate non-goal language?  PASSES 
> 26-0 (with 4
> abstentions).
> 
> The TC discussed the Architectural chapter in detail and collected
> comments for the editors:
> 
> Static model requests:
> 
> - If possible, separate out into two diagrams, one for containment
>    and one for other relationships.  (See Bob Blakley with questions.)
> 
> - Fill in the rest of the cardinalities and make sure that every
>    edge is labeled.
> 
> - Update terminology in diagram.
> 
> - Add prose explaining that the term "user" stands in for additional
>    examples that are not human, including parties and processes.
> 
> - Remove the abridged glossary.
> 
> Producer/consumer model requests:
> 
> - Remove the credential collection stuff entirely.
> 
> MOTION: Should we avoid "target" (except as a regular English 
> word) and
> "system resource" and use simply the word "resource"?  PASSES by
> unanimous consent.
> 
> The TC discussed the Glossary and collected comments for the editor:
> 
> - Make appropriate changes to "target", "system resource", and
>    "resource".
> 
> - Try using/defining "validation of binding" to mean authentication
>    of the binding of an assertion to a request.  Consider a 
> note saying
>    to avoid the term "authenticator."
> 
> - Define single sign-on (possibly as a marketing term conveying a
>    user experience).  Define login, logout, timein, keep alive,
>    and timeout.
> 
> - Define "session" and "rich session."
> 
> 
> Summary of ACTIONS taken
> ========================
> ACTION: All F2F #2 presenters to send their slides to Eve Maler.
> 
> ACTION: Eve Maler to stop the security-use and security-core lists but
> keep the archives. [DONE]
> 
> ACTION: Eve Maler to effect changes to security-consider and security-
> leaders lists. [DONE]
> 
> ACTION: Eve Maler to set up regular Focus subgroup telecons. [DONE]
> 
> ACTION: Eve Maler to get Sessions subgroup chairmanship initialized.
> [DONE]
> 
> ACTION: Eve Maler to update the group, meeting, and membership pages
> with changes as necessary.
> 
> ACTION: Bob Blakley to develop and circulate a Word template for all
> specification contributors to use.
> 
> ACTION: Bob Blakley to work with Phill Hallam-Baker to develop the
> simplified architectural model and coordinate it with the proposed
> Core Assertions design.
> 
> ACTION: Bob Griffin to attempt to map the proposed Core Assertions
> design to our requirements.
> 
> ACTION: Eve Maler to give open mike issues to Hal Lockhart. [DONE]
> 
> ACTION: Hal Lockhart to take over maintenance of the issues list and
> add the open mike issues, ideally with publication of the revised list
> before the next official TC meeting.
> 
> ACTION: Hal Lockhart and Dave Orchard to update the Architectural
> chapter as indicated above.
> 
> ACTION: Jeff Hodges to update the Glossary as indicated above.
> 
> ACTION: Darren Platt to update the requirements document to 
> reflect F2F
> #2 decisions and publish as a consensus draft ASAP.
> 
> 
> Attendance and membership report
> ================================
> Lost membership as a result of missing this meeting:
> 
> Michah   Lerner         AT&T
> 
> New members as of the end of this meeting:
> 
> Valerie  Beaubien       Netegrity
> Gavenraj Sodhi          Access360
> 
> Voting members who attended this meeting:
> 
> Bill     Perry          Aventail
> Irving   Reid           Baltimore
> Ken      Yagen          CrossLogix
> Brian    Eisenburg      DataChannel
> Hal      Lockhart       Entegrity
> Fred     Moses          Entitlenet
> Carlisle Adams          Entrust
> Alex     Berson         Entrust
> Robert   Griffin        Entrust
> Joe      Pato           HP
> Maryann  Hondo          IBM
> Kelly    Emo            Jamcracker
> David    Orchard        Jamcracker
> Gilbert  Pilz           Jamcracker
> Alan     Brown          Microsoft
> Marc     Chanliau       Netegrity
> Prateek  Mishra         Netegrity
> Jeff     Hodges         Oblix
> Charles  Knouse         Oblix
> Michael  Lyons          OpenNetwork
> Mark     Griesi         OpenNetwork
> Evan     Prodromou      Outlook
> Darren   Platt          Securant
> Eve      Maler          Sun
> Ron      Monzillo       Sun
> Bob      Blakley        Tivoli
> Marlena  Erdos          Tivoli
> Bob      Morgan         UWashington
> Phillip  Hallam-Baker   Verisign
> Jeremy   Epstein        webMethods
> 
> Others who attended this meeting:
> 
> Gavenraj Sodhi          Access360 (prospective member)
> Bill     Pope           Bowstreet (prospective member)
> Steven   Carmody        BrownU (observer)
> Sekhar   Vajjhala       Sun (observer)
>