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 SSTC Focus Group, Tuesday Dec 18


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


Attendees:
 Joe P
 Phill HB
 Hal L
 Steve A
 RLBob
 Gil P
 Scott C
 Jason R
 Emily Xu
 Prateek M
 Irving R
 Simon G
 Darren P
 Bob G
 Tim M
 Jeff B
 Thomas H
 Jeff H
 Chris M



Agenda:
1. Review status of action items - and move to resolution
2. Conformance
3. JeffH’s last call process
4. RLBob’s resent email
5. SimonG’s email re: attr authority in assertions
6. ScottC: status codes
7. Adjourn


>
> 1.  JeffH’s Last Call Process
>

- 5 documents for delivery are agreed upon
- Want doc set substantially polished and basically at same "level" by
  9 Jan
- Conformance and sec-considerations docs require the most attention to
  meet schedule
- Go into "last call" with status of "candidate committee specification"

- Email includes interim milestone dates for bindings doc, but not core
  doc
    - How to fit Domain Model material into Core doc?
    - Phill will take material from latest version of Domain Model doc
      in repository and integrate
    - Joe would like draft no later than 3 Jan, preferably by 27 Dec
    - 27 Dec not very likely
    - Milestone set for 3 Jan
    - Risk remains with little time left between 3 Jan and 9 Jan for
      people to make comments
- After 9 Jan, rest of schedule is tentative
- Aggressively targets 1 Mar
- If we make the 1 Feb date for close of Last Call, that leaves 2 weeks
  for public review and 2 weeks to adjust to comments during that review

- These represent the latest dates possible to still meet the 1 Mar end
  date
- Proposed methodology for determining whether Last Call has been passed

    - Editorial comments are not sufficient to prevent passing Last Call

    - Technical issues, which are sufficient, require champions
    - Raised issues may be challenged, otherwise the committee "buys
      into" the issue
    - If the issues go unchallenged, the doc doesn’t pass
- JeffH again requests review of this Last Call process


>
> 2 -- Review status of action items - and move to resolution
>
> [A3: Phill] - Section 3.1.5, need to further define error cases
>

- Joe to Scott: Are error cases still open?
    - Scott: hasn’t communicated with Eve, believes they are still open
- Phill familiar with the fact that there are not enough error codes
  defined, but not sure how to resolve yet
- Issues
    - Phill: What level of detail to give to clients
    - Scott: Top-Level codes, their semantics and completeness
- Joe: How close are we to closing this?
    - Scott has floated some ideas, but has only received comments from
      Rick Salz from the SOAP perspective
    - Scott has suggested re-organization to top-level codes, hoping to
      spark discussion, but discussion hasn’t happened
    - Joe: does anyone have strong feelings on this?
    - RLBob: comfortable with current state
- Joe to Phill: what do you need to complete the next core draft?
    - Phill: need text
- Need semantic description for error codes
- Scott can enumerate what he did
    - SOAP doesn’t have status, it has Fault, so success code may or
      may not be appropriate
    - Failure, Error or Unknown isn’t clear enough
- Not hearing anyone indicating they will have new codes to discuss by
  9 Jan
- Scott recommends starting with the smallest set possible at the top
  level
- Joe would like comments on the alternatives between the proposals on
  the list
- If no comments, power left to Phill and Eve to choose during editing
- Status: we have proposal on table, open to comments, no consensus
  established

>
> [A5: BobB] - Section 4.1.3 472-473, text to clarify construction of
> ID (w.r.t. uniqueness)
>

- Joe has not contacted Bob yet
- stays open

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

- Just waiting on integration into doc
- Chris not sure if Eve has included yet or not
- Joe to Chris: please sent note to list when you see it in draft

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

- Same as [A3]

>
> [A20: Prateek] - Need for additional ConfirmationMethod identifiers
> (Prateek and Phil)
>

- Prateek: wrt codes in section 5, has sent msg with constants and some
  text
- Phill: can use URNs from RFCs from IETF where appropriate, and where
  they don’t already exist, we can make them up
- Hal: you’re not talking about SASL codes, since you’re referring to
  URNs, so what are you referring to?
- Phill: There's an RFC (RFC2648, informal, not on standards track) on
  how to use URNs to reference IETF documents
- Hal: some things are defined in multiple RFCs
- RLBob: or an RFC may define multiple things
- Phill: we’ll have to just pick one RFC for each method
- Hal: sounds reasonable as long as some text explains the approach
- Scott: was there a previous issue from Eve over the use of URIs
  versus strings?
- Need to ask Eve
- Joe: We will re-confirm this in Jan

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

>

- Irving: Missed last concall, and it looks like there was some activity

  on this
- Not sure if it takes away his action item
- Joe: wasn’t re-assigned, but Scott & Eve have been contributing
- Scott: could be relegated to a second-level code
- Irving: msg in question was on 12 Dec
- Irving: thinks BobB was biggest supporter of Completeness specifier,
  but there were others at that F2F
