OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[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 ...


-----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 ...

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
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

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

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?

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC