[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for 1/25/2005
Please report any corrections or addition to the minutes to the list. The attendance list will be attached with the re-issued minutes. Don ================================================================== Minutes 1/25/05 Roll Call – Quorum achieved; 51voting members / 34 attending Minutes of 1/11/05 – Approved Hal - issue 347 was corrected. Please put it in issues list. Status of 1.1 Documents Tony – There are some open items for the proposed text that have not yet been agreed upon. Ron – Will get 1.1 version using SAML out soon. Put SAML 2.0 into the SAML Profile 1.0. SAML 2.0 to be voted on in Feb.; There is a composite profile that will add additional items, which will make 1.0 compatible with SAML 2.0. There are some differences in 1.1 schema, namely, can make direct references Chris – OASIS would prefer to have 1.1 revise all the token profiles. The WSS 1.1 profile should have a section that describes this. Hal – do we need an interop for 1.1 Chris – An interop will be needed on only new features Paul Cotton - Getting votes for only a few profiles is harder than for a new bundled version, thus getting 15% would be easier for full new version of WSS 1.1 than for just a SAML profile. Ron – true Paul – WS-I is debating whether they should profile 1.1 Kelvin – not too much difference in time between the two approaches Document for 1.0 is a standard, so we can’t go back. Ron – I have a writeup including SAML 2.0 based on 1.0 schema as well as one based on the WSS 1.1 schema Chris – put support for both SAML 2.0 and SAML 1.0 in WSS 1.1. We should be able to close 1.1 soon since there is only a small issue list We can produce 1.1 including all the documents. Ron – Should include kerberos Would prefer SAML 2.0 be based on core 1.1. Chris – We could have a section that would say how SAML 2.0 works with WSS Here’s how you use it with WSS 1.0 schema and the 1.1 schema. Ron – If there are any special cases for using 1.1 with 1.0 we should document them Should only have to look at one spec . Kelvin – Post to list Chris – What should the 1.1 token profile look like? Take what is there and if using 1.0 here’s what to do We are defining 1.1 as being compatible with 1.0 If you want to use this optional feature of 1.1 here’s how you do it. The first attempt at a consensus – Try get 1.1 done as soon as we can All profiles will be re-written for 1.1 profiles Include SAML 2.0 Design 1.1 profiles so they can work with 1.1 or 1.0?? (Discussion on this last item, which lead to a decision to go to issues list to see if it can be resolved as part of the open issue discussion.) Ron – We are modifying the STR by adding another optional element Issues List Pending Issues 349 pending 351 – assign to editors for change; Pending Review 352 - assign to editors for change; Pending Review 354 – Pending Open Issues 338 - No change 310 – VJ to get proposal to list; Ron will help. 250 – Ron to send proposal to the list There ensued a long discussion of issue 250. The final result was that there be a lead agenda item at the next telecom to vote on accepting either Ron’s proposal or Thomas’s proposal. However, if Ron and Thomas can come up with a common, combined proposal before the next telecom; that will be accepted. Synopsis of the discussion on Issue 250 Chris – Make a weak statement in 1.1 and strong statement in 2.0 Ron – If don’t have token type attribute present, you’re supporting 1.0 Chris - From a core 1.1 perspective, the attribute is optional What goes in the token profiles is to be discussed Ron - In my proposal –the core RECCOMMENDS that if profiles use 1.1 then they MUST use the attribute. Want a user to be able to tell when it is processing a 1.1 client. Should this be a global attribute or leave it as a local attribute? Chris – When writing a 1.1 profile define the 1.0 level and the 1.1 level which requires the attribute Ron – Profiles should define a token type attribute and should allow the use of direct references. Should WS-I define whether attribute should be there? Every profile has decision to make, require use of the attribute or not. An Example – If I support just two profiles; if the attribute is there, it makes it easy to tell if I support this particular profile Chris – in 1.0 don’t need attribute; in 1.1 must have the attribute What about the direct reference? Thomas – (In his proposal) The core specification RECOMMENDS that profiles should use token type attributes and if the profile defines the token type attribute they should require its use. Chris – To reach closure: We'll have an agenda item at the next telecom to vote on accepting either Ron’s proposal or Thomas’s proposal. If Ron and Thomas come up with a combined proposal then use that . Didn’t get to Kerberos agenda item. Adjournment -- Don Flinn President, Flint Security LLC Tel: 781-856-7230 Fax: 781-631-7693 http://flintsecurity.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]