Re: Minutes of 15 May 2001 Security Services TC/Focus telecon

["Eve L. Maler" <eve.maler@east.sun.com>]

Let's try attaching the attendee list this time...

At 01:53 PM 5/18/01 -0400, Eve L. Maler wrote:
>Thanks to Bob Griffin for taking the notes!
>
>
>
>Minutes of the OASIS Security Services Technical Committee telecon
>and the Focus Subcommittee telecon
>15 May 2001
>
>Please note the ACTION items below.  If you see anything that needs
>correction, please reply to this message.
>
>
>Administrative
>==============
>- Membership report: new/removed members
>
>    We didn't get a full report, but we have 58 members.
>
>- Roll call
>
>    Attendance list appears at the end of these minutes.  Quorum reached
>    with 30 voting members.
>
>- Approval of minutes for F2F #2:
>
> 
>http://lists.oasis-open.org/archives/security-services/200105/msg00006.html
>
>    Approved.
>
>- Approval of minutes for the last telecon:
>
> 
>http://lists.oasis-open.org/archives/security-services/200105/msg00040.html
>
>    Approved.
>
>- Approval of/additions to this agenda
>
>    Accepted with insertion of discussion of OASIS Conformance TC as the
>    first item.
>
>
>Discussion of OASIS Conformance TC
>==================================
>Lynne Rosenthal and Mark Skall joined us briefly.  The Conformance TC
>was formed about a year ago, partially in response to the XML/XSLT
>conformance work and the need to share it.  The goal of the TC is to
>share information about conformance in general; it serves as an advisory
>body (white papers, etc. are posted at the NIST website) and it
>represents NIST and OASIS at ebXML meetings.  They also work with W3C on
>quality initiative.
>
>Review the running list of open ACTION items
>============================================
>ACTION: Bob Blakley to develop and circulate a Word template for all
>specification contributors to use. STATUS: no progress yet; try for
>Monday 21 May.
>
>ACTION: Bob Blakley to work with Phill Hallam-Baker to develop the
>simplified architectural model and coordinate it with the proposed
>Core Assertions design. STATUS: BobB understood this as simplification
>of assertion data structures, rather than as model as a whole; about
>done with that.
>
>NEW ACTION: BobB to update assertions based on Phil's doc distributed
>yesterday.
>
>NEW ACTION: All members to review Phill's spec. Phil will be away for
>two weeks; comments should go to the TC list.
>
>ACTION: Bob Griffin to attempt to map the proposed Core Assertions
>design to our requirements.  To be done by 11 May. STATUS: need to
>distinguish two docs (examples and mapping).  Example doc has been
>published by Phill.  (Phill: Pieces are still needed in example doc: for
>example, exactly how you request, particularly for the subject: eg PEP
>might give account name but want common name back.)
>
>NEW ACTION: Conformance group to start reviewing the traceability
>of use cases against Phill's design and release a rough draft for review
>before the next TC telecon.
>
>NEW ACTION: Prateek to do traceability review before the next TC
>telecon.
>
>ACTION: Hal Lockhart to publish a fresh issues list.  New deadline: To
>be done by 18 May.
>
>ACTION: Hal Lockhart and Dave Orchard to update the Architectural
>chapter to reflect F2F #2 decisions.  Hal to update his picture today.
>Dave O to update whole chapter by 11 May. STATUS: put on hold for next
>two weeks. Credential collector and session had been out; pass-through
>authentication has re-opened the question. Gil suggested that session
>should be an overlay picture in any case.
>
>NEW ACTION: Agreement that for now session stuff should be taken out,
>cardinality information and other changes should be done. DaveO to send
>out chapter by Friday 18-May.
>
>ACTION: Jeff Hodges to update the Glossary to reflect F2F #2 decisions.
>New deadline: to be done by 18 May.
>
>ACTION: Darren Platt to update the requirements document to reflect F2F
>#2 decisions and publish as a consensus draft ASAP. STATUS: draft was
>sent last night to security leaders. Eve would like to finalize doc in
>order to make it public; should have group review before wrapping it
>up, hopefully at focus group on Tuesday 22-May.  To be done by 18 May.
>
>NEW ACTION: Eve to create Evite page with F2F #3 information.
>
>NEW ACTION: Prateeek to produce draft of bindings doc to go to whole
>group by Tuesday 22-May.
>
>NEW ACTION: Raj will sent out info on DSML.
>
>NEW ACTION: Dave Orchard to send out URLs for XML protocol related
>to binding.
>
>NEW ACTION: Darren to add this requirement to requirements doc.
>
>NEW ACTION: Hal to add new issues collected at this meeting.
>(Are AnonymitySupport, DisposableValidity, TimeSkew, NameVsHandle, and
>ValidityDependsOn good names?)
>
>NEW ACTION: Prateek will create or point to a use case for
>ValidityDependsOn.
>
>
>Review plans for F2F #3
>=======================
>- Evite poll results: will be 25-26 June in Menlo Park, CA.
>
>- If we don't reach quorum, is a Focus subcommittee meeting
>    acceptable?  We will probably have quorum for that date; if
>    not, OK to do it as Focus subcommittee.
>
>- Goals for this F2F:
>    . Review and approve as much of the design as possible
>    . Assess plans for implementation and conformance
>    . Figure out the end-game schedule
>
>    Eve wants to come out of F2F meeting with design substantially
>    complete; lots of work to do, especially some big decisions. General
>    response was doubt that can make such a goal. Eve: at next F2F have to
>    be brutally honest about going forward, particularly in terms of
>    reaching the September date or slipping 3 months.
>
>    Concern about the quality/completeness of the writing, including
>    issues such as protocol completeness. Hal: trade-off likely to be
>    regarding precision of information in spec.
>
>
>Subcommittee reports
>====================
>- Focus (Eve)
>    Made a recommendation to TC to authorize new subgroup to evaluate
>    pass-through, with Stephen F. as chair (see below). Also info on
>    tutorials on XML sent out by Eve.
>
>- Sessions (Hal)
>    Initial doc by Dave; concall on it last Thursday firming up and
>    agreeing on the requirements.  Also started a section on design
>    goals/tradeoffs, eg timeliness of updates vs efficiency of updates.
>
>- Bindings (Prateek)
>    Had concall last week and week before. In first concall, reviewed a
>    set of slides elaborating those from F2F; one thread is "binding
>    assertions to payloads"; second thread is terminological issue of
>    getting right terms for what binding subgroup is doing (Jeff has
>    circulated draft of this). Next meeting is Thursday noon.
>
>- Conformance (Tim)
>    Status: BobG/Krishna to arrange call this week or next. Goal of
>    strawman by two weeks.
>
>- Considerations (Jeff)
>    Status: no activity published in last week. Has been discussed as
>    context in various subgroups. Jeff has been looking into other
>    information to draw on. Goal of getting something out in next one or
>    two weeks.
>
>
>Liaison reports
>===============
>DSML: new DSML 2.0 proposal.
>
>ebXML: Maryann. Last meeting last week, specifications published to web
>site; ongoing work by steering committee to coordinate across
>organizations; SAML coordination was recommended (messaging
>specification and collaboration protocol subgroups). No significant
>authentication or authorization has been identified yet for ebXML;
>expectation that SAML assertions will need to be bound into payload or
>message.
>
>XML protocol: discussion about actor attribute and "must understand"
>which relates to binding of SAML and SOAP; particularly relevant to
>issues such as routing rules. For example: "Actor = SAML intermediary"
>would mean that SAML intermediary would have to understand some portion
>of the header.
>
>XKMS: workshop on 19 July, same place (San Francisco) as XML encryption
>on 20 July which has been announced; still looking at finding a chair.
>Hal: what is expectation on spec? Phill: workshop goal would be to
>discover whether the spec is complete; also discussion of extensions
>such as bulk load into smartcard, using it with WAP; and discussion of
>aligning with XML protocols will also require some modification to spec.
>
>
>Technical issues to discuss/approve
>===================================
>- Focus subcommittee recommendations:
> 
>http://lists.oasis-open.org/archives/security-services/200105/msg00051.html
>
>    . "We recommend that the TC authorize a subgroup/task force to
>      evaluate a suitable pass-through authN solution for eventual
>      inclusion in V.next of SAML. If the TC likes the design once it
>      is presented, it may choose to open up its scope to once again
>      include pass-through authN in V1.0. Stephen is willing to champion
>      this."
>
>    Moved and seconded. No debate or objections; passed.
>
>    . "Direct the editor of the requirements document (Darren) to
>      indicate that we desire a design where signatures and encryption
>      are optional."
>
>    Discussion: three possible options for signing (none; mandatory;
>    optional) Moved and seconded. No debate or objections; passed.
>
>
>Open mike (new issues)
>======================
>
>- Requirement for anonymous and pseud-anonymous is not met by current
>    assertions doc. At moment, assertions requires that there be a
>    subject. Pseud-anonymous means that identity does not map to real-
>    world identity; question is one of registration; Phill can accommodate
>    this in the design.
>
>    Darren read the two requirements. Pseud-anonymous will be done;
>    anonymous is issue. Should anonymous be supported?
>
>- Hal would like to have a way by which assertion that is valid cannot
>    be cached. Possible issue about time-skew, not met by validity period;
>    when talking about authorization decision assertion, may need to have
>    short life-time where clock-skew is an issue. Would like to have
>    explicit way of calling out that assertion is one-time-only: "one-
>    use". Bob: "Time-of-check to time-of-use problem". (If done by setting
>    validity interval, then if clock is wrong the assertion may not be
>    usable even once.)
>
>- General issue of whether one worries about time-skew is separate from
>    the above issue.
>
>    Prateek: wondering how the object will fit into infrastructure. BobB:
>    what does it mean that assertion can be used only once?
>
>    Hal: PEP gets assertion, with proviso: "if you want to ask about this
>    assertion, ask me again."
>
>
>Adjourn
>=======
>Adjourned at 1:20 pm EDT. Continued with focus group meeting.
>
>
>Focus subcommittee agenda
>=========================
>
>The following list is from Hal, our issues list maintainer.  Please see
>recent discussion on security-services and Phill's new version of the
>core assertions draft:
>
>    http://www.oasis-open.org/committees/security/docs/draft-sstc-core-06.pdf
>
>Phill reviewed what had changed in the Core Assertions draft:
>
>- Filling out the claims section
>- Going through and correcting typos etc.
>- Removed "validity depends upon", based on F2F discussion
>- Expanded explanation of respond element, particularly what kind
>    of assertion is expected
>- Changed subject specification to explicitly specify name of
>    principal or pass credential
>- Two ways of identifying: by name or by something they have. Bearer of
>    the assertion needs to be discussed; is this bearer of the assertion
>    itself (changes when assertion is passed to someone else) or bearer of
>    a ticket (ticket can be used as subject). With syntax currently, can
>    support bearer of assertion; binds to person who can present the
>    private associated with public key or can present a password that
>    matches digest or plain-text password (should allow both).
>
>Name vs. handle issue:
>
>    BobB: three cases are nominative (subject contains name); descriptive
>    (subject contains ticket); indexical (bearer).
>
>    Marlena: for Shibboleth, need user handle. Could use name; but handle
>    is not the same as the name, but rather used to retrieve attributes
>    and can change from day to day.
>
>    Phill: change from nameID to principalID?
>
>    Marlena: handle is not really a principal, since not something which
>    would be put on ACL.
>
>    Hal: way to solve anonymity problem? BobB: also solves other things;
>    solving anonymity is part of larger "how to we refer to subjects in
>    assertions problem".
>
>    Phill: in terms of datatypes, one of them was Unicode name of subject,
>    useful when you want to put subject's name up in page saying welcome
>    etc; the other is some means of machine identifier (perhaps make
>    element name more neutral, something like subjectID). Doesn't need to
>    be long-term identifier of principal, but must be a member of the set
>    identified for the duration of the validity interval.
>
>    Eve: can name be bound to short-term handle?
>
>    Phill: as long as the binding of name to handle is ok for the validity
>    period of the assertion.
>
>    Marlena: need handle to link up request/response.
>
>    Phill: proposal is that nameID element (type URI) remains type URI but
>    renamed subjectRef (analogous to HREF), and we write a section how to
>    use that with handle, with account name and so on.
>
>    BobB: and distinguished value meaning bearer of assertion.
>
>    Phill: might need to register URN types.
>
>    Hal: other than anonymity, are there other important requirements
>    being met?
>
>    BobB: question uppermost is "we have to refer to subject in
>    assertions; even if we don't address anonymity; there are reasons to
>    do things like bearer refs that don't have to do with anonymity; so we
>    need to keep in mind anonymity when designing schema that supports
>    referring to subjects, but larger issue is that we don't have a design
>    for referring to subjects.
>
>
>Discussion of "Validity depends on" issue:
>
>    Prateek: assertion could be generated in pieces; with attribute
>    assertion pointing to authentication assertion. How would this be
>    accommodated?
>
>    Phill: point raised at F2F is that if validity is not in scope, then
>    validity-depends-upon in not in scope either. (?)
>
>    Hal: could have a bunch of assertions that all refer to same subject;
>    using same subject would tie them all together?
>
>    Phill: yes, having same subject is way this issue would be addressed.
>
>    Hal: a single assertion that had a bunch of claims would be equivalent
>    to a bunch of assertions with a single claim each.
>
>    Prateek: need to check this against the use cases.
>
>    Marlena: don't have a use case for this; however, could be a case
>    where you get an attribute from one authority only if another
>    attribute was obtained from another authority.
>
>    Hal: if you want to say a is true if b is true, but cannot revoke b,
>    what value is the syntax? BobB: yes, don't have a fully-formed set of
>    rules.
>
>    Prateek: atomic assertion validity; on top of that, some assertions
>    might depend on others (a composite form).
>
>    BobB: objection is that the only way to get a NO response is they go
>    out of time scope.
>
>    Carlisle: another case is that depending assertion can't be verified
>    (essentially doesn't exist for the party verifying the assertion).
>
>    Marlena: by value vs by reference assertion.
>
>    BobB: have to evaluate assertion guts.
>
>    Marlena: yes, will be necessary in some cases.
>
>    Hal: relying party is free to have policy that requires a,b,c to be
>    true; asserting party wants to be sure that no one uses this info
>    unless other assertion is true.
>
>    BobM: expressing policy?
>
>    Prateek: attributes that are conditioned on authentication act?
>
>    Marlena: could also be on other attributes.
>
>    Carlisile: doesn't have to refer to an assertion.
>
>    Phill: keen on "depends-on"; but doesn't make sense unless we have the
>    other piece. Plan to address this later version? Other piece is we
>    need a general mechanism for tracking assertion status, such as
>    revoking assertions.
>
>    Carlisle/Prateek: no, depends on does not require revocation.
>
>    Prateek: change in SAML core assertions is causing debate in removing
>    of "depends-on" element.
>
>    Marlena: depends-on does not have to be on assertion. If you had a
>    time of under 3 hours in NY marathon, get to be in Boston marathon.
>
>    Hal: need use case.
>
>    Prateek: need to distinguish depends-on for assertion (reference to an
>    assertion) vs extension where depends-on anything else.
>
>    DaveO: risk here of circularity?
>
>    Prateek: may need to constrain number of levels, recursion, etc.
>
>
>Discussion of XMLAssertionGenerality (aka "top vs. bottom"):
>
>    Hal: why bottom-up makes him uneasy? If we assume we can have
>    authorization decisions that might not mention a subject, but some
>    attribute that might be shared, then suppose someone sends assertion
>    that has Joe/DR/access=fileX. Asserting party might have meant
>    something different from what receiver understands, because the
>    assertion does not define itself as authorization assertion or
>    authorization decision assertion. Semantic ambiguity is caused by not
>    distinguishing the kinds of assertion.
>
>    Eve: same guts could apply in different ways, if assertion types are
>    distinct.
>
>    Phill: way to distinguish is whether role is subject or object. At
>    moment, explicitly cannot specify role as subject; may need to remove
>    this in order to satisfy anonymity?
>
>    Marlena: don't need to put role into subject; too close to expression
>    of policy.
>
>    Phill: no way of saying that doctors are allowed to access file; that
>    is policy.
>
>    Hal: unidentified person is doctor, then in effect have said that all
>    doctors can access file.
>
>    Phill: no, issue of how the assertion is used.
>
>    BobB: "clairvoyance" concern. To write top-down, understand only what
>    input to provide; to write bottom-up, have to know a lot about answer
>    in order to ask the right question.
>
>    Eve: sentiment running against "bottom-up"? Not clear yet. Need
>    concrete examples of problems; want to explore what is truest to all
>    of our requirements and goals.
>
>    Phill: would like to see concrete example of problem caused by bottom-
>    up.

Voting members:
Gavenraj        Sodhi
Stephen         Farrell
Ken             Yagen
Hal             Lockhart
Fred            Moses
Ed              Simon
Carlisle        Adams
Alex            Berson
Bob             Griffin
Nigel           Edwards
Jason           Roualt
Maryann         Hondo
Kelly           Emo
Dave            Orchard
Gilbert         Pilz
Marc            Chanliau
Prateek         Mishra
Jeff            Hodges
Charles         Knouse
Evan            Prodromou
Darren          Platt
Jahan           Moreh
Eve             Maler
Ron             Monzillo
Mark            Vandenwauver
Bob             Blakley
Marlena         Erdos
Bob             Morgan
Phill           Hallam-Baker
Tony            Palmer

Prospective members:
Thomas          Hardjono
Larry           Hollowood
Mark            O'Neil
Pramod          Pathak

Observers:
Lynne           Rosenthal
Mark            Skaal
--
Eve Maler                                             +1 781 442 3190
Sun Microsystems XML Technology Development  eve.maler @ east.sun.com