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

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

I have an action in here that I don't understand - I can't find what it
refers to in my notes.  Does anybody know what requirement this refers to:

> NEW ACTION: Darren to add this requirement to requirements doc.

Thanks,

Darren



> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@east.sun.com]
> Sent: Friday, May 18, 2001 10:53 AM
> To: security-services@lists.oasis-open.org
> Subject: Minutes of 15 May 2001 Security Services TC/Focus telecon
> 
> 
> 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.
> 
> --
> Eve Maler                                             +1 781 442 3190
> Sun Microsystems XML Technology Development  eve.maler @ east.sun.com
> 
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: 
> security-services-request@lists.oasis-open.org
>