[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wss] Minutes from F2F #2
Day 2 morning minutes ... -- Steve -----Original Message----- From: Steve Anderson Sent: Friday, December 13, 2002 4:50 PM To: OASIS WSSTC (E-mail) Subject: [wss] Minutes from F2F #2 The minutes were taken by 4 different individuals, each taking different half-day shifts (starting with me). Since we have a short timeframe before next Tuesday's call, I will post them essentially as-is. Some have summaries, some do not. For those that have summaries, items in those summaries may have been addressed and resolved differently in subsequent sessions. Therefore, I advise reading through these minutes (carefully) in the order posted. Four postings to follow ... -- Steve ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
WS-Security Minutes 12 Dec 02 9-11:30 ** Walkthrough led by Tony of new core document changes - posted last night --- Issue #3, label tokens Tony Nadaln: revision to document was that at line [676] added new optional Usage attribute to security token reference, taking a QName value. The default value is wsse:UsageBind. Jerry Schwartz/Ron Monzillo: does it mean anything? Chris Kaler: don't specify, if no attribute how would you describe the usage. Specifically stating default Ron always have this meaning for signatures Chris only doing a bind Hal Lockhart: what does within a signature mean Chris could be used not within a signature ACTION: change the wording from "assertion" to "claim" Hal - For originanating & intermediary tokens, how to label with usage, since it applies to both Chris; only means that it is default, can't combine with other label Ron: want other labels Chris: put out mechanism we have now, have team decide what we need to do Ron need affirmative value, not conflict Chris get rid of default, have team decide on QNames ACTION: Team will decide list of valid QNames, will leave mechanism in document. Hal: Clarification, can you have more than one Tony: yes Ron: this is how to label security token reference from signature. Bill Cox: Keep the table until the group puts something in. Chris: defining mechanism was core to issue, resolved. Subsequent issue is to define list of QNames Tony :why is table not acceptable Hemma Prafullchandra: keep it until we have improvements Hal: what does it mean with token with this label that isn't used for a signature, is it an error Or token with a signature, Tony this does not need to be the default, Ron what if token is by itself Tony remove defaultness, just one of many possibilities Rob make default - no usage implied Ron not saying more with UsageBind, doesn't add anything, Tony if parsing might want a default value ACTION: QNames to be defined later, TBD for new table entry STATUS: Closed pending vote, new issue on defining Qnames Chris post interop version issue Hal had original proposal ACTION - Add new issue to define QNames, Hal will start activity to define list --- Issue 26 process a BinarySecurityToken Ron wrote line numbers for edits, not given to Tony yet, view edit online, in 06 merged 8 Dec draft See lines 433, 511, 593,670 (also search for process | compliant) Frederick Hirsch can add general statement at beginning to state what processing means. Have put proposal on list, Rob Philpot ACTION: add issue for 434 all implementations must declare which profile they support ACTION: editors merge Frederick & Tim statement, place into document up front, add note in error section STATUS: Closed pending reviewed changes to be performed by Tony. Will have status Monday. Vote on tuesday, doc out sunday ---- Issue: 28 Prateek Mishra has written proposal for referencing SAML assertions from security header. Independent of id issue. Two parts: 1. use key identifier container defined in the token reference section as all SAML assertions have "key" ValueType saml:assertion containing Assertion IDReference. Impact on core - none Chris why using the element AssertionIDAssertion Prateek SAML encourcages this usage Chris moves to mixed content model. KeyIdentifier usually just has string under it, now can be string or complex type. Many tools break or are inconsistent with mixed content value Rob Philpot put ValueType saml:AssertionIdReferenence, removing AssertionIdReference element Chris default encding type is base64, need new encocding type xsi:string ACTION: editors add new encoding type for xsi:string to core document Prateek: Now extended form: Reference available from SAML authority Use saml:Binding: URI describing concrete protocol used by SAML authority saml:Location: attribute describes location of authority ACTION: SAML binding introduces use of the two attributes from SAML core - saml:Binding, saml:Location Jerry: sig outside header, must be able to process it there. Is this generic mechanism Prateek No security token references are limited to occur in security header. Chris can be used anywhere you want to reference a token use only defined for signatures but could be used anywhere. Signature SHOULD appear in security header. what is issue Jerry using library for sig, encryption with plugins for saml chris not appropriate to describe other usage models ACTION: editors add wording to document - unspecified what it means to use a security token reference outside of the security header Ron can this be used for a data reference, any cases when you don't need both binding and location Prateek - although only one binding is defined (http) need both [Ron presents use diagrams] Prateek core need id or XPath for signature References Chris SAML binding could define transform to get saml assertion for id Action Need to define a digital signature transform for dsig to enable remote saml token action Frederick: XML Sig SignedInfo Data reference to remote token, what does core define. Need to define transform to enable use chris vote at concall after folded into SAML assertion STATUS 28 pending, Ron sending out document by Monday morning, and vote ---- Issue #36 Created be dateTime? [1183] merged 8 Dec doc 10.2.1 creation. STATUS: Tony; Changed document to state that default is xsd:dateTime for ValueType. Rob any recommendation on format, SAML says must be UTC, should not rely on time resolution better than milliseconds Tony further up it says UTC, Rob What is compelling reason Prateek not meaningful to use too fine a resolution from SAML- all time values have XML Schema dateTime, MUST be UTC, not rely on time resolution greater than milliseconds, must not leap seconds. Frederick: MUST on UTC or recommended (note that SAML is MUST)? chris recommended since some legacy systems can't do UTC STATUS: pending edit, and vote ---- Issue # 19 tony - why is it a special case Phil G has proposal. chris - postpone username issue into next version, any objections ron - yes, would like to see it in draft chris propose keep what is in current draft and keep issue is open ron password based signing profile is critical to us chris - want to keep us moving, interop on X.509, issue has taken a long time monica, gene separate XCBF from username issue ron RFC shows algorithm for HMAC, one important use case Shawn generation of key from password chris - sounds like a profile put infrastructure in the core doc profile to define algorithms for defining algorithms Martijn Boer - take out password completely for interop draft write password doc chris need to be able to support new algorithms, without revving doc Ron can identify algorithms only Chris no, need additional data for some, need to profile to add this additional data Phil G - don't want to remove things that are part of real use cases before "interop draft", need to be there early on, if really important. Want to make sure get done to level needed to make specs meaningful chris - initial interop will be difficult, try to keep first simple, have additional interops as profiles added Phil G - sends negative message not to spec important aspects by saying we will interop everything in spec, might not interop everything in spec so have everything in spec, lesson from ebXML john shewchuk keep username password token in, get concrete proposals, consider changes. Need concrete proposal from Ron. chris - don't do username/password on first interop, focus on x.509 ron is it correct to call this an interoperabilty draft? -break- -----
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC