[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wss] Baltimore F2F "raw" minutes all text, with newlines
just fyi & convenience (I hacked this up for myself and am just sharing)... Baltimore F2F "raw" minutes all text, newlines inserted, and day2 Actions file (which isn't on the website) -- otherwise they are as-sent by SteveA. JeffH
Minutes for WSSTC F2F, Wednesday 3 December 2002
Dial in info: +1 865 524 4287 #248770.
Minutes taken by Steve Anderson
======================================================================
Summary
======================================================================
Votes:
[NONE - QUORUM NOT REACHED]
New (General) Action Items:
[none]
Issues List Action Items & Status Updates:
- 3
- Ron to write up token labeling proposal, with help from Tony,
BillC, FredH, Don
- 4
- change issue owner to PhillHB
- Chris to write up proposal
- move to pending
- 5
- change issue owner to PhillHB
- Chris to contact PhillHB (done during session)
- PhillHB agrees to link to 5
- move to pending
- 22
- new issue: Kelvin to have document searched for
inconsistencies
- Tony to update definition of claim to be originating from an
"entity", rather than a "client"
- move to close pending vote (CPV)
- 25
- had previously been marked postponed
- 26
- Ron to get with Tony
- 30
- Chris to get with Tony to document XPath-like notation
- move status to postponed to next milestone draft (after
interop draft)
- 31
- move status to postponed to next milestone draft (after
interop draft)
- 38
- move to closed
- 42
- move to closed
- 48
- Kelvin to send email to Zahid to review
- 50
- link to issue 4 & 5
- 51
- Tony to take example out in section 7.1, lines 664-669
- move to CPV
- 52
- Chris to provide more text explaining the preferred
key referencing mechanism in STR section, and send to list
- Profile document editors to define what key names & key
identifiers are with respect to their tokens
- 54
- move to CPV
- 55
- Chris to work with Tony to clarify line 222
- FrederickH to work with Chris/Tony to clarify dynamic XML
schema description
- 56
- Tony to add appendix, and get with Rob to ensure types
are documented
- move to pending
- 57
- closed, withdrawn by Rob
- Chris to provide clarification of use of direct references
vs. key identifiers
- 58
- close, pending Rob's verification
- 61
- FrederickH to get with Tony to integrate his text
======================================================================
Raw Notes
======================================================================
>
> Agenda:
>
> 1. Roll call
>
- Attendance attached to bottom of these minutes
- Quorum NOT achieved yet
>
> 2. Review minutes from previous meeting (12/03)
> < http://lists.oasis-open.org/archives/wss/200212/msg00037.html >
>
- deferred until quorum reached
-
>
> 3. Volunteers for minute takers
>
- Responders
- Steve
- MaryAnn
- Frederick
- Bill Cox
>
> 4. Actions/Issues list
>
- 3: Proposal to Label Tokens to Indicate Their Semantics
- been open for some time
- Tony: proposal on table now is to put label on a STR, rather
than the tokens themselves
- one token may be used for multiple purposes, so labeling it in
a wrapper provides flexibility
- Ron: agrees that use of token has to be labeled
- question of using an attr vs an element to carry the labeling
- also, question of putting multiple labels on a STR
- in the case of a signature, there can be properties, which can
carry labels
- these are usually used in a signature to refer to a key
- [extended discussion]
- mention of SenderVouches from SAML as a use case
- JerryS: describes use case of taking client cert from SSL channel
and pass it on
- but no signature with that cert is possible, because the
intermediary that is passing the cert on doesn't have the private
key
- Hal: solution is to create binary token representation of
that client cert, add it to the message, and add a STR to it
with a label describing it
- Ron: the labeling of the STR does solve a large portion of the
problems, but data references would solve a different set of
problems
- doesn't appear to be possible without breaking DSig
- John: so what do you want to do about trying to add label when
ds:KeyInfo is used (rather than STR)?
- can't label ds:KeyInfo because it's a closed schema
- Chris: ds:KeyInfo has an open content model, but closed attr
model
- so to extend it, an element must be used (rather than an
attr), in which case, you might as well use a STR
- Kelvin: are we getting to a proposal?
- Ron: if you have keyInfo, how do you add label? whatever
solution can be constructed for that will also solve adding a
label to a data reference
- Chris: since an element would have to be used, might as well use
STR
- Ron: doesn't think that use of STR is consistent
- John: looking for specific proposal
- discussion difficult in this setting
- Volunteers to work on a proposal: Ron, Tony, BillC, FredH,
Don
- [ACTION] Ron to write up token labeling proposal, with help
from Tony, BillC, FredH, Don
- Don: this is an important issue for implementors, to clarify
semantic use of tokens
- 4: Why is the token in the header, and not a child of KeyInfo?
- PhilG: wasn't the owner
- Ron: thinks it was PhillHB
- [UPDATE] PhillHB as issue owner
- Chris: background on this
- XMLDsig is fairly closed schema
- bigger driver was that outside of signature, you might want
to use a token
- therefore, need a generic wrapper
- Ron: how do you reconcile case where ds:keyInfo is adequate
- Tony:
- Chris: another goal was to improve interop, but providing a
simpler alternative to ds:keyInfo
- this issue (4) is gating to issue (5)
- Chris: proposes to move this to pending
- [ACTION] Chris to write up proposal
- [UPDATE] move to pending
- 5: Within the KeyInfo, why not use a ds:RetrievalMethod?
- [UPDATE] PhillHB as issue owner
- dependent on issue (5)
- [ACTION] Chris to contact PhillHB
- Hal: not certain that there is a dependency between (4) & (5)
- Hemma: originally, certain token formats were elevated, but
current approach of using token profiles may make this issue moot
- Ron: sees STR as a unification of keyName and retrievalMethod
- unclear whether all cases that keyName covered by STR, and
whether all cases that retrievalMethod covered by STR
- remains open
- 6: Will the authors of the roadmap submit it?
- related to 9
- Kelvin: no news to report
- still looking for a static URL to serve this up
- 9: Approach authors to submit the App Note to the TC
- related to 6
- no news
- 10: Investigate interop fest at some later time
- this is a placeholder for an interop event, which will be driven
by getting out spec to interop draft status
- 19: Core: Why is it necessary to special case a Username/Password
POP token?
- was pending, should be reflected in current doc
- editors have not yet added
- PhilG: aims for early next week, before next call
- 22: Core: Should the spec preclude security tokens whose purpose is
other than to convey or bind a key to an identity or entity?
- was pending
- Tony: proposal is to make this clarification
- if we accept this, Tony can make this change
- Ron: when he raised this question, intent was not to make this
change, was just pointing this out
- Ron: have made some changes to docs to fix this
- discussion of "keys" to mean more than crypto keys, and to
encompass attribute info (a la database keys)
- Hal: so we're not precluding tokens that convey other than
crypto keys, but we are precluding keys that convey other than
attribute info
- Ron: tokens are intended to represent claims, which can be lots
of things
- Ron: proposes we close this issue as to whether or not tokens
are to be used for other than keys, since they are to be used
for claims
- Kelvin: proposes editors search
- [ACTION] new issue: Kelvin to have document searched for
inconsistencies
- [UPDATE] close, pending vote
- Ron: suggests that the "should" part of this issue be dropped
- Hal: believes wording of claim being made by a client is
incorrect
- [ACTION] Tony to update definition of claim to be originating
from an "entity", rather than a "client"
- 25: Core: How can a Signature element occurring outside of the
header be referenced?
- Ron: was his issue
- we postponed this
- 26: Core: What does it mean to process a BinarySecurityToken?
- Ron: hasn't completed this action
- has circled many instances where this phrase is used in the spec
- [ACTION] Ron to get with Tony
- 28: SAML Binding: Include the use of the URI attribute (on
SecurityTokenReference) from the SS TC submission
- Ron: made this change 2 revs ago
- needs Prateek or Don (whoever originally raised the issue) to
review and approve
- Prateek: has not reviewed, will do shortly
- remains pending until Prateek reviews
- [REVISIT]
- 29: SAML Binding: Should there be a reference form that carries what
amounts to a SAML assertion Query such that the sender does not need
to have acquired the assertion (to be able to apply it to a request)?
- Prateek sent mail to list describing usefulness of this
- Kelvin: asks people to review while we're here
- [REVISIT]
- 30: How should XML be explained
- Chris: hasn't seen strong push to change from what we currently
have
- Hal: would at least like a description at the beginning of what
the notation is
- John: proposes, at least for this rev, to not make big change,
and in next draft, incorporate Hal's suggestion of documenting
the notation
- [UPDATE] move status to postponed to next milestone draft (after
interop draft)
- [ACTION] Chris to get with Tony to document notation
- 31: Should use OASIS Namespace
- use the XMLSOAP namespace for now, until OASIS comes to
resolution
- [UPDATE] move status to postponed to next milestone draft (after
interop draft)
- 36: In section 10.2.2, why not just specify that the <Created>
element type be xsd:dateTime?
- [REVISIT]
- 38: line 238: Since this is a normative text, how "inappropriate
claims" is defined here?
- [UPDATE] closed, by virtue of Konstantin's review
- 42: Line 1155: the meaning of "materially" is unclear
- [UPDATE] closed, by virtue of Konstantin's review
- 46: WSDL definitions - It seems to me that a stand-alone
specification should just define the semantics of its elements. If
an application wants those semantics, then the application WSDL
should specify the header as being required.
- John: proposes postponing this until after interop draft
- BillC: concerned that we're pushing too many items out past
interop draft
- not opposing it for this item
- [UPDATE] pending the QoP discussion
- [REVISIT]
- 47:
- [REVISIT]
- 48:
- [REVISIT]
- 49:
- [REVISIT]
- 50:
- Ron: believes defining use cases of STRs would help
- John: we already have an action to go do this
- Ron: suggests leaving this open until those use cases are
produced
- FredH: are the STRs intended to be abstract (meaning, can't be
instantiated, vs. concrete derivations of STRs)
- no
- Chris: should this be marked pending and linked to issue (4)?
- Ron: prefers to keep this open until use cases are available
- [UPDATE] link to issue 4 & 5
[JUMPING BACK]
- 4:
- assuming Chris does write up, this will be closed
- 5:
- Chris spoke with PhillHB, and he believes this is same as (4)
- assuming Chris does write up, this will be closed as well
- 51:
- Chris: we could just take the example out
- [ACTION] Tony to take example out in section 7.1, lines 664-669
- [UPDATE] move to closed (pending vote)
- [REVISIT]
- 52:
- Chris: key identifier is some unique identifier for a token,
which would be defined by the token profile
- example of a hash of a X509 cert
- least explicit reference of a key is key name
- most explicit reference is via direct reference
- key identifier falls somewhere in between
- direct reference is much faster than processing key identifier
- Ron: all for this, it just needs to be spelled out
- Section 7.6 even describes a different type of ambiguity that
can happen
- [ACTION] Chris to provide more text explaining the preferred
key referencing mechanism in STR section
- [ACTION] Chris to send proposed text to list
- [ACTION] Profile document editors to define what key names & key
identifiers are with respect to their tokens
- 53:
- Ron: thought that PhilG's action to move username token text
into its own profile doc obviated this issue
- still open
- 54:
- multiple items in this issue
- first 3 items were pending Don's review
- Don: will review today
- John: Don needs to go thru each item, and will open new issues
for whatever still needs to be addressed
- [UPDATE] move to closed (pending vote)
- 55:
- line 222 is point of contention around encryption
- [ACTION] Chris to work with Tony to clarify line 222
- next sub item: dynamic XML Schema description
- Chris explained intent of this in section 4.2
- FredH: last "may" on line 383 is still confusing
- John: suggests FredH and Chris/Tony work out improved wording
- [ACTION] FredH to work with Chris/Tony to clarify dynamic XML
schema description
- 56:
- John: thought that W3C was working on an ID attribute, to be
added in next ver of SOAP
- so our ID may get replaced in the future
- Hal: what is reason for having two schemas
- Chris: things in utility schema are expected to be used outside
this spec
- Hal: if another group wants to use the utility schema, they won't
want to go through our core doc to find descriptions (where they
are scattered)
- John: proposes putting documentation of utility items into an
appendix, rather than in scattered chapters, with a forward
reference at the beginning
- Tony: counterproposal to maintain readability by keeping the
documentation where it is, and to add an appendix describing
these general utilities, referencing their locations back in the
spec
- Rob: there are some types in the utility schema not documented
in spec, which should be added to appendix
- [ACTION] Tony to add appendix, and get with Rob to ensure types
are documented
- [UPDATE] move to pending
- 57:
- [UPDATE] closed, withdrawn by Rob
- new, related issue raised by Ron
- related to use of direct references vs key identifiers
- [ACTION] Chris to provide clarification of use of direct
references vs. key identifiers
- 58:
- Rob will get with Tony to verify changes are satisfactory
- [UPDATE] close, pending Rob's verification
- [REVISIT]
- 59:
- Guillermo will call Thomas to see if he has verified changes
- [REVISIT]
- 60:
- Guillermo will call Thomas to see if he has verified changes
- [REVISIT]
- 61:
- [ACTION] FredH to get with Tony to integrate his text
- [REVISIT]
[JUMPING BACK]
- 47:
- still pending
- 48:
- Tony: done in latest draft
- awaiting Zahid's review
- [ACTION] Kelvin to send email to Zahid to review
-----------------------------------------------------------------------
Attendance of Voting Members:
Don Adams TIBCO
Steve Anderson OpenNetwork
Paul Cotton Microsoft
William Cox BEA
Martijn de Boer SAP
Yassir Elley Sun Microsystems
Don Flinn Quadrasis
Peter Furniss Choreology
Eric Gravengaard Reactivity
Phil Griffin Griffin Consulting
Frederick Hirsch Nokia
Maryann Hondo IBM
Chris Kaler Microsoft
Yutaka Kudo Hitachi
Guillermo Lao ContentGuard
Kelvin Lawrence IBM
Hal Lockhart Entegrity Solutions
Monica Martin Drake Certivo, Inc.
Prateek Mishra Netegrity
Ronald Monzillo Sun Microsystems
Tim Moses Entrust
Anthony Nadalin IBM
Andrew Nash RSA Security
Toshihiro Nishimura Fujitsu
Mark Nobles LMI
Rob Philpott RSA Security
Hemma Prafullchandra Verisign
Rajesh Raman BEA Systems
Jerry Schwarz Oracle
Shawn Sharp Cyclone Commerce
John Shewchuk Microsoft
Frank Siebenlist Argonne National Lab
Gene Thurston AmberPoint
John Weiland Navy
Attendance of Observers or Prospective Members:
Lloyd Burch Novell
Eric Cohen PwC
Membership Status Changes:
Joel Munter Intel - Withdrew 12/4/2002
Jeremy Epstein webMethods - Withdrew 12/8/2002
Hank Simon Lockheed Martin - Withdrew 12/9/2002
Takashi Kojo NEC - Withdrew 12/9/2002
Greg Carpenter Nokia - Withdrew 12/10/2002
Simon Godik Overxeer - Withdrew 12/11/2002
47 [still PENDING]
48 [ACTION Kelvin ….needs to be reviewed by Zahid before being closed]
- schema was brought in line with document
49 [ACTION Kelvin ….needs to be reviewed by Zahid before being closed]
- schema was brought in line with document
58- [PENDING]
- Rob Philpot to review and let us know if they can be closed
- Section related in 56 &57
Ron Monzilla
When you use which reference when?
Id References only have a role when the token is not present in the message
Really need to define how the references are used.
Chris….
Lets say SAML chose to make a token a type id
The only way to do this would be to know the schema
The purpose of id is to hardcode in the reference so you don’t
need to process all
The schema
Key identifier points to an opaque value
Key identifier has an encoding type
Ron,
Really unclear
KL
[action already taken….. tony and chris to write up the
security token model]
58- [PENDING] Rob will verify against current edits
59,60 –[PENDING] Thomas not here, Guillermo to call Thomas and verifiy that
changes made are acceptable
61 [PENDING] Frederick and tony to resolve the text and make proposal….
[ACTION-John]
Request to start a new issues list
Frederick and Phil Griffin will send new issues to list and these will be
reflected post interop draft
[ACTION- Tim]
Review editorial explanations Tony has done
Proposal to break for 20 minutes:
John and Steve to sync up and update the issues list
People who had actions to review ….should take the time to do
that
People who had actions to start discussions on new topics could
do that now
Resume after lunch
Redoing the issues list
CPV pending a vote
3- [ACTION to work on at F2F] Label of Tokens, Ron & Chris
4-5 CPV
6 Postponed to POST Interop draft
9 Postponed to POST Interop draft
19 Phil draft ---available after F2F
22 CPV
25 Postponed for this draft
26 [F2F ACTION] Ron and Tony
28 CLOSED …..changed to [F2F ACTION for Prateek, Rob, Don and Hal ]
after discussion of SAML binding
29 CLOSED [prateek suggests closing (withdrawn) and opening a separate]
30 Postponed till POST interop draft
31 Postponed till POST interop draft
36 [ F2F ACTION for GROUP] change has been made GROUP to review 10.2.2
46 [F2F …post QOP discussion]
47 still open [F2F]
48 [ACTION Kelvin] schema updated
50 remain open
51 CPV
52 [ACTION Chris F2F]
53 remain open
54 [CLOSED….Ron to review and open new issues if there is anything else]
55 [ACTION F2F Frederick to work with Tony and Chris]
56 [ACTION f2f] Tony
57 [CLOSED]
58 [CLOSED]
59 Guillermo left a message for Thomas
60 remain open ….need Thomas input
61 [ACTION f2f] Frederick to work with Tony
62 [ACTION f2f] Tim ….to review with Tony
Next agenda item:
Review bindings
SAML -04 review of Ron’s updates
This document shows all the changes
Changed some statements about IPR… pointer to the TC web page and the OASIS
guidelines
Philip provided an initial merging…..so some changes to intro…
editorial change
3.1 Talks about semantic labeling….
how a relying party knows what to pay attention to …has to make some
determination about signatures and processing .This was one of the sections
in which changes were requested
3.2. this is one of the areas that brought up questions about references
3.3 Hal and Zahid need to review and comment on this
3.3.1 Don Flinn wanted to know if this is the way saml assertions
will
3.3.2 Be included or whether or not they would be within another
container element within the wsse: security element
There are three ways to handle assertions.
Within SAML the responder URL is not sufficient to get the
element which is being referenced
Jerry,
even though saml is closed you could add an id by wrapping the element
Question on whether there is something missing from SAML?
Prateek,
not an easy way to do this, part of the metadata for the query not part of
the assertion itself We don’t have a good element/data reference for SAML
(retrieval)
Need a Reference form for saml for uniqueness and how to
retrieve them….
The SAML identifier is a unique assertion….globally unique over time and
space Identifies the contents…there seem to be different references when
the assertion is in the header use and when you need to be able to retieve
it
Why doesn’t a security token reference carry a key identifier?
[part of the ongoing discussion of labeling]
Chris Kaler
For saml define that the key identifier is the
assertion id
Advocate this model because its les ambiguous.
Ron
3.3.2 This shows how to reference within the header using a uri as a
fragment identifier
The binding is broken
Lots of discussion about url fragments, whether or not saml assetions can
Be reflected by a fragment identifier….
Key thing is that this is a URI not a URL …
Want to go back to the wrapper model….
There is some xml assertion and I want to create a reference to it.
We have assertions ids on saml assertions
But don’ t have a way to represent an access to the assertion in the
document
Ron I tried to do that …….
Tony suggested an XPATH or an XPOINTER
Does it give us an opportunity to get to the
resource?
This is the remote case….
First there is an authority at a URI…..
Do a wrapper and get a pointer to the
authority….
Security Token Referenc is that
wrapper….
Jerry
You need an element that specifies all the information to get the saml
assertion
Ron,
If I do that for saml I will need to do that for
every security token type.
Rob Philpot,
In order to handle the SAML case, might want to look at the saml authority
binding
Proposal to take this discussion offline and have the SAML people caucus
and come up with a solution.
In most cases a key identifier is used to look up the
referenece….
Chris,
There are two cases:
Potentially abstract URI
And a local identifier
Normatively it’s a URI
Jerry,
Want to implement STR ….there is no indication that it is a saml reference
to know whether its document based or retrievel type to have to go to the
SAML document to understand how to process the reference, it seems like the
wrong model
Chris
Processing model is there and extensible
Jerry, if its not handled at the base level,
Proposal
Should there be in the STR a way to retrieve a token or is that
a token specific mechanism?
In general a URI is self describing…
Do we need to identify if it’s a document based reference model and another
protocol reference model?
--------------------------------------------------------------
Proof of Posession
Confirmation mechanism was removed
Assertions indicate whether you must confirm or not
Comments requested but none received.
In looking at this you could confirm this by other means….
Tim,
Are you disqualifying the bearer approach?
Ron,
Sender vouches can be because I recognize them
Or it is a bearer case
Tim,
Message and an assertion within assertion is an identity and the whole
thing must be signed and the receipient can infer the identiy is associated
with the message because it is signed.
Prateek,
We are now trying to figure out how to attach saml assertions to SOAP
flows,
First case sender is the subject
Second case is the sender vouches.
BREAK
Ron
Have not allowed for a bearer case
Within the assertion, the authority says how you must confirm it there are
two methods documented here (saml has others) ….
The holder of key is different because the authority is indicating who
should be allowed to make the assertions
The document is prescriptive, maybe we need to loosen the
language
There is nothing in the saml core that says whether or not you
need to sign.
Hal
Bearer was a kludge, let’s not perpetuate it.
Prateek
Agree
Hal
Assume in this environment people will do something better
Prateek,
Could we investigate weakening the language …might end up
causing problems.
Ron,
The choices we’ve given you mean you always need to have assertions signed
and is this a problem for SAML….should we support a case for sender
vouches?
Issue to have people validate that this doesn’t validate the
core.
Go back to Holder of Key….. one of the things enabled by SOAP and SAML with
signatures…..
Where is it that says that you must sign the assertions? the core when
describing sending saml messages through an intermediary does say that
…browser profile does have a requirement but that is not part of the core
Don Flinn asked how does this relate to the canonicalization rqts of the
core?
Receiver [Section 3.4.1.2]
Knows which assertions it needs to process …make it clear you
should validate
Assertions….nobody can make you do that….should this be a MUST?
[Line 305 ]
proposal
“ Message receiver must validate signatures on the assertions and must not
accept them if they fail validation”
Hal
Do you want to say that all conformant applications do this?
Make it a MUST….
You can disable the feature or implement another profile.
This example was intended to show holder of key…..
Line 395 remove extra quotes.
Chris
Volunteers to make sure that the schema examples in the
documents will be validated….all major drafts will have this done….
Gene [example 3.4.2.3]
Core Document says As you add security tokens, you should
prepend …this does not follow the processing rules….Should signature be
prepended?
Ron
Where you have signature block ….there is a signature in the saml assertion
and is it a signature over both the assertion and the body?
Prateek
Then you are subject with a substitution attack.
Ron
There is a case where if your’re self authorizing….
in holder of key you are not self authorizing….
Ron
[ACTION]Change to the example, in the signed info include a reference to
the message body
[ACTION] In security considerations for an unsigned security token…..Tony
might need to add some text for this risk.
Tim,
Do we have a single mechanism in the core to identify different
tokens?…..it is implied that there is only one saml bindings/profile
Profile is used to process a token type…..
You can have one token which can be used in 3 profiles,
You need to identify the profiles for versioning
You may not need to support more than one profile
[ISSUE] There are versioning issues for all of WS-Security
[ISSUE] is there something in labeling which will help with the
versioning? There are lots of critters here…..are we versioning profiles or
tokens?
Can a profile itself indicate what it supports?
Is this a policy issue?
[ACTION] open an issue we need someone to put together the text….Ron will
volunteer to do this but not before the end of the meeting…..
3.4.2
line 435 change to MUST
line 513 should not have the quotes
lines 519, reference to body. Needs to be added to previous example
bind the token and the binding together,
3 potential options
SAML allow an id ( maybe for 1.1 )
2 options for now that make sense for all tokens that don’t have an id in
them
XPATH
Custom transform on the envelope
Proposal to wrap all tokens with an id ….
Make the reference a literal reference
Or define an XML token
[ACTION someone needs to write this up….Tony will draft for this F2F]
Error codes
Line 566 should be generalized
Jerry,
What if there’s more than one token and more than one error….
Fail when you hit the first error is the current processing
model
What error messages appear in the details in the soap fault?
Ron,
Are there security vulnerabilities in returning too much information? Then
you could also have internationalization issues if this is text
Rob,
If you want that level of detail….you can create audit logs to keep that
information on the server but you don’t send that information to the
client.
[ACTION for chris & Tony]
1) put text in the fault when you issue a fault you may include a security
token reference
2) in security considerations do it carefully
3.6 Threat Model & Considerations
Eavesdropping
Is the idea that you could have multiple audiences?
Yes and XML encryption allows you to take a symmetric key and distribute it
to the recipients through an asysmetric method
[ACTION for Ron, 621 sender signature, it should refer to this as
integrity protection]
we might want to chose a different emphasis mechanism
[Rod……626-628, made consistent with ACTION above]
Phil
Put out an input document to allow XCBF to be used in ws security
Defined an XML markup of two binary formats
1) bit map
2) biometric service provider
x9.84 CMS pkcs 7 standards
ASN 1 schema
NIST has defined a framework for what biometric formats need to be
These two fall under the framework
Define a type which tells you whether it will be binary x64 armored
Or an XML markup that is not tied to W3C schema but tied to the XCBF schema
Describe how to translate between the XML and binary formats
Propose to use this for authentication and distribution of biometric
information
Also add an optional biometric format to the id/password to supplement or
replace the password in a multi factor authentication
Request to support another binding document and phil has already
volunteered to participate in the previous username profile document
Phil has investigated and said there is no known IPR for the XCBF proposal
What occurs in the header?
It’s not used as a sole mechanism for authentication, but a second factor
in an authentication
Ron,
This is similar to a claim but what is the proof of possession?
Proposal to adopt this as another binding…. Will be tomorrow…..
Monica will repost
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- -----
Start time of these minutes: 11:30 AM Thursday December 12, 2002 meeting already in progress. Issue 47: Examples (Zahid Ahmed was not present) State PENDING Issue 52: Security token references. State PENDING Tony: two updates in Appendix B and in Security Token Reference where we outlined what will be in the non-normative summary of SecurityTokenReference in App B. Chris sent a sep doc that is now app B on how to process STRs. (lines around 694 in diffmarked) Ron wanted a description of the processing model. Ron - Chris pointed to the processing model. Ron - looked like alternative choices for references, wanted that. Chris - mark PENDING so Ron can review before Tuesday. ACTION on Ron Review issue 52 before next meeting. Kelvin - anyone here who can't be on the call on Tuesday? Brief discussion about quorum, still short 2. Issue 55: Line 395ff. Leave PENDING as Frederick is out of the room. Issue 56: Issue was consolidating to an appendix the wsu information, per Wednesday minutes. Robert Philpott - faults aren't in the appendix. receive type. Chris -- faults. PENDING, Tony will get edit in. A.3 covers type definition. Someone asked about Delay. ACTION on TC review response to Issue 56 for further edit. Issue 59: Guillermo: Need more time; Phillip sent new version to Chris. PENDING. Issue 60: Guillermo -- leave OPEN - need more time. Issue 61: Frederick has worked on clarification, Ron - need to talk with Frederick. Lines 808ff. Jerry - element that we don't have; should be SecurityTokenReference? ACTION on Tony to fix typos, Ron and Frederick re-review. Continues PENDING. Jerry Schwarz - XML security token wrapper - we agreed to do it, Tony had agreed to do it/take proposal. Tony would work with Jerry. Follow-on discussion of Issue 61, leading to a... NEW ISSUE on this, ACTION on editors, Jerry. Ron - several issues, including labeling? Chris - signing of SAML Token. We should think about whether we need it. No scenario in XRML doc that needs it. Jerry - There were other reasons, will reconstruct. NEW ISSUE Grammar to express elements - l167 - ACTION on TC to Review. Status PENDING. Clarification that fragments are illustrative (Tim Moses). Only normative is referenced XSD. NEW ISSUE Security considerations added by Tony: what should be signed (Ron - it wasnt covered in current doc). See line 1500. Ron to review. Took text from SAML binding, uses assertion - Tony will correct before issue of next draft. NEXT ITEM ON AGENDA: "Interop Draft" Kelvin - Issue has been open for a while. People want to do an interop event. There was mail to the list 2 months ago on interop draft. Kelvin would like to do this in first 3 months of next year. We will need more than one such event. Will propose a strict set of scenarios to interoperate on. Discussion on the term "interoperability draft." Chris - We need to create a script, and select a version of the spec that will be the [first] one to freeze for coding. When we talk about an interoperability draft that's what we mean. Kelvin - next F2F should be focused on interop and test of spec. (viz. addendum where a lot of things got fixed) - sanity check point, get a jump start as we come out of this process to become a formal spec. Martijn: generally a good idea, when we specify scenarios define a set of test vectors, which elements to protect, so people can test them. Robert P. - We should write a detailed interop scenario or scenarios. Lloyd Burch - This would need to be an open meeting, NOT a press event. Kelvin - Minutes would be taken. Purpose is to generate feedback on the spec. I will not call pcweek, etc. This is not an embarrassment deal - it's to determine where there are issues and holes in the spec. It will give us a chance to focus on the spec really well. Lloyd - We would not taking notes on pass/fail? Kelvin - the TC will have to establish rules. We will record actions for the editors to fix things that made interoperable implementations easier [meant "harder"] to implement. Tony - will we get feedback from the use case group in the afternoon session? Kelvin - is there anyone on the group? Eric was the driver, not here. Several people - nothing has happened on that list. Don Flinn - Don't stand on formality, post to the list! Kelvin - We'll have to come up with scripts for the event as a TC. Jerry - There's the suggestion of some special status to this draft we're about to issue at the end of this meeting. But the important doc is this scenario document, defining the bits that have to be done. Why the special status? Bill - from interop work, the scenario is what's important, in effect profiling the base spec. Kelvin - We need to do it this way because OASIS doesn't have a "candidate recommendation" designation. We want something frozen. Robert P - The key doc is the scenario doc, it can say use version core-xx. Jerry - Yes, can say in the scenario what draft is used. Kelvin - We want to say that this is the version to work against. Maryann - This draft should be a checkpoint, something concrete. Robert - say which. Doc editing - interoperability draft is designated. Jerry - what can I leave out? Chris - The scenario doc doesn't reiterate the spec. Kelvin - There's no special secret meaning. Robert P - Some didn't know, based on the agenda. Kelvin - that's what mail said. Ron - I agree that the script alluded to with use cases needs to be produced before we can lock down a draft. The drafts we have haven't been validated against (say) using X.509 certificates. Paul C - "No one" is a bold statement. Robert - not all use cases. Ron - need to validate before locking down scenarios. Gene Thurston - agrees. Kelvin - We can't wait for the use case group. Ron - There's a problem with the way that the use case group was kicked off, without participation of the chairs. The TC agreed back at the first meeting that there wouldn't be a use case document, so they've had nothing specific to do. Chris - We expected non-normative use cases, not for formal spec, use cases that we could possibly donate to WS-I. Ron - There was no sense that we needed use cases. Robert - [The chairs?] asserted at 1st F2F that there was no need for use cases. Ron - if the TC agrees that there's an important need for use cases, shouldn't saw the use case group off at the knees. Chris - general use cases [were discussed?], but also a specific proposal for the interoperability. Kelvin - want to kick off. Chris - I will take ACTION to put together a draft straw man of a potential interop script, mail to the general TC list. Date: in 2 weeks. ACTION Kelvin - will ping Eric on use cases. Ron - Now define and give them some weight. We want to show them interop over important use cases. Paul C - Remember that "them" is us. We should disband the interop subgroup and do it as committee of the whole. Chris - [We need a ] precise course through the core spec, where if you don't do it you're dead. Ron - that's a use case. Paul C - may need other use cases. Chris - This will revitalize the people who want to do use cases. Kelvin - At a future meeting we should set date for [the first] interoperability event. I'd like to take a Straw poll on who is interested in coming to such a meeting? And for what purpose? [roughly 2/3 of group present raised their hands.] Comments from group on why people would come - to watch, to attempt to interoperate. Chris - what kind of network infrastructure do we need to plan on? Should combine with a F2F: Spend the morning getting the code to work, the afternoon discussing. Robert - The SAML dry runs were similar. There were two, one on each coast. Focus was on the script and figuring out how to make it work. It was just a meeting, and it worked well (the marketing people not informed). Chris - interrupting - don't want to do that. Robert - (continuing) More of a working meeting. Chris - So let's have a TC meeting with a "code focus," perhaps in February. Discussion - Late March better. Won't have scenario/script until mid January. Paul C - We should have two days of interop and then have the f2f meeting. Tony - is there a motion on the floor to have this? [Some comment on "websphere interoperability"] Chris - Some companies have huge issues about unreleased code on the internet. QUORUM AND PROCEDURAL DISCUSSIONS Kelvin - We might have quorum, long discussion on what "attendance" means. Asked who would object to counting attendees that were not in the room as attending for quorum purposes. Objection from Bill regarding quorum calculation. Discussion on attendance for retaining membership, attendance for quorum. Counting of members who had attended at any time during the two day meeting was proposed, which would have reached quorum. Chairs declined to rule that LUNCH Afternoon: 1pm restart. Planned revised agenda: Naming committee - 5 minutes Liaison activity - 5 minutes QoP Discussion list - 25 minutes Adjourn Naming Committee Rob Philpot - naming summary. Based on responses, not checking whether only voting members voted: main choices on core were "Core" or "SOAP Message Security" or "...Protection". 17/25 votes Profile docs - move to "Profile documents" not "Binding Documents." Chris - on Tuesday call, take a vote and put to rest. ACTION on chairs - add vote to affirm straw poll selected names to agenda for Tuesday call. Discussion on whether this was a vote. Email call for vote claimed, but some said we haven't ever done that. Rob - summary of the leading choice: secondary docs: "web services security: tokenType Token Profile" primary doc: "web services security: SOAP Message Security." Liaison: Input from discussions in other groups. No requirement for big discussion. Tim Moses - XCML familiarity? around half of those present raised a hand. Auth and access control in mind - policy. Submitting as OASIS standard in the near future. Should be considered a jumping off point. Quite a satisfying activity - broad range of participants. Hal is co-chair of that group. At the 11th hour there was a disruptive declaration by ContentGuard that they had IP that applied; In Tim's opinion this was mischievous, with unknown motives. WS-I LIAISON Jerry Schwarz - WS-I has created working group on security with the expectation that future profiles will have some security use cases. The first meeting (teleconference) is next Tuesday. Kelvin - I've talked with Eve Mahler (??), the Chair - several people on this TC are on that meeting, so next Tuesday WSS will start on time and finish in 90 minutes (half hour early). We've agreed (?) that the WS-I meeting will not stay in that timeslot. SAML LIAISON Prateek - SAML liaison. SAML has completed 1.0 standard. Co-winner of PCWorld Award. Now entering into the 1.1 process, which we expect to terminate first half 2003. Rob is also co-chair with Prateek (?). Focus is on collecting input from implementation, of which there is a fair bit, and errata updates. SAML metadata and browser profiles, extensions for [something]. SAML 1.1 won't complete in time for WSS 1.0. Prateek is SAML schema-izing your information? yes, in 1.1. GRID LIAISON (OGSA, Global Grid Forum) Frank Siebenlist - OGSA [open grid services architecture, which has web services and other fluff around it) and Global Grid Forum (meets 3 times per year). Introduced WSS in the OGSA security architecture. They have a prelude release that implemented WSS (?!) 6 months ago. One of these GRID groups has also created and licensed a development toolkit, using a BSD style license. Many of the vendors here have ported to their own platforms. There have been early questions on the licensing model; no answers to date, but promises and suggestions that we shouldn't worry about it. Hope that it will resolve appropriately. I have a few questions that I was asked by the [two GRID groups] with my proposed answers... (1) what kind of licensing will apply to the OGSA security toolkit? - I don't know. (2) When will you know? I don't know. (3) How can we standardize without knowing the licensing? - I can't vote for the standard. (4) Are there more members that have issues on this lack? - maybe a few. (5) Could there be a substantial number that won't ratify with a bad IPR statement? - may well be. (6) Isn't this a bad situation to be in? - I couldn't agree more. (7) Are there any reasons this is not addressed? - submitters don't have their act together... (8) Are there some Machiavellian things going on? - I vouch for the integrity of the submitting companies, they wouldn't be capable of doing anything like that. (9) Isn't it hard to expect us to participate and contribute without knowing answers to these questions? - same answer, vouch for the integrity... (10) Are we heading for a confrontation? - possibly, and that is bad. (11) Did you manage to bring this to the attention of everyone? - I'm trying. Lots of colleagues and coworkers are following the mailing list. My request to put this on the agenda was refused - not even acknowledged. (12) Isn't that rude? - It was a mix-up, I vouch for the impartiality of the chairs. The TC should be very careful to ack others requests for agenda status, not very polite. Tony: Verisign put out an open source version of WSS; why can't you do the same to do that? Frank - go back to your own company and ask about our request. Tony - has been done. But IBM, MS, and Verisign worked together on the original spec. Prateek - is there a URL where you can find out how to license this? (no direct answer) Frank - You guys are working for the submitters of this spec, and you don't have this together. Chris - Kelvin offered to get the lawyers together (comments from the house - "and then do what?") Kelvin - You're concerned about the TC, or the IPR statement that isn't part of the TC? Frank - I don't know the licensing conditions. I never had any info except for IPR statement. Chris - are you asking how to get the Terms & Conditions? Go to our URL for the original spec, it will point you to the T&Cs for the April spec. Robert - The Intellectual Property is relevant to each member of this TC. Kelvin - no one has submitted any further declarations. The way I read your mail, I thought you had specific questions about the terms and conditions. Your company's lawyers should talk to ours. Robert - There's a letter of intent to the TC to contact RSA to receive licensing terms. long discussion, re: timing of disclosures. Hal - disclosure "at the earliest possible time." but no enforcement is in OASIS IPR statement. Frank - more Chris - ACTION on IBM, Microsoft, and Verisign: we will try to get what we can on licensing on the WSS TC web site. Chris - From my perspective, I've only known about this issue for 3 weeks, and this request is beyond what's required. If you did the due diligence to go to the MS web site you would have seen. ACTION on group requested by Robert for all TC members to disclose IPR issues. Ron [could have been Robert]- this may come up in many contexts. Someone wants to profile WSS; are there unencumbered profiles of WSS without having licensed the core licenses? IP others submit, e.g. the SAML SOAP binding might implicitly be subjected to this license! What are the linkages of these profiles to the licenses? Hal - could be two versions of a profile, one of which infringes on another. Chris - I can't answer that [Ron's question]; legal issues are beyond the scope of the TC. General comments suggesting that that is the case. WSRP LIAISON Bill - WSRP has issues with respect to roles; communication has started happening, I believe. W3C LIAISON Hal - Liaison from W3C Web Services Architecture. There was a note on 11/11 on WSAWG asking this group to provide WSDL references in the initial issue. (from Dave Orchard) Chris - have an action on this, but it's not clear whether this is appropriate - we're discussing it, but don't understand what is expected of us because it is not representable in its current form. Not clear whether this was from Dave O or from the TAG or from the WSAG? Hal - from the WSAG. QoP READOUT - DON'T HAVE SLIDES Tim Moses - QoP readout. SLIDES AVAILABLE? At the WSS F2F #1 - a need was identified. Objections raised were schedule impact, absence of interested parties. Solution taken - create a discussion group, liaison statement. On schedule impact: Chris - The schedule impact comment is a false claim; this is a hypothesis that majority of TC hasn't followed or discussed, hence no impact. Interested parties should have gone through OASIS procedures; experts should know that the activity is taking place. Only one additional person took part. Tony - what is the scope of a discussion group? Tim - determined by its charter. Tony - open environment, no rules associated with it? Tim - follows OASIS group procedures. Tim - There were people present that found this an important, and possibly urgent, activity. The group is reporting back to the TC on its work. Summarized (from slides): WSS describes how to apply a chosen security policy to a SOAP message. This leaves open: How can the parties exchange their security policies? [SEE SLIDES] Security Policy and QoP document have a normative flavor, but are not intended to conform to full OASIS requirements. Issues: Confidentiality, integrity, origin authentication. Which Parts to protect. Authorization. Privacy. Full report is 25 pages; see (http://lists.oasis-open.org/archives/wss/200211/msg00179.html and link therein to http://www.entrust.com/resources/pdf/wssqopv09.pdf .) How does the consumer find about providers policies, and the provider find out about consumers capabilities? SOAP for the consumer, WSDL for the provider. (???) Tony - any reason the consumer is not also WSDL? Tim - responder may not define the schema for its response via WSDL, it may not have any WSDL. Tony - can policies be combined? Tim - if any intermediaries have policies, the document addresses combining them. John S - could you use the SOAP-based mechanism for that? John S - do you envision this applying to broader policy, e.g. transactions or policy ports? Tim - addressed general-purpose policy language (e.g. for authorization privacy); possible to extend as you described. We focused on security policies. John S - customer requirements - if doing reliable message exchange you would do one kind of security, if not, do something else. if in completely separate domains, couldn't say anything about the cross product. Ron - Need to express security policy associated with a context. So you could define a union context. John - I don't know what you mean by context. If I had a policy (trans, reliable messages) so have a security, transaction, and reliable message contexts? Are these separate from security contexts? Ron - generalize and re-factor at one level. May want to re-factor transaction policies in the same way. John S - context vs policy? I think I'd have policy as distinct from context. Ron - This is in effect a tree that could exist in multiple contexts. John - should be able to define a policy that can apply to different contexts. E.g. transacted ops on Amazon are secure, non-transacted are not. Higher-level framework in which to describe that and those policy descriptions. I see context as separate from policy. Ron - context is the thing that allows you to express all policies (of the client?) Describe the aspects of a security policy that you want to deploy. Could be your active event, express all of its properties. One large area is its security policy. Could be more than one security policy in a context. Martijn - describe security attributes by getting some data, get list of books, and buy one of them. Not interested in security for all of this. John S - important point. Many things out there need policies (choice of algorithms, etc) Prateek - specs, even in life there are many policies. John S - take this and express a general policy language. Prateek - I'd be excited as a professional, but what does it have to do with OASIS? Tim - how do we explain which security mechanisms need to be applied between the parties? More broadly, this is an issue of policy and its expression. But what do we do with this particular proposal? John S - I'd like to see the industry come up with a general policy framework, and have ;the security policy be a specific set of nouns and verbs within. I'd hate a one off that would be replaced by that broader mechanism. Jerry - People implementing web services and intending to use this standard want a mechanism to exchange the required information for things that are out of band. If we don't do it here, they'll have to do case-by-case in a non-standard way. The question is whether someone provides an interoperable standard way of doing it. Tim - wrap this phase of the discussion, turn to what we do about this topic. Ron - Let's say that [my understanding of John's point] is that there should be a way of expressing a unification framework for policies. My question is "would you expect that to be built from common building blocks that are being reused? are you forcing this from the bottom up? would you end up with the same elements? John - I want the group to think about the broader context, and that this isn't the end of the line. Determine that the mechanisms we define here have applicability beyond security. Martijn - Say in mid 2003 WSS is standardized. Then we're told we can produce toolkits for adding things, but no WS client can really make use of WSS because it's a manual process defining what to sign, and error messages. End up with WSS... John S - We must solve this problem. Martijn - delays a general framework until 2004 probably. We need way to express security policies pretty fast. Tim - The Liaison Statement on mailing list [see earlier links] contains link to work we've done. Referencing sec policy from SOAP and WSDL. Tim will propose a Motion - That the WSS TC resolves to form a subcommittee and instructs its members to advance the work of the QoP discussion group to OASIS Standard by Summer 2003. John S - We've said from first meeting of the TC that there's a need for a general policy framework - there are people at MS and other companies that have expertise, and we could bring them together. Frank - I stress that for the OSGA framework, we are using the WSS elements already for 6 months. We have a version of WS Trust, WS Policy, whatever these boxes[in Tim's slides] are. Not giving any dates is very frustrating when we want to move on. Tony - This brings up issues of OSGA also creating a general policy framework, inventing the same thing. John S - Wouldn't it be great if we had a group put together to do something about policy in the broader sense. Robert P - More general sooner? get some consensus around this description to get some interop going. When you go to a service, accept it or not. Monica - some people who would be actively interested. Already discussions on this in WSRP and WSIA. John S - Think of policy broadly. A while back, when we originally talked of WSS, we said that we should have a roadmap of specs and a general policy language. I've heard from a lot of partners and customers. I'd hate to see people investing in a point solution when I know there are people out there thinking about the broader solution. We should devote our energies to solving the broader solution, then the specific. Jerry - If we had a motion, then you'd be opposed? John S - I'd make a friendly amendment to determine interest in a broader solution before doing a point solution. Frank - could we do this so minimal profiles can be defined to do this in the near future? John S - that would be great. Ron - This is a semantic model transformed into XML? Tim has captured a concrete representation of a semantic model. When someone comes up with a grand unification model, could reuse. Tony - Don't want to formalize the 10-20 ways that service could be formalized. John is advocating a more general framework. Then some group could do this. Ron - There is a semantic model for policy that could be formalized and prepared for entry into WSDL. What you're suggesting allows for both things to go on at the same time. Grand semantic model, and at the same time have the specific profiles that we need. Martijn - Define what are the tokens we need to describe (types, parameters), and way to exchange these policies. Probably not inside this group - dedicate to some other group. Also, look at language for describing the semantics. Add semantics to the tokens. John S - Exactly what I'm looking for. People inside and outside this room could bring expertise. Chris - could bring in relevant MS people from various policies. To have the right intellectual horsepower on it, we might create an unbalanced and unpleasant experience. Frank - we need it for this WSS stuff, need negotiation. Chris - we've achieved a refinement of work. Published XML Signature; doing a good job on WSS. There are more steps that are needed. Frank - if you throw this off the wall, everyone will invent their own. Chris - but there will be a standards group that will address this. This is a point on a continuum. Tim - Summary: some are naturally bottom-up, some top-down, and that will be illustrated when this is voted. Don Flinn - Grand unification can take multiple years. We want baby solutions along the way. This is more than a process question. Ron - Who's going to work on this problem? We're here to work on WSS so it's something we all could use. Tim got people that are interested in policy together. Tony - I agree we're trying to solve security problem. But even if I want to negotiate, what language and what level of expression to negotiate in? Ron - Your reps could come to this forum and steer it. John S - Your point is we have a bunch of "security people" but others have transaction, reliable messaging experts, and other kinds of experts, metadata experts. They would like to participate in this, but don't have experience with what we have in security. Let's talk about a detailed timeline? Martijn - I want a sub-TC to express security policy with a link back to this TC. Jerry - If this other group that you're hypothesizing actually existed, we'd probably want to form a liaison (or subcommittee) to work with this other group you're hypothesizing. Form this subgroup as liaison to the grand unification committee when that committee actually exists. John S - Scope the subcommittee to define the whole thing, or the pieces of policy that are relevant to security in the broader environment. Martijn - define our expectations with respect to policy exchange infrastructure, and (if we have these features available) what they are and how they would work. Kelvin - There will be a charter issue whatever way we want to go. Bear in mind how we want to go. Depending on how much additional work is proposed, this will get into a charter discussion. ACTION on TC to consider impact of policy/QoP work. Tim - There was not a great deal of support for WSDL liaison - editors didn't respond. Discussion group ends this coming Sunday. Frank - Should we extend this discussion group and its time period? Kelvin - We need a concrete action at the end of this discussion list's life. Peter Furniss - Assume it fits in with whatever John's group does. Short term, need something about what level of WSS things are required by this TC. Need at least a requirements document. This is not a permanent building with full architecture - an interim policy description, not committed to OASIS spec. John S - Sounds very rational. Tony - Was there a requirements doc? Tim - One doc. No use cases. Jerry - Concrete task for this possible subcommittee - Chris will come up with a scenario/script with a lot of the info/docs we expect to exchange [for interoperability work]. That could be a useful input. Chris - people go off and come back with a requirements document. ACTION ON CHAIRS? - Create a subgroup to come up with requirements. Monica - There's an issue about the identity and propagation of roles brought up in the Security Joint Committee; there's a recommendation coming to take definitions from existing sources, compile them, and provide as input doc to the TAB. (Board had feedback - don't do deliverables, don't do recommendations.) This will be input to the TAB as to how they recommend the formation of a TC to talk about the terms, relevance across the affected communities. No decision or advisement in the SJC. Meeting closed at approximately 2:45pm. ACTION ON TC - Phone next Tuesday, December 17. Members who attended this F2F should make every effort to attend.
ACTION on Ron Review issue 52 before next meeting. Mark issue 52 PENDING REVIEW. ACTION on TC review response to Issue 56 for further edit. Issue 59: Guillermo: Need more time; Phillip sent new version to Chris. PENDING. Issue 60: Guillermo -- leave OPEN - need more time. ACTION on Tony to fix typos in Issue 61, Ron and Frederick re-review before next meeting. Issue 61 continues PENDING. NEW ISSUE on XML Security Token Wrapper. ACTION on editors, Jerry. Ron - several issues, including labeling? Chris - signing of SAML Token. We should think about whether we need it. No scenario in XRML doc that needs it. Jerry - There were other reasons, will reconstruct. NEW ISSUE Grammar to express elements - l167 - ACTION on TC to Review. Status PENDING. Clarification that fragments are illustrative (Tim Moses). Only normative is referenced XSD. NEW ISSUE Security considerations added by Tony: what should be signed (Ron - it wasnt covered in current doc). See line 1500. Ron to review this new issue. Took text from SAML binding, uses assertion - Tony will correct before issue of next draft. ACTION Chris - put together a draft straw man of a potential interop script, mail to the general TC list. Date: in 2 weeks = December 28, 2002. ACTION Kelvin - will ping Eric on use cases. ACTION on chairs - add vote to affirm straw poll selected names to agenda for Tuesday call. secondary docs: "web services security: tokenType Token Profile" primary doc: "web services security: SOAP Message Security." ACTION on IBM, Microsoft, and Verisign: we will try to get what we can on licensing on the WSS TC web site. ACTION on group for all TC members to disclose IPR issues. ACTIONS arising from Liaison reports? ACTION on TC to consider impact of policy/QoP work. ACTION ON CHAIRS - Create a subgroup to come up with requirements. ACTION ON TC - Phone next Tuesday, December 17. Members who attended this F2F should make every effort to attend.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC