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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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

Subject: Minutes, April 15,2003 Teleconference, corrected

Enclosed are a corrected version of the minutes, incorporating the corrections
from Rob and Eve. Thank you for the corrections.

regards, Frederick
Frederick Hirsch
Nokia Mobile Phones

Minutes April 15, 2003 SAML Teleconference

1. Role Call

Quorum achieved.

Irving Reid (Baltimore)
Hal Lockhart (BEA)
Ronald Jacobson (Computer Associates)
John Hughes (Entegrity Solutions)
Carlisle Adams (Entrust)
Robert Griffin (Entrust)
Prateek Mishra (Netegrity)
Frederick Hirsch (Nokia)
Senthil Sengodan (Nokia)
Charles Knouse (Oblix)
Rob Philpott (RSA Security)
Dipak Chopra (SAP)
Jahan Moreh (Sigaba)
Bhavna Bhatnagar (Sun)
Jeff Hodges (Sun)
Eve Maler (Sun)
Emily Xu (Sun)
Phillip Hallam-Baker (Verisign)
Scott Cantor (individual)

2. Minutes accepted from last call. ( April 8, 2003 )

3. Discussion and Voting: 

(a) Letter of submission of LA 1.1 specifications to SSTC 


Proposed motion: 
The SSTC accepts the submission from HP, SUN, RSA and Nokia, of the Liberty 
Alliance Version 1.1 specification (and forthcoming errata documents), as 
described in.. 


..for incorporation as appropriate into the SSTC's on-going and future work. 
Jeff - please let us know if any question, letter should cover all of Oasis requirements for

Jahan - does this mean Liberty will stop specifying further and hand it over

Jeff - Want to drive convergence between this portion of Liberty (1.1) and SAML. Yes,
on this portion of Liberty. V1.2 will be announced, intent is also to contribute those
formally. Drafts are available today on Liberty site. People who participate in both venues 
(Liberty and SSTC) should ensure proper coordination occurs.

Prateek - we should acknowledge submission in this motion, received as requested, plan to
do something with it.

Jahan - motion
Irving - seconded.

Hal - not required to accept submission, just like any other submission. Change from what was policy
in November.

Motion passed with unanomous consent.

(b) Impact on SAML 1.1 

Prateek - 1.1 has been cleanup, as well as missing pieces, including based on last years interop
Particularly, Browser site first flows, meta data proposal. What should SAML 1.1 be? Narrow
to cleanup and clarifications? What should we do with extensions?

Hal - Two proposals in question - champions should look at germaine Liberty portions and make a 
recommendation if it looks like Liberty adoption solves problem, if so adopt the Liberty solution, 
otherwise defer to 2.0

Scott - cannot adopt liberty in SAML 1.1 timeframe because of differences. Signifant value of putting 
proposals on table for SAML 1.1. Will there be divergences when we reconcile with Liberty. What is
proposed should be consistent

Jahan - metadata should go in 1.1, very concise

Scott - metadata changed considerably between liberty 1.1 and liberty 1.2 - placeholder in 1.1

Rob - Is metadata for entire liberty functionality or federation framework?

Scott - integrated, federated required 

Prateek - main concern at messaging, product level - consistency of SAML 1.1 and 2.0. Certain
flows from use case document have been implemented already - example of risks

Hal - should be ok to extend SAML, designed for that. Two principles: where SAML and Liberty
do same thing, should converge. Shouldn't do new things now we should undo. Can do part and add more 
later, e.g. data structure that can be extended.

Rob  with respect to metadata

Hal - not an opinion, needs to be evaluated

Scott - Significant difference between Liberty 1.1 and 1.2

Hal - is Liberty going to submit 1.2. Should we wait for 1.2?

Jeff 1.2 specs are available on the web, so we can work with them. They are very stable drafts, Liberty
is soliciting feedback, but they should not change much.

Rob - how long?

Hal - 2 weeks for members, then 2-4 weeks public review. Liberty versioning is confusing.

Jahan - we have nothing for metadata now, should have something sooner. 

Jeff - work I did and Prateek took leverages Liberty 1.1 metadata work. Needs revision and further 

Rob - will depend on schedule. Need dates to finalize 1.1 work.

ACTION: Jahan - analyize meta data issue, including Liberty 1.2 draft,  write up and publish to list. 
Plan for discussion on call in 2 weeks. 

defer decision on what to do with SAML 1.1 until the analysis done.

Scott - proposal in SAML context, GET profile differences from Liberty, not opposed to defer
until SAML 2.0

Jeff - SSTC need to finish 1.1 as soon as possible, submit for Oasis wide approval (monthly calendar, 
not quarterly, 1st of month),...

Prateek - April end goal to converge on committee spec

Scott - work on 2.0 can begin quickly

Rob - probably cannot get metadata into 1.1 by end of April

Jahan - will do what I can in week

Jeff - need to have last call in committee - June 1 submission either way. 

Scott need public review

Jeff - working group last call was 2wks last time - need to examine Oasis process. need detailed
schedule on last call, need to allow time to revise the specifciation. Should look at the older 
mail messages and compare to current process.

ACTION Chairs to publish proposed timeline to list. 

Hal Submission is 15th of month, public review prior, committee spec, IPR etc all before.

Jeff - need to get through reviews and specifications ready to submit. At that point most of 
committee can focus on 2.0 as chairs continue the process.

