OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [security-services] Minutes for Focus Group, Tuesday Dec 4

Agenda - OASIS SSTC Focus Group - Tuesday Dec 4
Dial in info: +1 334 262 0740 #856956

 Thomas H
 Emily X
 Don F
 Irving R
 Allen R
 Jeff B
 Carlisle A
 Simon G
 Gil P
 Jeff H
 Prateek M
 Chris M
 Steve A
 Scott C

> Agenda:
> -------
> 1. Review status of milestones
> 2. Review status of action items - and move to resolution
> 3. Additional items?
>     Outreach status
> 4. Adjourn

- JeffH: we've stated publicly that we'll have something (not sure what
  to call it) available 21 Dec
    - Prateek:  bindings draft hasn't progressed as hoped, but does have

      action items went out, and does think a "95%" document is
      realistic on schedule
    - Prateek:  Eve had proposed an additional step (look & feel, IPR,
      etc), but Prateek has already expressed skepticism at
      accomplishing that
    - Chris:  concerned that we don't know what we're going to produce
      (one doc, separate docs, docs that will need polishing)
    - JeffH:  BobB has indicated he won't have time for polishing by
      deadline; Eve has done polishing on glossary, so there is an
    - JeffH:  believes we should proceed with separate docs
    - Chris:  agrees.
    - Prateek:  wants to get group focused on reading docs and raising
      objections with content, that will be sufficient
    - JeffH:  agrees.  Wants to put these docs on web site with some
      term describing its status (looking for term in other arenas)
    - We're not at "Committee Specification" status yet, nor will be
    - "Committee Working Draft" might be appropriate
    - DonF:  "Committee Recommendation"?
    - Has bigger implication
    - Carlisle:  "Pre-specification"?
    - JeffH:  This spec process is just not well defined
    - Could borrow "Working Group Last Call" concept from IETF, which is

      inline with Prateek's earlier suggestion
    - General consensus
    - Email will go to SSTC list, enumerating the set of docs and the
    - DonF:  is this the doc developers can code to, where only mistakes

      will change?
    - RLBob:  tough to say
    - JeffH:  certainly changes will occur, but they get progressively
      less frequent and less significant
    - JeffH:  in W3C, if changes affect data on the wire, spec has to go

      through "last call" again
    - JeffH:  after passing "last call", believes that "Committee
      Specification" is appropriate status
    - JeffH:  what are gating factors to getting to "last call"
        - Prateek sees 2 more iterations of bindings before then
        - Phill not on call, but another rev to core seems reasonable
        - Prateek calling for folks to comb docs before "last call"
        - RLBob: "last call" should imply no open issues
    - DonF:  how long will "last call" phase last
    - JeffH:  typically, 2 weeks
    - Irving:  sounds good, but must accommodate holidays
    - DonF:  CORBA gave 3 weeks
    - RLBob: another week or so to incorporate comments generated during

      last call
    - JeffH:  we must methodically work through action items before
      everyone vanishes for holidays, i.e. around 21 Dec
    - JeffH:  "last call" can be announced to last through 15 Jan
    - Carlisle: will there be a vote then?
    - JeffH:  we get to establish process
    - RLBob:  we should shoot for one or two Tuesdays after comments are

      incorporated to have vote
    - DonF:  vote by voice or by email?
    - Carlisle:  OASIS guideline suggests email votes take ~5 days
    - RLBob:  We can investigate this between now and then
    - Carlisle:  OASIS requires that specification must be in use when
    - JeffH:  for consideration by OASIS in 2nd half of 2002, we must
      submit by 01 Mar
    - RLBob:  end of Jan is reasonable for his team to claim use of spec

    - DonF:  does have implementation underway, but still has questions
      over conformance
    - Carlisle:  that's the province of bob griffin & conformance
    - Carlisle:  other implementations?
    - quadrasis
    - Prateek:  his organization should have something re-spun and ready

      shortly after Jan
    - Irving:  likewise
    - JeffH:  sounds like we're in good shape, and arriving at process
    - Gating factor on issuing last call is having all issues & actions
      where appr on docs closed
    - Emily:  are latest working docs available on website?
    - JeffH:  the docs repository beneath web page should have
      bindings-06, core-20 and security considerations, and he will work

      on getting that done [ACTION ITEM, Jeff/Krishna]
    - JeffH:  we'll need to summarize process decisions to the list,
      which he'll do [ACTION ITEM]

> Milestones:
> -----------
> [M1 - Prateek] - publish bindings-07 during week of Dec 3.

