3/30 Telecon OGSA BP

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.