Eve - remember publicity, dee shure

Hal - need to allow time to revise specification, have vote. Need 3-5 days interval.

Rob - public review period must be 30 days

discussion of what public review means.

Jeff - can have concurrent last call and public review.

(c) Text for DSIG core change proposal 
Scott Cantor 

Proposed motion: vote to accept text 

Scott - Frederick comments mostly on original 1.0 text, most seem reasonable. Substantive comments need
to be discussed. 1) other signing techniques beyond XML Signature, e.g. S/MIME. Should it be removed?
2) Canonicalization escape cause, allowing profiles override rules, probably not necessary to make it
simpler - may make it harder. 

Eve - Explicitly say "Unless profile says otherwise..."

Eve - need to discuss ID attributes

Prateek - voted on inclusion of id attributes

Scott - not on wording

Eve - do not want to rely on fonts, merging is a good idea.

Irving - look at SAML dev

Prateek - asked on list

Irving - did not ask about assertion id change. (Using UUID not valid XML id)

ACTION Eve - pose question to SAML Dev regarding proposed assertion id change

Prateek - some more work to do, delay vote...

Frederick - should we discuss alternate signature techniques, make a decision? Issue is
context of signature that must be maintained...

ACTION - Scott and Frederick to revise signature note text.

(d) Text for change to versioning text in Core 
Scott Cantor 

Proposed motion: vote to accept text 

Scott - another revision incorporating suggestions from Eve. Ready to vote.  Highlights:
kept language about rules for evaluating version differences
defined specification set version 
- reflected in non-normative schema version attribute, (can distinguish schemas apart from namespace)
- asssertion and protocol versions in messages (major,minor versions), processing rules similar to

disconnect this version from the namespace version - continue to include version indicator in
URI for namespaces, include major,minor version of specification when namespace introduced

goals to maintain namespace stablitity and compatability.

As Eve mentioned, two versions: specification and namespace

Irving - Yet another way for things to break?

Scott - things could break before, now clearer when and how things can break. Changes to existing
namespace, schema document referencing same target namespace

Irving - need to be able to examine schema, issue of revising namespace in this case. 

Scott - major decision to change schema in incompatible manner

Irving - reasonable to expect v 1.1 request/response to return version 1.0 assertion in response? 
We discussed, no decision made.

Scott - no significant processing rules to make this possible, as long as namespaces don't change.

Irving - old assertion fit with new assertion

Scott - unless change to id attribute, breaking backward compatability.

Eve - importing assertion schema into protocol schema

Irving - question of whether to introduce constraint to have assertions and protocol be same version 
of spec

Scott - possibly long lived assertions

Irving - example, equifax report...

Irving - implementers have to figure out what to do, 

Scott - 1.1 code can process 1.0 assertion

Irving - longer term issue, e.g. major versions

Prateek - Is a change needed?

Scott - does saying "don't do that" violate use cases? Saying you can do it, doesn't mean you can.

Irving = either add normative text saying must match or processing rules if they don't, especially
how to send an error. version mismatch. Advice, evidence are cases where issue arises

Scott - this is additional language so we could vote on this and have a separate issue with

ACTION - Scott - post question on list regarding protocol/assertion issue

Scott =motion
Frederick - second

Motion passed.

ACTION - Eve - section on versioning needs update

Jeff - Thank you for nice work that required much thought.

3. Action Item Review: 
#0018: Describe degenerate RespondWith cases 
Rob Philpott 

Stays OPEN.

#0013: Request use of WS-Trust for CC proposal 
Maryann Hondo 

Rob - Reported that Maryann Hondo submitted email to authors asking to arrange concall, 
after RSA conference.

Still OPEN.

#0009: Propose text for PE-9 
Rob Philpott 

Text Sent to List: 


Eve: Either QName for element or QName for type, hence problem. New text may be backward incompatable.

Scott - will it schema validate without xsi:type
Eve - must be substitution group
Scott - should be possible to pass element name in message

Jeff - Liberty is not using it. v1.1 had RespondWith removed.

Eve - Deprecate in 1.1, remove in 2.0

replaced with three query types. 

Jeff - ask Phill Hallam-Baker if there are use cases that use RespondWith, if so, how. 

Rob Mail should go to SAML Dev as well

ACTION - Rob will send message to Phill and SAML Dev to ask if RespondWith used and if so how. Can it
be deprecated in 1.1 and removed in 2.0 would you care? 

Still OPEN.

also AuthorityKind issue.

Scott - just says how it is characterized, but no processing rules, can get back different statement

Rob - value of AuthorityKind MUST be of same type

ACTION - Scott to improve language around AuthorityKind

#0008: Provide text for PE-4 
Prateek Mishra 

OPEN, Will provide text this week.

#0004 Propose WSDL for Meta-data 
Prateek Mishra 


#0002 Attribute Authority Use-Case 
Rob Philpott 


#0020 Text for DSIG core change proposal 
Scott Cantor 


Published, CLOSED

#0021 Text to clarify use of base64 in FORM post profile 
Scott Cantor 


#022 Motion for inclusion of destination-site first flows in SAML 1.1 
Prateek Mishra 


Submitted text, CLOSED

#023 Editorial Review of Glossary and Bindings 
Eve Maler 


4. Other business

Eve: any other changes to errata document - none obvious

Rob: Sent mail to the list regarding patent license and process today.

Meeting Adjourned.

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