- Joe: anyone else feel strongly about this?
- None
- Joe: directs Phill (and Eve) to go ahead and integrate this change

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

- Still open, for tracking

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

- Phill has updated the schema for this
- Believes he updated core
- Stays open


>
> 3. Conformance, BobG
>

- Three fundamental issues
    - How do we categorize conformance?
    - How do we specify mandatory vs options?
    - How do we specify proof of conformance, e.g. test cases
- "How do we categorize conformance?"
    - Originally based on entities in domain model
    - Over time, has concluded this to be insufficient, as domain model
      has become non-normative, and instances of overlap on assertions
      used has increased
    - Has kept this proposal, but has also introduced new model, based
      on assertions
    - New approach includes notion of levels and considerations to
      bindings and profiles
    - << DISTRACTED HERE >>
    - any objections to this approach?
    - Phill likes it, as they aren't going to implement all of it, for
      example
    - Hal not so sure
    - Prateek prefers a binding/profile-first approach
    - General concern with vendors implementing bits and pieces, but not

      being interoperable
    - There is great detail in the bindings doc about what is required
      to implement a given binding or profile
    - Finer level of granularity appropriate for bindings, but should go

      into conformance doc
    - Scott: so if I build a toolkit, would it be compliant, or would I
      have to built a running product in order to claim compliance?
    - Hal: the latter, since his customers really are interested in
      products that interoperate
    - Any concerns over taking a binding/profile-first approach?
    - Proposal: allow an app claim conformance with any of the bindings
      or profile, and underneath that, they can claim the assertions
      they support
    - BobG will write this up and send to list for discussion
    - There won’t be time for group discussion of this before 8 Jan, but

      if anyone wants to discuss prior to that, they can contact BobG
- Discussion of mandatory bindings/profile
    - If a vendor has no use for SOAP binding, why must it be required
      to be in their product?  If it can’t be turned off, does it leave
      door open for potential attacks?
    - Prateek: ok with not requiring any binding/profile, but leaves
      strange feeling over basic interop if no basic binding/profile can

      be counted on
    - Gil: how can consumer look on side of box and determine
      interoperability?
    - RLBob: still large amount of work done outside of SAML to ensure
      interop between systems
    - Sounds like this SOAP binding is useful to require, true?
    - Darren: not convinced. Even thinks Hal had mentioned only
      implementing the SSO aspects, which doesn’t seem to imply all of
      SOAP binding
    - JeffB: what happens in future when there are more bindings?
    - We’ll have to revisit this in the future
    - Any objections to moving forward with proposal?
    - None
- Mechanism for specifying conformance
    - One is a black box of tests
    - Another is a specification of scenarios and test cases
    - BobG proposes that he proceed with generating that specification
    - Doesn’t think there is time to develop the black box tests
    - Any issues with this proposal?
    - None
- [ACTION] BobG to send out proposal by end of this week on this topic
- There will be a meeting on Friday 4 Jan for anyone wishing to review


>
> 4.  SimonG’s Authorization Authority Proposal (evolved into
> discussion of process for issue handling)
>

- Simon had sent msg to list already, proposing authN assertions with
  a list of authorities that the cliet must check with
- Not sure if people have read it
- Joe suggests Simon resend it
- JeffH: is there an open issue?
- Simon: at F2F, it was deemed that there was not enough text to
  consider, and now there is
- JeffH: There should be a high level issue around this
- Chris: the issues have revolved around submitting text, not whether
  the text should go into the spec
- Scott: there are two others in a similar situation
- Joe: champion has to push it until it gets agreed to
- JeffH: our mechanism should change, adding issues for discussion when
  solid text is proposed
- This will get worse in the last call process if the process doesn’t
  change now
- RLBob: based on this, he has three issues to champion
- Via email, Joe will contact Hal to manage this
- [ACTION] Joe to contact Hal concerning:
    - What is the outlook for updating issues doc
    - Does he agree that once proposals are solid, should they become
      issues
    - Can he do overall sweep of list of issues so that issues doc is
      the singular source for issues?
- RLBob will help with identification of his proposals
- Prateek thought there was some level of agreement to RLBob’s proposals

  already
- These were unusual because at the F2F, they were agreed to initially,
  but then group became uncomfortable with agreeing to something without

  complete text
- Prateek already modified bindings doc to incorporate RLBob’s proposals

- Joe: do not roll back, send reminder to list of original agreement and

  the tie to this completed text
- Noted that the group needs to approve several proposals very soon in
  order to get them into 9 Jan drafts
- Since no call is scheduled before 8 Jan, much of this will have to be
  handled on list


>
> 5. Adjourn
>

- Adjourned

--
Steve Anderson
OpenNetwork Technologies
sanderson@opennetwork.com
727-561-9500 x241

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 330;Clearwater;Florida;33762;USA
x-mozilla-cpt:;-15216
fn:Steve Anderson
end:vcard


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


Powered by eList eXpress LLC