[ogsa-wg] OGSA Basic Profile Telecon Agenda 3/30
Samuel Meder
meder at mcs.anl.gov
Wed Mar 30 13:33:37 CST 2005
Minutes attached.
/Sam
On Tue, 2005-03-29 at 21:31 -0500, Tom Maguire wrote:
>
>
>
> The following is a proposed agenda for OGSA-WG telecon on March 30th
> Wednesday from noon to 2pm (CST).
>
> The dial-in number for Wednesday;
> Free: +1-800-664-6895
> Toll: +1-719-955-1126
> passcode: 285178
>
> Screen share service will be provided.
> URL: http://ogsa.glance.net
> Session key: 0330
> See more explanation:
> http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html
>
> 1) Early discussion (10 min)
> Note taker assignment
> Roll call
> Agenda bashing
>
> 2) Security discussion (60 min)
> 1324: Separate Security Basic Profile
> 1320: Transport and/or Message Level security
> 1321: Discovery of key-info for encryption in message level
> security
> 1322: Use of Proxy Certificates
> 1323: Communication of assertions
>
> 3) Basic Profile discussion (50 min)
> 1317: QueryRP should be optional
> 1262: Should set resource property be included in BPv1?
> 1211: What must a service satisfy before it can be called an
> "OGSA service?"
> 1314: Relationship to WS-I Basic Security Profile 1.0
>
> 4) Wrap up (10 min)
> AOB
>
>
> See telecon schedule until May F2F:
> https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule
> ----
>
>
> Perfection is achieved, not when there is nothing more to add, but when
> there is nothing left to take away. – Antoine de Saint-Exupery
>
>
> T o m M a g u i r e
>
>
> STSM, On Demand Architecture
>
>
> Poughkeepsie, NY 12601
--
Sam Meder <meder at mcs.anl.gov>
The Globus Alliance - University of Chicago
630-252-1752
-------------- next part --------------
Participants:
Tom M, Dave S, Sam M, Frank S, Absollom, Jem
- Initial discussion:
* Frank: Trying to motivate definition of key info
discovery. Addressing criticism that this should be done elsewhere
(e.g. WS-I, WS-Security). This is wrt to email sent by Frank
("[ogsa-wg] "tactical-agreement" (#1321: Key-info discovery for
encryption in message level security)").
* Tom: Where do standardize/put this requirement: Outlined the
options: Profile/App Note etc.
* Discussion on where to put the key information. DaveS/FrankS in
favor of putting it into EPR. Absollom points out that services may
just want to use URLs. Frank points out that you can't just use URLs
when using message level sec.
* TomM: There needs to be a backup mechanism to get at this info in
case it is stale (e.g. WS-MX).
* TomM: suggesting wording along the lines of: If using EPRs &
requiring message security add this piece of metadata to the EPR.
* FrankS: The whole issue of metadata and EPRs is being side stepped
by addressing group
* TomM: agreed
* Discussion of whether we should add a wrapper element around a
ws-security element.
* Discussion of how to factor this work in terms of documents. The
resolution was to make it part of either the basic profile
(addressing chapter) or if that is split up into two parts, the
security profile.
* Action: Frank & Sam to come up with text and schema for this.
- Issue 1320:
* Discussion of whether this ought to be a SHOULD or a MUST. DaveS
leaning towards requiring a MUST. Takuya points out that other
security mechanisms may be used (e.g. VPN/IPSec).
* The discussion resulted in agreement to make require the profile
restrictions/requirement for TLS/SSL if using https. And if using
http we MUST use WS-Security/MLS as per profile. The profile will
require that one of these mechanisms is implemented by a service,
which essentially means that clients will have to support both.
* Action DaveS (?) to update text.
- Issue 1324:
* FrankS/DaveS: We should not make it a separate profile
* TomM: Happy with that.
* Since we require https/or MLS when using http we should leave it
part of the same profile.
- Discussion of naming related issues:
* 1298, 1231-33 should be moved to OGSA naming profile
* Franks: We should keep around field for resolver service EPR since
it is independent of naming discussion
* TomM: EPR can be self contained enough to do resolve message with no
parameters.
* TomM: Tactical to have them in the profile until Naming group comes
up with something to replace them.
* TomM: Profile will not make any statements about who is going to add
the resolver EPRs to the EPR.
* Action: 1298 should be closed no action since we do not make any
statements about who adds the resolver EPRs and how they are added.
* Action: TomM to pull back 1231-33 into the document with empty body
resolve message.
- Issue 1317:
* Action: TomM to make this a SHOULD with follow-on MUSTs (if
implemented)
- Issue 1262:
* DaveS: We should just drop it from the profile and not say anything
about it in the profile.
* TomM: Agreed
* DaveS: 3 alternatives: Use it this way, don't say anything, don't
use it
* DaveS: Dropping it means we don't preclude it's use, but the profile
will not guarantee any interop
* Action: TomM to remove from profile doc.
More information about the ogsa-wg
mailing list