[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] Minutes for Focus Group, Tuesday Oct 23
Minutes for SSTC Focus Group, Tuesday Oct 23 Dial in info: +1 334 262 0740 #856956 Minutes taken by Steve Anderson Attendees: Allen Rogers Authentica Irving Reid Baltimore Simon Godik Crosslogix Gil Pilz E2open Hal Lockhart Entegrity Tim Moses Entrust Don Flinn Hitachi Joe Pato HP Jason Rouault HP Chris McLaren Netegrity Prateek Mishra Netegrity Steve Anderson OpenNetwork Darren Platt RSA Phillip Hallam-Baker Verisign Thomas Hardjono Verisign Scott Cantor IBM Agenda - Non-closed Action Items from last concall - New Items: - Simon’s proposal sent to list - Chris: Shib status codes Action item: Scott will propose text that documents the detailed semantics of NameIdentifier - Sent clarification to list - Subject line was "Suggested addition to core-19.doc, sec. 1.3.2.2", dated Oct 9 - No discussion on list so far - Prateek: so we are not going to call out any distinguished name identifier scheme for purpose of pseudonymity? - Scott: correct - Joe: move issue to being closed & accepted - Phill making change in Core doc - Closed Action item: Krishna to drive SAML profile of xmldsig - Tabled Action Item: Don to elaborate the number of 1-1 relationships and propose how to fix the resulting scaling issues - Considering pulling issue - Issue of number of capacity to handle large number of simultaneous connections - Can be dealt with in implementation & deployment - So, can't do anything about problem, and it can be solved with additional hardware - Closed, Withdrawn Action item: Prateek "Security properties of Assertion Handle" - Still open - will send text to BobB by Friday Action item: Tim, Simon, Prateek (champions): compose complete recommendation for "Relying Party tailors assertion in browser artifact profile" - Prateek: Essentially closed - Text has been received by Prateek - will update draft and share with bindings group - Tim sent proposal to Phill, who made counter proposal, mainly due to differences in Core 16 & Core19 - [ACTION: Tim] Tim to propose how to modify core19 (rather than core16) - Joe: Try to have closed by next week Action item: Scott, Marlena to champion "attribute scope" - Current approach in Core doc is sufficient - Allows arbitrary XML in attribute assertions - Closed Action item: Simon: to champion "Query refinement proposal" - Still deferred to F2F#5 Action item: Prateek -- senderVouches security model - Sent text to list - Got responses from Bob & Mack Hicks - Integrated into bindings draft - Bindings call this week will cover further - Keep open until next week New Item: Simon’s proposal - In email w/ subject "Attribute Authority information in Authentication Assertion proposal", dated Oct 22 - Joint submission with scott & marlena - Orig context - From Shib design - Relying party doesn't know what Attrib authority to use, based on authN assertion - Wants to include indicating info in authN assn, using URI - AuthN assn will only point to attrib authority - Joe: how is attribute linked to authority? How is attrib scoped to authority? - Simon: not scoped, up to RP, mainly for purpose of obtaining attrib assn - Chris: had asked list whether this is in scope? - No response from list. Talked to Simon directly. - Prateek: agrees with question, believes this is a provisioning issue - Chris: Shib must have it, but it may not be in scope for SAML - Chris: allows info on subjects to include reference for additional info - If there is a way to do it with a Dir Svc, that's fine - Simon focused (correctly) on problem of different Attrib authorities responsible for diff segments of information on user - Scott - Given an AuthN event at an origin site, where does a RP go for more info? - Attrib authorities are inherently dynamically related, so only way to know is from AuthN assn - Chris: still a question of in/out of scope for SAML 1.0 - Scott: if not in scope, what extension point would be appropriate for this type of functionality? - Chris: clarifying that he's not for or against at this point - Irving: suggests Advice over Conditions, since conditions affect ability to use current assertion - Use of Advice limits interop - Irving: any other uses beyond AuthN event? - Scott: can't think of any, but there could be - Simon: Shib is first app of SAML, so we should ensure that Shib requirements are met - Scott: Shib hopes to be able to swap various SAML implementations in and out - Irving: his company making progress on Web browser Pull profile - Prateek: core issue is that only authN authority has knowledge of attrib authority - Scott: moves to table, so that people can think about question of scope - Don: how to express subject of attrib request to attrib authority? Particularly when authority needs proof of authentication of the subject - Subject field may be filled with just a name, or with an authN assn - Irving: authN assn in subject was not originally intended for this purpose - there's no use case to support this, not that this use is not valid - Trying to address Shib problem of controlled release of information about users - possession of authN assertion doesn't prove that entity has authenticated session with user, so this may not be useful for the problem at hand - Don: out-of-band trust relationship should have already been estab between authorities, which, combined with AuthN assertions, may be sufficient - [ACTION: Don] Don to add discussion material on list - tabled New Item: Scott's status codes - doesn't really have proposal on table - got impression that at some time later, this would eventually be covered - drawing attention to section 3 of core19 - case of error being returned expressing incompatible protocol - existing four status values in current schema are limiting - work is Shib is resulting in a running list of new status codes - just raising visibility of need for more expressiveness - not trying to make fuss prematurely - [ACTION: Scott] Joe: recommends Scott outline a proposal Prateek: reopening first issue (Scott's proposed text that documents the semantics of NameIdentifier) - Question on interop: - Presumably, cases where one sec domain communicates with another sec domain, won't something be necessary to enable interop - Scott: that was Marlena’s point - Shib doesn't have use case for it, but others may - Scott's current wording reflects current spec, which doesn't have a more formal mechanism - Prateek will consider whether to raise this as issue - Joe: changing structure of NameIdentifer later (post v1.0) will be difficult, so it should be considered carefully now - [ACTION: Prateek] Prateek will place issue on list today Issues to consider for next Tuesday's ConCall - Agenda for F2F - Date/location confirmed (20+ confirmed attendees) - Downtown SF at Bank of America - Can book flights now - Other logistics will follow soon - Phill Editorial question: Any other agreed-upon changes for Core19? - Multiplicity of NameIdentifier still in question - Basically, no - A few concrete proposals have been floated, but no consensus has been reached on them - Action items have been closed, but their related issues have not - [ACTION: Issue Champions] Up to champion to drive to vote, etc - [ACTION: Everyone] Phill wants everyone to look through Eve's proposed restructuring of document -- 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