[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft minutes for SAML F2F, Tuesday 3.29.2004 Morning
Roll-call - 19 present, therefore quorate arrange minute-takers - Tue morn - JohnK afternoon - Paula Wed morn - John L Wed afternoon - Paul Thurs - Frederick Accept minutes of last meeting - no objections, so approved Review agenda Hal would like to add an itemt to discuss ITU-T Frederick - add item to discuss WS-SMS, STP Tony - explains logistics - kitchen combination #542 Eve - review scope document + re-assess W12, W22, W23, W26 Re-assess W12 - attrib retrieval - anyone in favour? No - change to inactive W22 - assertion caching - anyone in favour? No - changed to inactive W23 - security workflow - no-one knows what it is - changed to inactive W26 - dependency audit - prateek cared once upon a time, and explains - Hal mentions use-case of making assertions about an issuer. Enhanced Condition definitions could support this. Changed to 'inactive'. Review liason activities: W18 - SASL. Is this critical for 2.0? Kerberos profiles could use this. Discussions ongoing, but maybe not in 2.0 timeframe. W20 - ebMS - not for 2.0 timeframe. Eve: Notes difference between active and completed - completed items are basically "feature complete". Eve walking through core - draft-08-diff Ref the XMLNS spec. - we hadn't done that before. Mostly editorial change to introduction. We need to updated the contributors vs. the editors. Eve explains difference between the two lists. Add to list of 1.1 contributors. Rob mentions that Karl has given rules on contributors. Eve discusses BaseNameIdentifier (RLBob, Mike Beach arrive) Eve reviews EncryptedNameID - 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? Review at some future point. AssertionURIReference - new element - should we mention that URN would require "special" resolution? If URL - security token reference to a SAML assertion. Scott - should probably ref SAMLBind - this is de-referenceable using that binding. Eve/Scott discuss referencing between documents. Eve - re-ordered Issuer Scott - re-ordered the ds:Signature element on suggestiong from JohnH Lighting discussions - lighting fixed. Everything is Illuminated Subject discussion. Irving wonders whether we're changing too much. Eve mentions the migration document Scott says it's Irving's fault. Rob + Greg says this is simpler. Conor agrees this makes processing simpler. Eve asks for volunteer to list changes. Scott says he'll write it up. Jeff H will do this! RLBob mentions problem between assertions and statements. There is an implied semantic of a Subject linked to the Assertion - just not syntactically. DoNotCacheCondition languuge improved by Scott. Conor - does this impact session established with SAML token? FJH - this is policy SessionIndex - Prateek objects to MUST NOT for globally unique ID. Discussion. Greg thinks you need normative langauge for this. Mentions use of the AssertionID. Scott mentions use of AssertionID, and then asks Prateek what the use-case is. Prateek wants to generate the same session id for each SP. Conor tries to remember what the use-case. Conclusion: Some (not mutually exclusive) Options: 1) Use AssertionID 2) Re-write language to be even more specific Greg presents an option to include JohnK to propose text to meet the privacy needs when using specific NameID Format values. Time for break. Eve discusses SubjectStatement changes. Auth Method - TBD at this meeting Discussion of authentication statement vs. authentication context statement Eve - better define the terminology of AuthnContext within that element. AttributeDesignator - for further discussion during the meeting. Proposal added as discussed at last F2F. AuthZDecisionStatement - implemented decision to freeze. Eve implemeneted changes regarding the derivation of protocols from Request/Response Scott - added Extensions element - modelled to be consistent with SOAP header element - ie. multiple extentions within one Extensions (header) element. Discussion of ##any vs ##other. Should use ##other. Scott - should we have a wrapper element for extensions? Resolution: change Extension to use ##other Scott: strongly suggests we use a wrapper element for extensions, in order to better be able to better determine the sequence of elements. Eve - explains difference between anyType, any, and anyAttribute Frederick - suggests unified model for schema extensibility (allow anyAttribute on ALL extension elements). Maybe want to add attributes to the Assertion? Scott - argue Ann's question about anyAttribute. Decision: 1) keep wrapper eleemnt 2) use ##other for now, and maybe expand scope if we find a good reason. Discussion of extension by extenders. Tony: Provide method of reference extensions. If I have an extension defined, and I want to reference it, how would I do that? Add anyAttribute in useful places. Discussion of status codes. Scott made a list in one place. Eve wanted to split them out. Rob - we need to have these in both places - should alphabetize in the list, and then refer to them in the protocol/profiles. Rob: Do we have to expose this much information in status responses? Scott: We didn't do anything gratuitously - tradeoff between usability and security Eve mentions use of Qname in StatusCodes for IOP causing problems. SubjectQuery - SessionIndex - what does it mean that Subject is now at the assertion level? Again we need to think about Subject-less-ness. Query processing rules (line 1682) text revised for type hierarchy of NameIdentifiers Scott - revised text about what it means to match SubjectConfirmation? Scott explains Authentication Request protocol - intent is to write a general protocol that can be profiled for specific uses. There are many complex things that you can do when authenticating. We took the Lib AuthnRequest, and exploded it into fully parametized assertion request. Profiles would then profile it down. Defined a vocab to capture the players in several scenarios. Hal: Why isn't this possible in current SAML? Scott explains use-case Conor - mentions Liberty use-case of authentication context - SP can control the strength of authentication. Hal + Conor converse. Paul: Policy advertisement mechanism Eve: Not policy. Hal: Requires capabilities not specified. Scott: Authority can't figure this out themselves - request should specify input. Scott continues - is this thing an auth authority, a credentials collector? Or what? Conor: Should be a separate discussion item on agenda Eve: Have we become too general? Hal: Need a general framework JeffH: We need to review the profiles well. Eve: Can we make some slides explaining this whole thing better? Scott to try and present this succinctly. Prateek: Lunch!
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]