- Prateek:  Not out yet.  Should be out tomorrow.
- RLBob:  mostly reflects comments from F2F#5?
- Prateek:  yes

> [M2 - Tim, Simon, Irving] - detailed reviews: Tim - section 4.1;
> Simon - section 3.1; Irving - section 4.2

- Sections of Bindings, yes?
- Correct
- These are reviews of Bindings-07, so tied to previous milestone
- Prateek:  will Irving be able to get thru his part of this by next
- Irving: yes
- JeffH:  stresses schedule
- Prateek:  soliciting feedback for all sections within a week, so next
  rev can get out by 17 Dec
- Proposed end date of this milestone: 12 Dec

> [M3 - Prateek] - publish bindings-08 during week of  Dec 17.

- Based on closure of [M2], ok

> Open Action Items:
> ------------------
> [A2: Prateek] - Section, need to capture SSL version, cipher
> suites, etc
> Status: thread on direction: < http://lists.oasis-open.org/archives/
> security-services/200111/msg00025.html >

- JeffH:  is recent discussion on list sufficient
- Prateek:  yes.  Will go into Bindings-07
- JeffH:  folks need to review this in -07

> [A3: Prateek] - Section 3.1.5, need to further define error cases

- Prateek:  believes we found language to step around this
- Simon:  agrees
- Prateek:  will review Simon's proposed text and carry forward into
- RLBob:  so we can expect specific error codes to be specified in
- Prateek:  yes
- Summary:  bindings-07 will include text appropriately pointing to
- JeffH:  is there appropriate text in core?
- Prateek:  not sure
- Gil:  Is there anything capturing this dicussion?
- Prateek:  section 3.1.5 does have some such language
- JeffH:  we need to ensure that core addresses this
- Still open pending issuance of bindings-07

> [A4: Prateek] - Section 4.1.1, create a diagram for this section

- Prateek:  there is highlevel OID diagram for web browser profile
- There is one in the use case doc, so struggling with need for a
  different one here
- JeffH:  use case doc is non-normative, and many people won't even
  refer to it
- RLBob:  agrees with value in adding diagram here
- Prateek:  accepts.  Will be in bindings-07
- still open pending -07

> [A5: BobB] - Section 4.1.3 472-473, text to clarify construction of ID

> (w.r.t. uniqueness)

- BobB not on call
- This has not been seen on list
- JeffH will try to ping BobB
- RLBob: recalls this as a possible nit, so if omitted, wouldn't be
- still open

