[security-services] Minutes for Telecon, Tuesday Jan 22, 2002

[sanderson@opennetwork.com (Steve Anderson)]

Minutes for SSTC Telecon, Tuesday Jan 22, 2002
Dial in info: +1 334 262 0740 #856956
Minutes taken by Steve Anderson


>
> 1 -- Roll Call
>

- Attendance attached to bottom of these minutes
- Quorum achieved.

>
> 2 - Process Issues
>
> Handling comments during the next few weeks:
>         * comments from at-large reviewers will be treated as if they
>           are part of the last call review set.
>         * comments need voting member champion in the meantime.
>

- No objections to new model
- Champions must be voting members
- Hal: editorial comments need not be issues
    - Currently no basis for determining what is editorial vs.
      functional
- Joe: determination to be made initially by person making comment
- Jeff H: may take some coordination to determine status as true issue
- Joe: commentors must ensure that true issues not get buried in larger
  messages involving editorial comments
- Hal: create new threads for separate issues
- Jeff H: would like pointers in issues list to mail list entry

>
> Conference Calls:
>
> Do we need additional calls this week and next to reach last-call
> closure?
> Friday 25-Jan? Thursday 31-Jan?

- Candidate dates.  We�ll see where we get today.

>
> Document Review
>        * This is essential to step up this week.
>

- Joe: asking folks to set aside time to review and comment this week

>
> 3 - Issues to Discuss
>
> A) Prateek's suggestion to de-couple SOAP profile from binding doc.
>    ([security-services] SOAP Profile of SAML vs WS-Security: Summary
>    and an Action Plan)
>

- Bindings group has not had chance to respond to MS�s new proposals
- This doesn�t make our work redundant
- Proposes that we separate SOAP profile and deal with it later, after
  completing analysis of MS�s proposals
- Phill: doesn�t think WS-Security will get on W3C agenda before April
- Joe: strongly favors Prateek�s proposal
- Jeff H: also agrees
- Hal: last discussion at F2F boiled down to SAML being "less
  interesting" without SOAP profile
- Prateek: that was his sentiments, but this gives us a clear path &
  mandate to getting something solid out
- Phill: concerned that this would look as though we are waiting on MS
  to release a proprietary protocol
- Prateek: not proposing that we base our work on MS�s work, just to
  give it due analysis
- RLBob: has fielded questions about the weight that will be given to
  follow-on work, and he couldn�t answer
    - Would support this proposal even more if there were some
      clarification to this
- Irving: we specifically created the bindings & profiles structure in
  our spec to allow future extension
- Rob: some of these new bindings docs may require changes to core
- Proposal is to publish as additional profile at a later time
- Jeff H: is WS-Security and WS-License on the list to be considered by
  W3C?
    - Phill: can�t say for sure, MS won�t say, neither will W3C
    - Doubts it can be picked up before XKMS completes
- Prateek: Should SOAP profile be given a different status than just an
  additional profile, since it will get full force of the TC?
    - Yes.  This is the proposal
    - RLBob:  does anything else fall in this category?
    - Not currently
- SOAP Profile text needs to be removed from Bindings doc and put into
  new doc in repository
- BobG: conformance doc will need to be adjusted
- Hal: security conformance will be affected also
- So, text from all three docs will be excised and put in this new doc
- [Vote] No objections.  Passes.

>
> B) "resource" attribute for AttributeQuery
>    NOT entered in saml-issues-07.  SHOULD BE.
>    NOT addressed in core-25. SHOULD BE.
>
>    Definitive message...
>
>    [security-services] spec text for additional Attribute Query
>    element morgan
>    http://lists.oasis-open.org/archives/security-
>    services/200112/msg00004.html
>

- Hal: looks just like an action item for me, right?
- Joe: no, also for Phill in core
- This was the item voted on at F2F#5, but then determined that text
  was required
- The text was submitted by RLBob in December
- [Action Item] Phill to merge text into core

