[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] List of open action items as of April 30, 2004
The following issues should be marked closed: #0152: Updates to ECP Profile See http://www.oasis-open.org/archives/security-services/200404/msg00055.html #0149: Propose text for FIPS Compliance see http://www.oasis-open.org/archives/security-services/200404/msg00095.html regards, Frederick Frederick Hirsch Nokia > -----Original Message----- > From: ext Mishra, Prateek [mailto:pmishra@netegrity.com] > Sent: Friday, April 30, 2004 4:27 PM > To: security-services@lists.oasis-open.org > Subject: [security-services] List of open action items as of April 30, > 2004 > > > > 0161: Remove KeyInfo from Assertion top-level > Owner: Eve Maler > Status: Open > Assigned: 30 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-30 18:16 GMT > o Mike - what is difference in meaning for KeyInfo at top > versus KeyInfo > inside SubjectConfirmationData > > o Eve - no, just a syntactic > > o discussion ensues, decision to remove KeyInfo > > o Prateek - eliminating holder of key, Ron will have comments > > o Decision - remove KeyInfo, allow within SubjectConfirmationData > > *** AI - Eve to implement decision on core 18 after checking with Ron > > -------------------------------------------------------------- > -------------- > ---- > > #0160: Separate Privacy concerns language from Element/Attribute > descriptions > Owner: Prateek Mishra > Status: Open > Assigned: 30 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-30 18:14 GMT > Jeff H - We need to highlight privacy considerations related > to core, could > be notes in core, could be section. > *** AI: Prateek - will generate list potential changes from core > > -------------------------------------------------------------- > -------------- > ---- > > #0159: Propose "Binding conditions" concept > Owner: Scott Cantor > Status: Open > Assigned: 30 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-30 18:13 GMT > Scott's "Binding conditions" > *** AI: Scott to draft proposal > > -------------------------------------------------------------- > -------------- > ---- > > #0158: Propose changes to definition of Federation in glossary > Owner: Prateek Mishra > Status: Open > Assigned: 30 Apr 2004 > Due: --- > Comments: > > > -------------------------------------------------------------- > -------------- > ---- > > #0157: Define Binding and Profile in Glossary > Owner: Jeff Hodges > Status: Open > Assigned: 30 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-30 18:10 GMT > o "atomic unit of interoperability" proposed > > -------------------------------------------------------------- > -------------- > ---- > > #0156: Determine how Kerberos principals can be represented as > NameIdentifiers > Owner: Scott Cantor > Status: Open > Assigned: 30 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-30 18:01 GMT > *** AI - Scott Determine how Kerberos principals can be represented as > NameIdentifiers. 1510 possibility. > > -------------------------------------------------------------- > -------------- > ---- > > #0155: Message asking if deprecation of AuthenticationMethod > is acceptable > Owner: Prateek Mishra > Status: Open > Assigned: 30 Apr 2004 > Due: --- > Comments: > > > -------------------------------------------------------------- > -------------- > ---- > > #0154: Schema changes so that AuthenticationMethod and AuthContext are > parallel choices > Owner: John Kemp > Status: Open > Assigned: 30 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-30 17:58 GMT > We need to resolve if we will deprecate SAML AuthenticationMethod > > *** AI: On hold - make schema changes so that AM and AuthContext are > parallel choices > > -------------------------------------------------------------- > -------------- > ---- > > #0153: add ReauthenticateOnOrAfter > Owner: Scott Cantor > Status: Open > Assigned: 29 Apr 2004 > Due: --- > Comments: > > > -------------------------------------------------------------- > -------------- > ---- > > #0152: Updates to ECP Profile > Owner: Frederick Hirsch > Status: Open > Assigned: 29 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-29 22:05 GMT > o FH- also changed messageId, recommended that it be not > used, but if used, > rersponse must have correlation > > *** AI: Section 3.3.4.1 - need to add back SOAP Header to > allow an ECP to > get info from the SP without having to parse AuthnRequest. > > -------------------------------------------------------------- > -------------- > ---- > > #0151: Limit number of supported combinations > Owner: Prateek Mishra > Status: Open > Assigned: 29 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-29 22:04 GMT > o PM- just because we can do it 3 ways doesn't mean we have > to define them > as SAML approved. Need to pull their weight. Somebody needs > to drive this > discussion. So who is going to this? > > *** AI: Prateek takes ownership of driving a discussion on limiting > combinations. > > -------------------------------------------------------------- > -------------- > ---- > > #0150: Relax Single AuthNStatement Constraint > Owner: Scott Cantor > Status: Open > Assigned: 29 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-29 22:02 GMT > o SC- Response Profile more extensive than that for AuthnRequest > > o IR - the restriction that there be only a single > AuthenticationStatement > is too strict, SC- OK (will change) > > *** AI: Scott: Relax AuthenticationStatement Occurrence > > -------------------------------------------------------------- > -------------- > ---- > > #0149: Propose text for FIPS Compliance > Owner: Frederick Hirsch > Status: Open > Assigned: 29 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-29 22:01 GMT > Tony asks a question about Sec. 3.1 (SSL/TLS), noting that > some customers > may require use of FIPS cipher suites, which apply only to > TLS and not to > SSL. He observes that IBM has evaluated FIPS requirements, > and has concluded > that non-FIPS algorithms must not be included in > FIPS-compliant deployments. > > o Hal asks what change would satisfy this concern. This has also been > discussed in WS-I. > > *** AI: Fred Hirsch will propose text. > > -------------------------------------------------------------- > -------------- > ---- > > #0148: Artifact format proposal for SAML 2.0 > Owner: Jeff Hodges > Status: Open > Assigned: 29 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-29 21:58 GMT > o An action is needed to propose artifact types; SAML and Liberty have > different types, and Liberty's includes metadata. > > o Prateek believes that convergence on a single type is > desirable, and that > this should have been done in SAML 1.1; > > o Jeff Hodges agrees with this goal, but Rob sees this as > less important. > > o Liberty's artifact format contains a hash of a provider's > identity, which > doesn't permit metadata lookup. Backward compatibility will need to be > considered if and as new types are specified. > > *** AI: Jeff Hodges will make a concrete proposal for a > common artifact > format. > > -------------------------------------------------------------- > -------------- > ---- > > #0147: Chairs to solicit comment from saml-dev on gzip encoding > Owner: Prateek Mishra > Status: Open > Assigned: 29 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-29 21:57 GMT > Prateek wants to avoid having multiple encoding methods, and a working > consensus in favor of the gzip approach appears to be developing. > > o Jeff Hodges suggests that implementers' comments be > solicited, and Prateek > recommends that the chairs send a message to the saml-dev list. > > *** AI: Chairs to solicit comments. > > -------------------------------------------------------------- > -------------- > ---- > > #0146: SOAP Binding works with WSS Model > Owner: Hal Lockhart > Status: Open > Assigned: 29 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-29 21:54 GMT > *** AI: Hal: Look at SOAP binding and make sure hand waving > on WS-Security > works. > > -------------------------------------------------------------- > -------------- > ---- > > #0145: Encryption Schema and Examples > Owner: Hal Lockhart > Status: Open > Assigned: 29 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-29 21:53 GMT > Hal: Summary: agreement to encrypt SAML Attribute Statement. Allow > encryption of Assertion Statement, NameIdentifier and > Attribute Statement. > > *** Follow-up: Need schema and some examples. > > -------------------------------------------------------------- > -------------- > ---- > > #0144: Explain optional subject decision > Owner: Eve Maler > Status: Open > Assigned: 29 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-29 21:51 GMT > *** AI: Eve: Optional subject implemented in core spec prose. > Schema shows > that subject is optional. > > o Eve: Has wanted to create a rationale for some of the > decisions made on > spec. Decision on subject less statements is a good example > of what needs to > be documented. Making an explicit design decision that is not really > explicit on. By choosing to add prose to core spec we're > making a stealth > abstract profile (generic design decision) that applies to > all explicit > profiles. > > o Scott: data model (design) decision to require subjects in all SAML > statements. > > -------------------------------------------------------------- > -------------- > ---- > > #0143: Check SAML schema for consistency > Owner: Eve Maler > Status: Open > Assigned: 29 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-29 21:49 GMT > *** Follow-up: Examine SAML schema for consistent use of XML > attributes vs. > elements > > -------------------------------------------------------------- > -------------- > ---- > > #0142: RegisterNameIdentifier to handle unregister case > Owner: Scott Cantor > Status: Open > Assigned: 29 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-29 21:48 GMT > *** AI: Scott: propose change to RegisterNameIdentifier to > handle unregister > case and consider specifying an attribute that identifies intent of > operation. > > -------------------------------------------------------------- > -------------- > ---- > > #0141: Review/fix boilerplace text for Artifact Protocol > Owner: Eve Maler > Status: Open > Assigned: 27 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-27 15:24 GMT > o Prateek: Should we sign or authenticate? > > o Scott: Common language on all protocol messages. > > o Prateek: Concerned about text on line 2118 "...SHOULD be signed or > otherwise authenticated...." > > o Scott: Not a MUST, need to provide some recommendation to > protect message. > > > o Eve: this is boiler plate text for all messages. Need to > agree on the > correct text for this. > > ***Follow-up: Review/fix boilerplate text re: recommendation > for protecting > messages > > -------------------------------------------------------------- > -------------- > ---- > > #0140: Update extensions element to use ##other > Owner: Eve Maler > Status: Open > Assigned: 27 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-27 15:22 GMT > Scott - added Extensions element - modeled to be consistent > with SOAP header > element - i.e. multiple extensions within one Extensions > (header) element. > o Discussion of ##any vs. ##other. > > o Should use ##other. > > o Scott - should we have a wrapper element for extensions? > > *** Follow-up: Resolution: change Extension to use ##other > > -------------------------------------------------------------- > -------------- > ---- > > #0139: Followup on a recipient attribute for the encryption key > Owner: Scott Cantor > Status: Open > Assigned: 27 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-27 15:20 GMT > Eve reviews EncryptedNameID > o Scott mentions 0 or more key distribution for Enc NameIDs. > Scott also > mentions 'recipient' attribute for the key - do we want to > make that a MUST? > > > -------------------------------------------------------------- > -------------- > ---- > > #0138: Schema snippet for UID Attribute Profile > Owner: Scott Cantor > Status: Open > Assigned: 27 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-27 15:10 GMT > XML schema for UID/OID plus friendly name > > -------------------------------------------------------------- > -------------- > ---- > > #0137: Propose text for core on validity of assertions > Owner: Bob Morgan > Status: Open > Assigned: 27 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-27 15:07 GMT > http://lists.oasis-open.org/archives/security-services/200404/ > msg00048.html > > -------------------------------------------------------------- > -------------- > ---- > > #0136: SSO Validity Proposal to be moved into bindings draft > Owner: Scott Cantor > Status: Open > Assigned: 27 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-27 15:02 GMT > - Scott to implement SSO validity from proposal into > next draft > > -------------------------------------------------------------- > -------------- > ---- > > #0135: Why does signature need to be the first element? > Owner: Eve Maler > Status: Open > Assigned: 27 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-27 15:00 GMT > - Eve to ask Bhavna to post motivation for moving Signature to > front > > -------------------------------------------------------------- > -------------- > ---- > > #0134: Availability of GZIP Implementations > Owner: Greg Whitehead > Status: Open > Assigned: 27 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-27 14:58 GMT > - Greg to ensure that readily available GZIP implementations > can conform to our description in bindings > > -------------------------------------------------------------- > -------------- > ---- > > #0133: Review role of EncryptedNameID recipient attribute > Owner: Scott Cantor > Status: Open > Assigned: 13 Apr 2004 > Due: --- > Comments: > > > -------------------------------------------------------------- > -------------- > ---- > > #0132: Text to explain privacy reqts when using certain > NameFormat values > Owner: John Kemp > Status: Open > Assigned: 13 Apr 2004 > Due: --- > Comments: > > > -------------------------------------------------------------- > -------------- > ---- > > #0131: Migration document describing changes to subject in SAML 2.0 > Owner: Jeff Hodges > Status: Open > Assigned: 13 Apr 2004 > Due: --- > Comments: > Prateek Mishra 2004-04-13 04:31 GMT > Explain how treatment of subjects have changed in going from SAML 1.X > to SAML 2.0. This might be an action for Scott? > > -------------------------------------------------------------- > -------------- > ---- > > #0130: Respond to paper on SAML 1.1 Browser Profiles > Owner: Prateek Mishra > Status: Open > Assigned: 29 Mar 2004 > Due: --- > Comments: > Prateek Mishra 2004-03-29 17:04 GMT > Maryann Hondo and Prateek Mishra to draft response to paper > by Thomas Gross. > > > -------------------------------------------------------------- > -------------- > ---- > > #0128: Liason with XRI Data Interchange > Owner: Hal Lockhart > Status: Open > Assigned: 02 Mar 2004 > Due: --- > Comments: > Prateek Mishra 2004-03-02 04:33 GMT > Hal will generate a posting on possible need to liaison. > > -------------------------------------------------------------- > -------------- > ---- > > #0125: Propose language to explain that AuthNResponse may > contain attribute > statements > Owner: Prateek Mishra > Status: Open > Assigned: 16 Feb 2004 > Due: --- > Comments: > Prateek Mishra 2004-02-16 14:46 GMT > Easy to do but needs proposal on validity of assertion > life-times as well. > > -------------------------------------------------------------- > -------------- > ---- > > #0123: Obtain MIME type registration for HTTP lookup of SAML > Owner: Jeff Hodges > Status: Open > Assigned: 13 Feb 2004 > Due: --- > Comments: > > > -------------------------------------------------------------- > -------------- > ---- > > #0117: Describe use-cases for attribute-based SSO in > relationship to ID-FF > 1.2 NameIdPolicy > Owner: Prateek Mishra > Status: Open > Assigned: 11 Feb 2004 > Due: --- > Comments: > > > -------------------------------------------------------------- > -------------- > ---- > > #0114: Propose language to address attribute-based federation > Owner: Prateek Mishra > Status: Open > Assigned: 19 Jan 2004 > Due: --- > Comments: > Prateek Mishra 2004-01-20 03:22 GMT > We could break the bilateral assumption that account linkage and > > http://lists.oasis-open.org/archives/security-services/200312/ msg00064.html ---------------------------------------------------------------------------- ---- #0112: Update (W-7) discovery protocol solution proposal Owner: Scott Cantor Status: Open Assigned: 19 Jan 2004 Due: --- Comments: Prateek Mishra 2004-01-20 03:17 GMT ACTION: (SC) Update based on replacement of hash of succint id by literal provider id. ---------------------------------------------------------------------------- ---- #0105: Respond to IBM Analysis Paper Owner: Status: Open Assigned: 19 Jan 2004 Due: --- Comments: Prateek Mishra 2004-01-19 23:09 GMT - [ACTION] Scott & Tony to make recommendations based on IBM security analysis paper To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]