[ogsa-wg] WS-SecurityPolicy 1.2 Submitted for OASIS Standard (Re: Minutes of OGSA-WG Security session 2007-05-31)
Hiro Kishimoto
hiro.kishimoto at jp.fujitsu.com
Mon Jun 4 03:55:06 CDT 2007
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 at ttu.edu>
To: OGSA WG <ogsa-wg at 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 at ttu.edu ph. 806-742-4350 fax 806-742-4358 :
> ====================================================================
>
>
> --
> ogsa-wg mailing list
> ogsa-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/ogsa-wg
>
>
More information about the ogsa-wg
mailing list