>
> C) "removal of AttributeValueType still an issue"
>    NOT entered in saml-issues-07.  SHOULD BE.
>    NOT addressed in core-25. SHOULD BE?
>
>    Beginning of thread...
>
>    [security-services] Validation of simple attribute value fails?
>    cantor
>    http://lists.oasis-open.org/archives/security-
>    services/200112/msg00079.html
>
>    Most recent followup...
>
>    [security-services] removal of AttributeValueType still an issue
>    morgan
>    http://lists.oasis-open.org/archives/security-
>    services/200201/msg00153.html
>

- Hal treated this as one issue in issues doc, but there were multiple
  issues
- Phill has fixed one of these, which was related to needing the latest
  XMLSpy, or it gets rejected
- Appears that Tim & Phill wanted same thing, and Chris has a proposal
  that satisfies that
- Joe: drive to closure within next few days
- Jeff H: be sure to be clear in addressing this, given the multiple,
  overlapping discussions so far
- Hal: what do we call this in issues list?  "Approval of
  AttributeValue type"?
- Tim: "Attribute Tagging"
- Chris: the "removal of AttributeValueType" issue has been resolved in
  Phill�s core doc, and Tim�s "Attribute Tagging" will be addressed
  right away
- RLBob & Scott: possibly have a new issue involving representation of
  multi-valued attributes, which will be raised in a new posting

>
> D) Suggest adding IssueInstant attribute to Requestand Response
>
>    Initial msg...
>
>    [security-services] Suggest adding IssueInstant attribute to
>    RequestandResponse
>    cantor
>    http://lists.oasis-open.org/archives/security-
>    services/200201/msg00033.html
>
>    thread in response...
>
>    RE: [security-services] Suggest adding IssueInstant attribute
>    toRequest and Response
>    hallam-baker
>    http://lists.oasis-open.org/archives/security-
>    services/200201/msg00055.html
>
>    Scott appears to be backing off the issue in his last msg in the
>    thread.
>

- Scott: indeed has backed off
- Doesn�t see this as necessary for anything present or anything in
  immediate future
- But by same token, why does request id exist?
- Chris doesn�t think it costs anything to add this, that it will be
  useful, and that the clock skew issues aren�t any different than what
  we already face
- Overhead of tracking request id�s that have already been serviced is
  much greater than checking to see if the issue instant of a request
  is within last 5 minutes
- Doesn�t see value to adding this to Response, just Request
- Valid, signed Response should be believed for its lifetime regardless
  how it arrived
- RLBob: seems odd to have asymmetry between Request & Response
- Chris: payload of response is an assertion that has its own timing
  mechanism
- Any objections?
    - None
    - Irving: is attribute optional or required?
    - Optional
        - Scott: make it required to send, but optional to process on
          reception
    - Jeff H:  Was well-crafted description of semantics provided?
    - Scott: no, but now that there is consensus, he can submit
    - [Action Item]  Scott to provide clear write-up of this proposal
- Prateek: there are other items that do not have sufficient
  description in core doc, that have not been given clear semantics,
  etc
    - AuthorityBinding element (2.4.3.2)
        - Late addition, not clearly specified
        - Was not voted on
        - Hal: somehow dropped from issues list
        - Prateek sees it as relatively benign, but just not worked
          through
        - Based on message sent in December, Simon did propose more
          text than appeared in core 25
        - [Action Item] Scott to champion, Prateek to assist
    - RespondWith (3.2.1.1) element
        - This one very troubling
        - Results in broad expansion of request/response protocol
        - Semantics are very lacking
        - Possible to create contradictory request
        - There have been many notes on list showing confusion
        - Phill saw this element as advisory
        - Jeff H: we discussed this on 2nd day of F2F#5, and there are
          notes on this
        - We voted on 4 options posed by Phill
        - More semantic exploration might well be needed
        - [Action Item] Phill to review these notes and present
          suggestions to list

>
> E) Hal's tentative closure list
>

- asks for people who disagree with categorization (shown by color) to
  speak up quickly
