[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] Minutes for Focus Group Telecon Tue 2-Apr-2002
Agenda ------- Joe: intend to discuss ds-1-10 prateek: any word from RSA about license intent? rob: we're meeting later today, can you (chairs) send comments? Joe: mentioned karl's note, need to request clarification from Karl about the intent of the new approach. [Action 1] joe/Jeff to solicit clear IPR procedure statement from Karl ds-1-10 discussion ------------------- [ds-1-13 is closely related] applicable messages.. New Issue: SubjectConfirmation descriptions http://lists.oasis-open.org/archives/security-services/200201/msg00247.html ISSUE: core-27: Should AuthenticationMethods andConfirmationMethods be listed in the same subsection? http://lists.oasis-open.org/archives/security-services/200203/msg00006.html hal: will settle for addressing this with a warning that no matter what the ConfirmationMethod says, it's the profile that needs to describe precise use of SubjectConfirmationData material. e.g. to use a kerberos ConfirmationMethod & SubjectConfirmationData, one needs to specify whether the included ticket is a TGT or a service ticket and other stuff. in contrast, AuthenticationMethod is relatively easy to include in assertions and base subsequent policy on. prateek: suggests we retain list as AuthenticationMethods, prune as appropriate, then define ConfirmationMethods in the bindings spec as appropriate. [further discussion around Prateek's proposal, culminating in...] Agreed-to resolution to DS-1-10, DS-1-13: re-label core-29 section 7.1 as "Authentication Methods" include some appropriate note in subsequent version of core-xx to the effect.. "ConfirmationMethod identifiers and their semantics/use are defined in SAML bindings & profiles. Some are presently defined in [SAMLBind]." need to drop a few AuthenticationMethods, clarify the prose describing the rest. Presently defined & employed ConfirmationMethods (and attendant SubjectConfirmationData values) will be defined in appropriate places in the subsequent version of bindings-model-xx, and it'll also have a (sub)section summarizing the presently defined & employed ConfirmationMethods... holderOfKey bearer sender vouches artifact wrt the OASIS-specific URIs identifying AuthenticationMethods & ConfirmationMethods.. use "am" in AuthenticationMethods listed in core e.g. urn:oasis:names:tc:SAML:1.0:am:password use "cm" in ConfirmationMethods listed in bindings e.g. urn:oasis:names:tc:SAML:1.0:cm:Holder-Of-Key [Action 2] Hal will make a proposal for the changes to core-29 section 7.1, as described above. Will try to make the proposal by COB today. [Action 3] Prateek to make appropriate changes to bindings-model-13 and issue new spec by Thur 4-Apr. [Action 4] Phill to incorp Hal's suggested changes to core-29 within 24hrs of Hal's proposal. ----------- Editorial fixes to various docs [Action 5] Phill, Prateek, perhaps others.. Assuming the editors agree and the suggestions aren't found controversial by others, then these suggestions (and others submitted by today) should be incorporated.. Comments on bindings-13 http://lists.oasis-open.org/archives/security-services/200204/msg00003.html RE: [security-services] Comments on bindings-13 http://lists.oasis-open.org/archives/security-services/200204/msg00004.html minor editorial comments on core-29 http://lists.oasis-open.org/archives/security-services/200204/msg00005.html NOTE: there's further action, [Action 6], identified near the end of this msg below!! ----------- have we closed all open issues? Review of red-coded open issues in issues-status-05 http://www.oasis-open.org/committees/security/docs/draft-sstc-saml-issues-status-05.pdf we just worked on DS-1-11 & DS-1-13 (see above), so will skip them for now. Note: all "done"s below means the item was addressed in core-29 or bindings-model-13, as appropriate. DS-1-11 & DS-1-12 done DS-4-12 done (see discussion at end of these minutes wrt to schemalocation) DS-4-13 done DS-4-15 Was deferred during 19-Mar-2002 telecon Minutes for Telecon, Tuesday 19 Mar 2002 http://lists.oasis-open.org/archives/security-services/200203/msg00137.html DS-8-06 was closed during 19-Mar-2002 telecon DS-9-14 done DS-12-06 done DS-14-19 done DS-14-20 done line 426 ms-1-03 done ms-1-07 not done in core -- but will be addressed as a part of DS-1-10 resolution done in bindings ms-5-08 done ------------- Prateek noted that at least one item agreed to during the 26-Mar-2002 (last week's) concall wasn't incorp'd in core-29. Review of 26-Mar-2002 minutes http://lists.oasis-open.org/archives/security-services/200203/msg00169.html Note: all "done"s below means the item was addressed in core-29 or bindings-model-13, as appropriate. > [RLBob] InResponseTo optional > proposed text change to core-28 to list - included in spec (Phill?) > > http://lists.oasis-open.org/archives/security-services/200203/msg00127.html > > [Minutes] Change accepted. Editor to add to Core-29. done line 1142 > > [Hal] New Issue: Should Queries contain a full Subject? > > http://lists.oasis-open.org/archives/security-services/200203/msg00129.html > [..snip..] > Resolution: We will include text to characterize the general threat described > under part 3 of Hal's message. An additional error sub-status code "Request > Denied" and the conditions under which it is to be used described. No change > to schema for subject in query. > > Prateek will write this text and Rob P. will review. This text will be added > to the core document. Motion passes. done line 1040 > > [Hal] [security-services] New (minor) Issue: AuthNMethod, not > ConfirmationMethod in AuthNQu ery > > http://lists.oasis-open.org/archives/security-services/200203/msg00142.html - > prateek's proposed changes > > [Minutes] Friendly amendment from Rob --- instruction to the editor -- text > beginning at "first,... and > further, etc..." should be split up into bullets so the processing steps are > obvious. > > Motion passes. done line 1046 > > [Hal] Text for "All Assertions" > > http://lists.oasis-open.org/archives/security-services/200203/msg00138.html - > agreed? applied? > > lines 1317 & 1318 change the sentence to read: > > If no attributes are specified, it indicates that all attributes allowed by > policy are requested. > > [Minutes] > Motion passes. done > > [Scott] Core changes for ISSUE DS-14-19 > > http://lists.oasis-open.org/archives/security-services/200203/msg00143.html - > > [Minutes] Proposed and accepted. done > > [Emily] Minor error in core 28 > > http://lists.oasis-open.org/archives/security-services/200203/msg00145.html > > [Minutes] Proposed and accepted. done line 1177 > > [Scott] Core changes for ISSUE DS-4-13 > > http://lists.oasis-open.org/archives/security-services/200203/msg00146.html - > > [Minutes] > [..snip..] > Joe: action to Scott. > > Scott will write text to rule out use of empty strings, rule out empty URIs > other than for resources. > > done line 169, 753, 1080 > > > [Scott] Approved changes/cleanup for Status/StatusCode/etc. > > http://lists.oasis-open.org/archives/security-services/200203/msg00148.html > [..snip..] > > Joe: move to accept change. Change is accepted and forwarded to Editor. scott/prateek: done. line 1219 et al. > > [Hal] Base64 in core and bindings > > http://lists.oasis-open.org/archives/security-services/200203/msg00152.html > > Prateek: Is this an instruction only for binding? > Scott, Rob: what about subject confirmation data element? This is currently a > string and cannot > carry an arbitrary blob. > Rob: Also occurs in Section 7.1 > Joe: any other changes for core other than making sure the spelling is > correct? > > Joe: change is accepted. Editors to fix. prateek: done in bindings core: line 1559 done > > [Rob P] Comments on core-28 > > http://lists.oasis-open.org/archives/security-services/200203/msg00161.html - > editorial, applied? > > amendments: > > 4) change line 352 to start: "currently being defined" > 6) replace application by terms a SAML requestor, SAML responder, where > appropriate > > http://lists.oasis-open.org/archives/security-services/200203/msg00163.html - > editorial > > [accepted] done rob verified them minor correction on lines 1334 & 1335 "authority" in all lines, shouldn't be, rob to send editorial comment to list Phil to address. This is part of [Action 5], above. > > [Rob P] Issue/editorial comment: Description of<Condition> processing in > core-28 > > http://lists.oasis-open.org/archives/security-services/200203/msg00162.html - > agreed? applied? > > [accepted] done section 2.3.2.1 417 et al > > ADDITIONAL ISSUES RAISED IN CALL: > ------------------------------------------------- > (1) > Scott: msg00146 - should the empty string restriction be generalized to > whitespace in the text? Rob moves. > Prateek seconds. this actually passed, assesrted by prateek, no obj. done line 173 > (2) > > Prateek: Motion is to change the type of SubjectConfirmationData to > base64binary? > Scott: Remove ds:KeyInfo and change SubjectConformationData to be anytype? > Phil: objects to removal of ds:KeyInfo > Scott: why not choose between the two? > Phil: objects to exclusive choose > Joe: Proposal to change of SubjectConfirmationData to AnyType. > > Motion passes. not done. anytype is correct type for SubjectConfirmationData. Phil missed in core-29 [Action 6] Phill to address > > (3) RL Bob's URN message to be applied to core and bindings. > http://lists.oasis-open.org/archives/security-services/200201/msg00225.html > Scott, Joe: explain that these URNs are available. > Joe: Phil + Prateek to apply changes. done. phill: one thing not done is the assertion schema location in the protocol schema. will have to do that when we post to the website. scott: perhaps don't need to point schemalocation to exact location, but perhaps can do relative schemalocation & the namespace. It's one thing to point authoritatively at, say, the dsig schema, but another to have our protocol schema reference our assertion schema we should treat schema location as only a "hint" -- it can't be normative. summary: In anycase, we'll ensure there's something reasonable in the protocol schema for the assertion schema location at final publication time. ------------------------------ Attendance ---------- Allen Rogers Authentica Krishna Sankar Cisco Gil Pilz E2open Hal Lockhart Entegrity Joe Pato HP Jason Rouault HP Marc Chanliau Netegrity Chris McLaren Netegrity Rob Philpott RSA Security Jahan Moreh Sigaba Jeff Hodges Sun Emily Xu Sun Bob Morgan UWashington Phillip Hallam-Baker Verisign [did Irving arrive late? thought I heard his voice] observers: Scott Cantor OSU Thomas Hardjono Verisign Tim Moses Entrust --- end
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC