Hi Andrew and Duane,
We may have to redraft the OGSA work once the WS-SecurityPolicy work is complete, but it is not clear yet how or when.
The OASIS Web Services Secure Exchange (WS-SX) Technical Committee has submitted WS-SecurityPolicy 1.2 specification, which is an approved Committee Specification, to be considered as an OASIS Standard. OASIS member vote will complete the end of June and is likely to become OASIS standard early July. Thanks, ---- Hiro Kishimoto -------- Original Message -------- Subject: [ogsa-wg] Minutes of OGSA-WG Security session 2007-05-31 From: Alan Sill <Alan.Sill@ttu.edu> To: OGSA WG <ogsa-wg@ogf.org> Date: 2007/05/31 23:15
Here are the minutes of OGSA-WG Security call 2007-05-31, 8:00 - 9:00 am CDT.
Hiro, can you adjust the list of attendees as necessary?
Thanks, Alan
Minutes of OGSA Security session
Attendees: Jack Andrew Grimshaw Duane Merrill Mark Morgan Chris Alan Sill Frank Siebenlist Hugo Mills
Minutes approval - Apr. 23: https://forge.gridforum.org/sf/go/doc14410 - OGF20: https://forge.gridforum.org/sf/go/doc14473 - F2F AuthZ: https://forge.gridforum.org/sf/go/doc14536
-- Approved as posted
Action Item review * AI-0409b: Liberty spec statements on EPRs (compatibility or intent vs OGSA BSP) should be checked; are these true and is there some difference in interpretation that is unresolvable? - Duane will do an initial review to be discussed on the April 23 teleconference
-- Duane concludes that the language and policies are not inconsistent, but not wire compatible. Liberty is not only an EPR provider, but also authentication service. We have not profiled such an implementation, but observe that the schemas are different and will require different parsing. At this level, they are not compatible as different implementations of a standard might be, but are not incompatible in concept. There is no equivalent to some Liberty ideas in terms of use of identity as a client in what we have profiled so far. There is also a difference in semantics that Duane regards as a deficiency in that security mechanisms used to transport the message-level content are limited to single strings in Liberty EPRs. The different URI components referenced are not as flexible as the Secure Addressing profile.
Andrew refers to a mesage sent out March 20 by Duane (he will refresh this reference with a new e-mail shortly) and proposes closing this action item. This was agreed. Note the discussion can be moved to the tracker item on this topic.
2) Use case document and profile review
Andrew noted comments made by by Alan regarding discoverability and service requirement description features and indicated that these are or will be addressed in the OGSA Security Profile 2.0 - Secure Addressing document. He displayed this document, which is on the repository, on Glance for discussion. This covers usage of EPRs that are descriptive, and allow the client to know what it needs to do to talk to a given service. The heart of the document is in he definition of hte security context in section 4. The security contacts go into the metadata piece in the EPR. An example is given in the document (see XML beginning with "<secaddr:SecurityContext>..."). The example given in the document describes a service that expects transport-level X.509, as is common practice now, followed by message-leel security for some portion of the transaction. In this particular case, it also says how you would expect to authenticate. The "contexts" allow you to define items that can be described in later profiles.
From a process point of view, Andrew wanted to address a few comments received so far at this point. The trackers are the ones in GridForge in the OGSA-WG by Hiro for these items (see forge.gridforge.org and navigate to OGSA-WG then Trackers to get there). Under "Addressing" there are a couple of specific items that need to be dealt with at this point:
- A comment was made by Hiro that WS-SecurityPolicy has a mechanism for describing how to do such descriptions, but not where. Andrew responded that this has been slow to converge, and is more general than what we are trying to accomplish here. Progress is being made on that front (i.e., SecurityPolicy) and Duane has been studying the draft spec, but the intent here is more specific and aimed to be quicker. We may have to redraft the OGSA work once the WS-SecurityPolicy work is complete, but it is not clear yet how or when. The syntax of the schemas are likely to be different once the OASIS work is complete. (See www.oasis-open.org for further details on this progress -- look for the ws-wx TC public documents.) Andrew proposes an action item to look into this in detail and see if an early recast of our work can be made based on the current status of Ws-SecurityPolicy. Alan noted from the Glance session that an use case examples document has recently been posted in WS-SX (May 15) that may be useful.
- Another comment was made by Hiro that use of a MUST ought to appear in the profile documents for security contexts, i.e. "A provider MUST support one of the following..." No one seems to own this comment, which had come up in the face-to-face meeting. Some discussion with Frank followed, in which the necessity to avoid an empty security context was pointed out. Andrew was concerned that any specific limitation will necessarily lose some portion or other of the community, and he, Alan and Frank agreed that what is necessary is for a given community to specify its accepted set of authentication mechanisms and be able to discover, advertise and select inclusion of services based on conformance with their desired set. Section 4.4 of the Secure Addressing document fives an example of such use.
Comments were made at this point that the Secure Addressing profile becomes more of a meta-profile when viewed in this context. Interoperability is then expected to be provided in the derived profiles for particular security authentication mechanisms (TLS, X. 509, etc.). Frank pointed out that this introduces another layer, and in this sense is not a true profile in and of itself in the sense that it could ensure ineroperability, but Duane and Andrew and Alan felt that the existence of this layer is in fact essential for ultimate interoperability. After discussion, this was agreed to and the comment was closed as "resolved."
- Would this make the OGSA BSP and SP secure channel obsolete? Andrew believes that it will, once complete. Both intend to put key information into the EPR. The combination of Secure Addressing and specification of the transport (by the Secure Transport document) will eventually supply a key set that will supersede BSP and secure channel for the reason that the BSP core does not provide all of the features described here.
The comment was closed with notations made by Andrew to this effect.
Next call in this series will be on June 18 (Monday) 6 pm Eastern.
Alan Sill, Ph.D TIGRE Senior Scientist, High Performance Computing Center Adjunct Professor of Physics TTU
==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
-- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg