[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] (amended) Minutes for Telecon, Tuesday 28 May 2002
(Corrected confusion of Emily with Bhavna, as well as Simon's affiliation) Minutes for SSTC Telecon, Tuesday 28 May 2002 Dial in info: +1 334 262 0740 #856956 Minutes taken by Steve Anderson > > The focus for this week's meeting is to tie up any loose ends prior to > submitting the SAML 1.0 specs for consideration as an OASIS spec. > > Agenda: > > 1. Roll call > - Attendance attached to bottom of these minutes - Quorum achieved > > 2. Consensus test that we do want to submit into the 1 June OASIS > review cycle - failure to reach consensus will cause us to adjourn > and continue as a focus group meeting > - Who does not believe we should be submitting? - no one - Consensus is that we do want to submit > > 3. Any residual technical issues (esp. inclusion of fixes to errata > in specs) > > There are 5 new PEs (potential erratas) in draft-sstc-cs-errata-02 > to discuss. > > see.. > > Errata document V02 > < http://lists.oasis-open.org/archives/security-services/ > 200205/msg00050.html > > - Eve summarizes where we are - PE14-PE22 are open - a couple will need thought, but rest should be trivial - PE4 had action item, but has been resolved - PE14-22 need to be decided on today - Walking through PE's - PE14: Fix references to time values section - Eve moves to fix these - [VOTE] no opposition, approved - PE15: Unify signature inheritance subsections - this one's more meaty - Irving: brought up concern in F2F#5 - recalls that the intent was for the restriction to be there - Prateek: so you're just re-affirming what is in there? - Irving: found first paragraph confusing, mentioning inheriting signatures from anything, but later we say signatures can only be inherited from surrounding SAML - Prateek: notice term "rationale" in 5.3.1, implying non-normative - Irving: options are to revisit intent (which would have to be defined by profile) or fold a little of 5.3.1 into 5.3.2 - re-opening sounds like a bad thing - Prateek: profiles still can define signature rules - Eve: inclined to dump wording in PE15, and follow Irving's direction - Irving will craft some wording while we proceed - RLBob: comments on term "signed SAML" being unclear - Irving: there are some parts of SAML where signatures are allowed - RLBob: write that down - deferring item for the moment - PE16: Remove schema listings in back of core - Phill: uncomfortable removing this, as people may not refer to the schema file - we've not had problem keep them in sync - Eve: actually we have, see PE13 - Eve moves to remove them - [VOTE] no opposition, passes - PE17: Remove mention of <AdviceElement> - Eve moves that we remove the mention - [VOTE] no opposition, passes - PE18: Interpretation of authentication information - requires a little thought - Prateek: believes these were supposed to be required - believes misunderstanding stems from attributes needed to be flagged as required, otherwise they are optional - Phill: can imaging cases where method may not want to be revealed - Eve: could have URI that specifies "none of your business" - Eve: this would be a schema change if this becomes required - Prateek: we've implemented as required - several others did as well - Rob: would it be appropriate to add that method (in 7.1.11) for "not specified"? - Phill: suggests devices may not have ability to generate good timestamp - Prateek: no presumption that it is a good clock - Emily: nowhere else stipulates a "good clock", so why make this one inconsistent? - Eve: moves to change the prose and schema to make these required - RLBob: makes friendly amendment to specify the "unspecified" authN method - Eve: accepted - [VOTE] - Phill opposes - passes with one objection - PE19: Clarify the SubjectLocality element - Joe: do we have specific change text? - Eve: no - Rob: not against leaving as is - Eve moves to accept option 2, not changing it - [VOTE] no opposition, passes - PE20: ResourceNotRecognized not found - Prateek: moves to add status code - Joe: we do need text here - Eve: friendly amendment of proposed text "The responder does not wish to support resource-specific attribute queries, or the resource value provided is invalid or unrecognized." - [VOTE] no opposition, passes - PE21: Equality of major and minor versions - much wordsmithing ... - motion to accept: "The specifications may be revised without a change to the SAML major or minor version number, as long as the specification changes raise no compatibility issues with SAML implementations." - [VOTE] no opposition, passes - PE22: Delete reference to "AuthorityKindType" in line 707 of cs-sstc-core-00.pdf < http://lists.oasis-open.org/archives/security-services/ 200205/msg00055.html > - Eve moves to make this editorial change - [VOTE] no opposition, passes - PE15 (revisited) - Irving sent proposed text to list in < http://lists.oasis-open.org/archives/security-services/ 200205/msg00056.html > - Prateek: friendly amendment "but is contained in an enclosing SAML element" - new text: "A SAML assertion may be embedded within another SAML element, such as an enclosing saml:Assertion or a samlp:Request or samlp:Response, which may be signed. When a SAML assertion does not contain a ds:Signature element, but is contained in an enclosing SAML element that contains a ds:Signature, and the signature applies to the saml:Assertion element and all its children, then the Assertion can be considered to inherit the signature from the enclosing element. The resulting interpretation should be equivalent to the case where the Assertion itself was signed with the same key and signature options. Many SAML use cases involve SAML XML data enclosed within other protected data structures such as signed SOAP messages, S/MIME packages, and authenticated SSL connections. SAML profiles may define additional rules for interpreting SAML elements as inheriting signatures or other authentication information from the surrounding context, but no such inheritance should be inferred unless specifically identified by the profile." - Eve moves to accept - [VOTE] no opposition, passes - Eve: we have now closed all errata, and new draft of errata doc should be out this afternoon - new rev of docs & schema should be ready 30 May, so 31 May will be last chance to say "Eve, you missed one" - Errata doc will change again after that to reflect disposition change to "incorporated" - Eve: would be nice to have extra pairs of eyes committed to double- checking - Krishna & Prateek commit > > 4. Verification of company attestations - esp. note Karl Best's > message citing policy section 3.2(A) indicating that each > implementation must have taken "adequate steps to comply with any > such [IPR] rights". We will review briefly what that means for > SAML and I'd like each implementer to have considered the RSA IPR > claims and what that means to them. > - Joe: only 1 IPR claim presently (from RSA) - there are no formal steps provided from RSA at this time - Rob: RSA had committed to getting a process to the committee by 31 May - he believes it should not hold up anyone's attestation - Joe: so details will come too late to alter submission, but in month of June, details could cause parties to withdraw attestations, and cause us to pull spec submission - we will lose face significantly in this event, so all parties must be prepared to work this out - Joe: implementers need to re-assert attestations - done verbally on call - Charles: does this apply only to browser POST profile, or to everything? - Rob: there are other scenarios outside of POST profile that are covered by patent - Joe: so we are still a "go" - Joe: looking for 3rd attestation of Req/Resp of AuthZ - Prateek: Crosslogix claims to support this - Joe: that would make the 3rd - Joe: any discomfort making attestation claims less granular? - motion: "We have determined that there are more than 3 independent implementations of SAML, and details will be made available later" - [VOTE] no opposition, passes > > 5. Vote to approve spec with errata fixes to be submitted to OASIS as > a candidate specification. > - motion to approve spec with errata fixes to be submitted to OASIS as a candidate specification - [VOTE] no opposition, passes - << and there was much rejoicing ... yeah >> > > 6. New Business > - Creation of liaison to the Joint Committee on Security - Intent of committee to coordinate direction on security - each security-related committee needs to create a liaison sub- committee - currently, Joe and Jeff are named for SSTC - Joe prepared to attend as the putative liaison sub-committee - Krishna: would like to be part of sub-committee - Phill: believes lots of this group would like to participate - Krishna: what is relationship between the JC and the TAB (Tech Advisory Board) - Joe: not defined yet - motion to name Joe & Jeff as the formal liaison sub-committee, which will be re-addressed in future SSTC meetings - [VOTE] no opposition, passes - Schedule of future SSTC concalls - Joe: doesn't want weekly, anyone suggest less frequent than every to weeks? - none - Will remain bi-weekly - RLBob: attendance and membership rules continue? - Joe: yes - Prateek: has put doc on table of unfinished business and would like TC to take it up for consideration - motion to take this up as first priority - [VOTE] no opposition, passes - Krishna has a road map to propose - Krishna raises issue of Kerberos - Rob: should we consider overlapping work on other specs, e.g. WS-Security, XrML? - much discussion ... - the spirit of the committee is that are strong reasons to look for collaboration, and over the next weeks (and in particular, on the next call in two weeks), we will be brainstorming ways to accomplish this - TC is asking Phill, as a member of the authoring group, to extend an invitation to the rest of the authoring group to join us in that brainstorming session - Rob: another item is a registry for new authN methods, etc - Joe: can this be part of the road map effort? - Rob: sounds fine - Prateek: would add to that the bindings & profiles, which is essentially the same spirit - Joe: assignments - Prateek will lead the SAML SOAP Profile - for the road map, need people to outline and bring to committee the topics 4 weeks from now - volunteers will be solicited at next call (11 June) > > 7. Adjourn > - Adjourned ----------------------------------------------------------------------- Attendance of Voting Members: Allen Rogers Authentica Irving Reid Baltimore Krishna Sankar Cisco Carlisle Adams Entrust Don Flinn Hitachi Joe Pato HP Marc Chanliau Netegrity Prateek Mishra Netegrity Charles Knouse Oblix Steve Anderson OpenNetwork Rob Philpott RSA Security Jahan Moreh Sigaba Bhavna Bhatnagar Sun Eve Maler Sun Emily Xu Sun Bob Morgan UWashington Phillip Hallam-Baker Verisign Attendance of Observers or Prospective Members: Robert Griffin Entrust Robert Zuccherato Entrust Simon Godik (individual) Membership Status Changes: Robert Griffin Entrust - granted voting status after call Robert Zuccherato Entrust - granted voting status after call -- Steve
Attachment:
sanderson.vcf
Description: Card for Steve Anderson
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC