[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Focus Call Minutes, November 2, 2004
Rob Philpott Rebekah Metz Gavenraj Sodhi Eve Maler Abbie Barbir Greg Whitehead Scott Cantor Peter Davis Forest Yin Rick Randall New agenda items: 1. (1) Mail from Thomas Wisniewski on Name Identifier Update http://lists.oasis-open.org/archives/security-services/200411/msg00014.h tml (2) Comment from JP Morgan http://lists.oasis-open.org/archives/security-services-comment/200411/ms g00000.html (3) Eve comment on schema location http://lists.oasis-open.org/archives/security-services/200411/msg00020.h tml 2. Rob: we have not yet received three attestations. Proposal to continue making editorial and non-substantive changes to specification. We would vote on December 7 to re-affirm CD status. 3. <AuthnRequest> conformance. Lots of email starting with: * http://lists.oasis-open.org/archives/security-services/200410/msg00059.h tml * Concensus seems to be to do nothing. CLOSED. 4. Eve: Registration process for 3rd-party SAML customizations * http://lists.oasis-open.org/archives/security-services/200410/msg00036.h tml Eve proposes to add tweaked text to the website. Rob and Prateek concur. Rick: how can contributed submissions attain official status within the TC? Prateek, Eve: explain process steps for attaining CD status 5. Public review comments from farrukh.najmi@sun.com * http://lists.oasis-open.org/archives/security-services-comment/200410/ms g00002.html * Scott's response: http://lists.oasis-open.org/archives/security-services-comment/200410/ms g00003.html Eve: issue has been around for some time. Suggestion is that schema location hint follow the model used in XML-ENC. Currently, we are using more general pointer to schema location. Scott: Concern that XML-ENC schema location model is not a good one. DIscussion about use of schema location hint. Resolution that we will follow XML-ENC model but add text in core explaining that this is only a hint. 6. Tom Scavo comment re: Identity Provider Discover Profile > > * > http://lists.oasis-open.org/archives/security-services-comment/200410/ms g00004.html Changes have been made, Scott has sent a response 7. Comment from sean@smo.uhi.ac.uk <mailto:sean@smo.uhi.ac.uk> re: > Profiles > > * > http://lists.oasis-open.org/archives/security-services-comment/200410/ms g00006.html Scott has sent message encouraging submission of new profiles. > 8. Scott's response to Rob's initial comments on -core-02 > > * > http://lists.oasis-open.org/archives/security-services/200410/msg00089.h tml > 1. Section 3.7.3.2 Session Authority Rules (Lines > 2506-2509), states that the protocol does not permit partial > success and that "any error during the propagation of logout > requests. MUST result in the failure of the overall logout > process ...". Doesn't this imply that somehow logout Scott has made the changes, Rob will review. > 2. There was a question about why the "terminate" option > of the Name ID Management Protocol was combined with the ID > management and thus now always requires a response to be > returned. In Liberty-based FederationTerminationNotification Rob main concern is about Liberty community. Will they object? Scott doesn't think so. ALL ISSUES HAVE BEEN ADDRESSED. Rob to provide text explaining why we use terms like user, principal, subject etc. > 9. Additional comments from Rob on -core-02 > > * > http://lists.oasis-open.org/archives/security-services/200410/msg00085.h tml > > * Scott response: > http://lists.oasis-open.org/archives/security-services/200411/msg00000.h tml Item 1 discussed by Ron, Scott, and Rob. Ron has commented on item 1: http://lists.oasis-open.org/archives/security-services/200411/msg00001.h tml Proposal to use Ron's text with removal of either/or from definition. Discussion of Conor's suggestion: http://lists.oasis-open.org/archives/security-services/200411/msg00009.h tml Scott to add text based on Ron's text and discussion during the call. Item 2: Scott will add an example explaining use. Item 3: similar to 2 and closed Item 4: Scott suggests that implementation guidelines should discuss subject confirmation. Rob agrees issue is closed. Item 5: Scott has updated the text but wonders if it is much improved. Rob will review and believes it is closed. Item 6: closed. Item 7: Scott will make editorial update to same. Item 8: text has been re-spun. Item 9: Done Item 10: Close. Item 11: There is a reason for this choice, there is no issue here. Item 12: Updated in text. Item 13: Agreed to update to InvalidAttrNameOrValue Item 14: Update text to reflect that it is used more generally, whenever NameIDPolicy cannot be satisfied. Item 15: Rob agrees it is good enough. Item 16: closed. Item 17: Scott argues that this text is intentional, does not want to import binding-related notions into the core. Item 18: Closed. Item 19: Closed Item 20: Resoulution SSO profile will include sentence that AllowCreate element should have value true to enable creation of federated identifier when fulfilling AuthNRequest. Item 21: Test has been updated. Closed. Item 22: Text updated. Closed. 11. Open AI regarding update of IETF MIME type information. NEW AGENDA ITEMS (1) Mail from Thomas Wisniewski on Name Identifier Update http://lists.oasis-open.org/archives/security-services/200411/msg00014.h tml Suggestion: omit the word persistent, add sentence saying that protocol is not typically used for transient identifiers. (2) Comment from JP Morgan http://lists.oasis-open.org/archives/security-services-comment/200411/ms g00000.html Prateek: I will respond to this message, SSTC considered this feature, decided it didn;t fit within our timelines. We are open to considering this type of functionality in the future. (3) Rob's message on profiles-2.0-cd-02 Scott: processing rule for Address is described in the section. (4) http://lists.oasis-open.org/archives/security-services/200411/msg00021.h tml Item 1: Scott to pull text on inheritance from parent from material that follows. Item 2: Discussion if there is any clarification needed here. Proposal to add comment explaining why there might be more than one <IDPSSODecscriptor> elements with different settings. Item 3: Remains as is. Item 4: Discussion around whether this can be accommodated in the current go-around. Greg asks why it isn't it enough that each partner receives data relevant to them. Suggestion to add to metadata specfication explaining that metadata does not include any means of targetting information to particular partners. Item 5: Suggestion to allow portions of attribute authority descriptor to apply to IdPs. Item 6: As in 5. Item 7: Review the current text and update if needed.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]