OGSA January 2006 Interim Meeting
=================================

  Location: Sunnyvale, CA
  Date:     19/1/2006, afternoon

* Attendees 

  Hiro Kishimoto
  Dave Snelling
  Jem Treadwell
  Andreas Savva
  Fred Maciel
  Darren Pulsipher
  Chuck Spitx
  Fred Brisard
  Ravi Subramaniam
  Dave Berry
  Steve McGough
  Neil Chue Hong
  Takuya Mori
  Frank Siebenlist
  Jay Unger
  
  Bridge:
    Alan Sill
    David Chadwick 

  Notes: Andreas Savva

  See also Security agenda ppt:
  https://forge.gridforum.org/projects/ogsa-wg/document/ogsa-security-session/en/1

* Security - OGSA AuthZ joint discussion

   - "Use of SAML" document finished public comment with no comments
     - Many people have looked at it. One minor change and expect it
       to be published, but not sure when.
   - OGSI Authorization Requirements: 1 comment
   - Attributes ?

   - Charter revision
     - Looked at revised charter
     - Hiro explained procedure for getting approval: circulate within
       WG and if happy with level of support send to ADs; otherwise do
       a BoF.
     - New charter output: 2 new versions
       - Authorization document
       - (The attributes document is not mentioned)
     - The milestones are not clear.

   - Everyone is doing their own solution in the authorization area;
     no attempt to reach consensus on a common approach. Perhaps this
     is the reason why some of the docs received no comments. It is a
     problem but there is no solution.

   - There is real difficulty with getting buy-in from major grid
     projects. Even if they say ok on the charter it does not mean
     they will contribute actively.

   - Takuya has contacted NAREGI. Alan also asked about PRAGMA.
     Takuya agreed to contact PRAGMA as well.

   - There is a Grid Interop at the next GGF16. Alan unfortunately
     canot make GGF16.
   
   - Hiro's issue: how to combine security protocols (authorization)
     with service invocation?
   - Cannot tell people how to do authorization. Also do not want to
     create refined schemas because the semantics attached to the
     schema by different organizations may be different.
   - So focus not on attribute description but on the information
     about what are the required attributes by the services. (Analogy
     with card tokens; tokens are different but using a token may be a
     common point.)
   - Attribute information is dependent on the issuer. The proposal is
     not to try to map attributes between schemas but just to
     facilitate the exchange of what schemas are supported and can be
     used for authentication.
   - If no attribute mapping is attempted then cross-site auditing or
     logging isn't possible.
     - It is out of scope of OGSA AuthZ
   
* Security - Review of Basic Security Profile -- Secure Channel 

  - Just doing secure channel (point to point) and looking towards
    end-to-end (MLS) eventually. Performance of MLS is an issue. (Also
    need a way to describe policy and name entities and ...)
    - Note that this is point-to-point and not host-to-host.

  - There is a bigger problem that needs solving (...) and this
    [profile] is the first step towards that goal (a bootstrap step).

  - This profile says nothing about what is an authenticated
    entity. It may be a next step.

  Action: To add an example of how the keyinfo exchange (core) is used
          with the secure channel profile

  Action: Since Secure Channel should be composed with a Core it
          should not expose the BasicSecurity claim. Only Core should
          do that.

  Update and aim for a final call by the end of the month

* Security - Review of Basic Security Profile - Core

  - 1.2: This profile is not extending the WS-I Basic Profile
  - 1.2: Generalize the statement discussing the security profiles
    that can be combined with this profile.

  - Agreed that this profile will not expose an anonymous channel
    claim URI. An anonymous channel profile should be defined as a
    separate document. 
    - The important point is that it can be done with the current
      document structure. It may be left to the people who want it to
      actually do it.
  - Need to expose the extensibility elements in referenced specs
  - Need to address (at some point) how information on what features
    are required or supported.

* Future plans

  Discussed plans for security design team and prioritized work:  

  - 1 Work on a Security architecture
  - 2 How to combine security functions (security context) with
      functional interfaces.
  - 3 MLS profile
  - 4 Issues raised by OGSA-Data wg and collaboration