[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
Attendees:
Thomas H
Emily X
RLBob
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
example;
- 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
soon
- "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
timeframe
- 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
presented
- 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
subcomm
- 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
consensus
- 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
week?
- 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 3.1.9.2, 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
- [CLOSED]
>
> [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
Bindings-07
- RLBob: so we can expect specific error codes to be specified in
Bindings-07
- Prateek: yes
- Summary: bindings-07 will include text appropriately pointing to
core-2x
- 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
significant
- 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
what
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
measures
>
- 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
- [CLOSED]
>
> [A15: Chris] - Write up advice on how to use current approach to
generic
> 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
core
> document including recommendations for minimum behavior.
>
- Sent message to list
- [CLOSED]
- 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
- [CLOSED]
>
> [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
- [CLOSED]
>
> [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
- [CLOSED]
>
> [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
for
> 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
>
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