> [A6: Prateek] - Line 565, capture the threat (leading to requiring a
<saml:audience>, then decide to leave it, change it, or strike it

- Prateek: will be dealt with in -07
- Summary is that there is no need for this element, since you're
  authenticating the requestor
- open pending -07

> [A7: Simon] - text for "things you might do in step 6"

- Not done yet
- Simon will send text to list by next Tuesday
- still open

> [A9: Irving] - line 788-791, provide clarifying language for
> application level error handling. Tied to Scott's status code proposal

> < http://lists.oasis-open.org/archives/security-services/200111/
>   msg00049.html >

- Irving: this is for specific case of attaching saml assns to soap msg
  (soap profile)
- Difficulty is that we're just sticking SAML assertions in SOAP header
  with no notion of what application is going to do with them.  So how
  to return errors, etc. when holderOfKey is used, can be done if signer

  isn't same, but in more general case it's very difficult to
  characterize what the error handling ought to be
- Prateek agrees with characterization
- only if the consumption of the assn itself has some issue at consumer,

  then needs to issue some error
- Irving will attempt to write up tonight, to get into bindings -07
- still open

> [A11: Irving] - line 824-829, Irving to research and propose language
> to weaken requirement on signing over entire message (body and
> headers). The proposal is to require signing over assertion headers
> and body only. Other components are to be signed by agreement between
> sender and receiver (out of scope for us).

- Irving will also attempt to get this out to Prateek tonight
- Prateek:  after re-reading XML DSig, realized he had confusion, and
  that Dsig alone will support construction of an XPath that will do
  we need.  Will see if this use of XPath in DSig is "mandatory to
  implement" or not
- still open

> [A12: Irving] - line 847-848, change "subject" to "sender"

- Prateek will update draft
- still open, pending -07

> [A13: Prateek] - add text on threat model and security counter

- Prateek: will endeavor to include in -07
- Issue is having a statement about what the recipient can assume upon
  receiving the msg
- Still open, pending -07

> [A14: Phill] - will post to list to try to recover original intent for

> AssertionSpecifier as subject

- Phill not on call
- Message sent to list 27-Nov
- Unless objections to msg on list, the change will be made in the next
  core doc

> [A15: Chris] - Write up advice on how to use current approach to
> slots for attributes

- Chris:  seems to be same as [A23]
- Sent some text just before call
- There are two ways of telling someone things about the "value",
  one can use xml schema facilities
- Not sure that this text fits in Core, as it is just commentary on how
  to use XML typing
- RLBob:  thinks we do want a recommended way of doing types such that
  implementations wouldn't be likely to re-invent one
- Chris:  agrees.  Still a question of where to position in docs
- JeffH:  we could put bare minimum of ‘shoulds' inline in core, with a
  discussion as an appendix
- Summary: Chris will suggest 'should' phrase to go into next core doc,
  then perhaps a more explanatory appendix
- still open

> [A16: RLBob] - adding context to attribute query; provide text for
> document including recommendations for minimum behavior.

- Sent message to list

- Irving:  In the bindings work, we've been adding a lot of baggage to
  the assertions lately, and we haven't thought about how a client will
  request assertions with those things in them
- Prateek: issue here is the expressiveness of the query language
- Irving: wants to have authority issue attr assn, and then send it to
  amazon, and if attr authority doesn't put right stuff in assn, it
  won't work
- RLBob: could be handled with extensions
- Irving: does not want to raise this as a formal issue at this time
- Scott:  agrees, and suggests this discussion be added to the FAQ
- JeffH: asks Irving to write FAQ contribution

> [A17: Charles] - to complete proposal for adding failure "reason" for
> SAML response.
> Status: < http://lists.oasis-open.org/archives/security-services/
>           200111/msg00037.html >

- Charles not on call
- Scott:  notes that this issue overlaps with general status code
- Message sent to list

> [A18: Phill] - completion of error code specification for core

- still open

> [A19: Chris] - eliminate <assertion> and rename <MultipleAssertion>
> Assertion. Draft text to deal with multiple assertions that are
> contradictory or cannot be reconciled.

- Message posted on list

> [A20: Prateek] - Need for additional ConfirmationMethod identifiers
> (Prateek and Phil)
> Bindings-06 uses two identifiers not found in core: HolderOfKey and
> SenderVouches. It is important to understand that no change in schema
> is being proposed, only new text and constants for Section 5 of core.
> Prateek to send Phil necessary text.

- Prateek:  will produce by Friday
- JeffH:  not in -07?
- Prateek:  will go in core
- still open

> [A21: Simon] - Section 3.1, SAML SOAP binding. Simon to review and add

> text to reflect F2F#4 discussion.

- Simon thinks this is done, sent text to Prateek
- Prateek agrees.  Will appear in -07

> [A22: Irving] - core line 752, return code for completeness specifier:

> < http://lists.oasis-open.org/archives/security-services/200111/
>   msg00031.html >

- Irving: was on hold until return code work completed, which appears
  done, so it can move forward now
- Still open
- Shooting for next Tuesday

> [A23: Chris] - explain use of xsi:type attribute to introduce element
> of basic XML schema type to avoid the need to introduce new schemas
> the sole purpose of specifying a string attribute value.

- Covered by [A15]

> [A24: Phill] - Bring together Tim's etc. text for the Authentication
> mechanism section.
>             [In progress]

- Still open

> [A25: Phill & Eve]  - Eve's reorganization of preamble

- Still open

> [A26: Phill] - text on the <RespondWith> option voted for at F2F#5

- Still open

> Outreach status
> ---------------

- Eve & Darren not on call
- JeffH mentioned Eve's reworking of draft-sstc-glossary which she'll
  be sending to the list. will have further summary of outreach status
  at next concall.

> Additional Items
> ----------------

- Scott: regarding status code issue, xmlp folks are now thinking of a
  new way of doing this, and there's no clear indication of which way
  they are leaning. Question is should he re-send his proposal with
  their alternative solution?
- JeffH:  can't hurt to have both options on the table
- we can decide from there whether we'll try to follow what soap/xmlp
  does (if they do it soon enough) or decide on our own
- Scott:  will do

> Adjourn


Steve Anderson
OpenNetwork Technologies
727-561-9500 x241

tel;work:727-561-9500 x241
org:OpenNetwork Technologies
title:Product Architect
adr;quoted-printable:;;13577 Feather Sound Drive=0D=0ASuite 330;Clearwater;Florida;33762;USA
fn:Steve Anderson

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC