[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