- especially looking for "no, this isn�t closed, it needs more
  discussion" type responses
- already caught one omission here on call, looking for others
- Jeff H: suggests using "deferred" as a new state value, rather than a
  description used for closed items
- Agreed
- Discuss red items here on call
- DS-1-06 MultipleSubjects
    - Jeff H: core 25 (line 575) explicitly states that multiple
      subjects refer to the same principal
    - Objections?
    - Irving: no.  been rehashed more than enough
    - At-large reviewers may take exception to this, particularly in
      the Java community
- DS-1-07 MultipleSubjectConfirmations
    - RLBob: thought we had come to conclusion that there can be only
      one at F2F#5
    - Core 25, Line 581 mistakenly has maxOccurs="unbounded"
    - Intention is that multiples shouldn�t be allowed
    - Will be handled as typo, and this issue is now resolved
    - Jeff H: Title of this issue is a little misleading
    - Should say MultipleSubjectConfirmationMethods
    - Multiple methods are allowable, but not necessarily acceptable in
      all circumstances
- DS-1-08 HolderOfKey
    - Hal mainly wanted to hear from Irving if he is satisfied
    - Prateek sent msg with text intended to clarify this
    - Hal not satisfied with level of detail
    - Prateek: without profile or binding, it can�t be sufficiently
      clear
    - Hal suggests taking this to the mail list
    - Doesn�t want to see different profiles using same confirmation
      method in different ways
- DS-1-09 SenderVouches
    - Not sure if this reached resolution or just lost momentum
    - Tim seems to be central to this topic, but no longer on call
    - Jeff H: BobB produced list of work items after F2F#4, and
      included text on semantics of SenderVouches
    - Not sure if that got extracted properly
- Remaining items won�t get covered today
    - DS-4-08 anyAttribute
    - DS-9-05 RequestAttributes
    - DS-9-10 IssueInstant in Req&Response
    - DS-11-01 MultipleSubjectAssertions
    - DS-12-06 RequestALLAttribs
    - DS-14-07 BearerIndication

>
> 4 - Scheduling of additional call
>

- Will schedule focus call for Friday, Jan 25
- Joe will arrange dial-in facility, and send email

>
> 5 - Other Items
>

- RLBob: referring to msg from Stephen Farrell, unless some voting
  member picks up items from his msg and champion them, they will not
  become issues for consideration before going to last call

>
> 6 - Adjourn
>

- Adjourned


-----------------------------------------------------------------------

Attendence of Voting Members:

  Irving Reid Baltimore
  Larry Hollowood Bank of America
  Hal Lockhart Entegrity
  Robert Griffin Entrust
  Tim Moses Entrust
  Joe Pato HP
  Chris McLaren Netegrity
  Prateek Mishra Netegrity
  Jeff Hodges Oblix
  Charles Knouse Oblix
  Steve Anderson OpenNetwork
  Aravindan Ranganathan Sun
  Bob Morgan UWashington
  Phillip Hallam-Baker Verisign
  Thomas Hardjono Verisign




Attendance of Observers or Prospective Members:

  Rob Philpott RSA Security
  Scott Cantor OSU



Membership Status Changes:

  Krishna Sankar Cisco - Granted voting status after call
  Frederick Hirsch Zolera Systems - Granted voting status after call
  Maryann Hondo IBM - Granted voting status after call
  Gavenraj Sodhi BusinessLayers - Lost voting status due to missing 3rd
    consecutive call

--
Steve

begin:vcard 
n:Anderson;Steve
tel;fax:727-561-0303
tel;work:727-561-9500 x241
x-mozilla-html:FALSE
url:www.opennetwork.com
org:OpenNetwork Technologies
version:2.1
email;internet:sanderson@opennetwork.com
title:Product Architect
adr;quoted-printable:;;13577 Feather Sound Drive=0D=0ASuite 390;Clearwater;Florida;33762;USA
x-mozilla-cpt:;-6352
fn:Steve Anderson
end:vcard