[OGSA-AUTHZ] Re: OGSA-AuthZ & OGSA-WG joint call

[Hiro Kishimoto]

Thanks David for your update.

I am very glad you made a lot of progress. Joint meeting at GGF17
sounds great.

Out of curiosity, have you got approved new WG's charter formally?
All I can find on OGSA-AuthZ project is proposed charter dated
Aug. 18, 2005 and it looks like working draft.

Thanks,
----
Hiro Kishimoto

David Chadwick wrote:
> Hi Hiro
> 
> I am actually at the NIST PKI workshop in Washington this week, and fly 
> home on Thursday night. So I will be travelling from about lunchtime on 
> Thursday (Eastern Time).
> 
> Here is an update for you. I have nearly finished a couple of docs to 
> present to the next GGF OGSA meeting to replace the current OGSA-SAML 
> profile. One is based on XACML and is a PDP-PEP interface. The other is 
> based on WS-Trust/SAML and is a PIP(CVS)-PEP interface. The existing 
> OGSA-SAML spec is an interface to a combinded PIP(CVS)/PDP, but as we 
> know it has severe limitations.
> 
> regards
> 
> David
> 
> 
> Hiro Kishimoto wrote:
> 
>> Hi Alan, David, Von and Mary,
>>
>> Is it possible to have one hour joint call between OGSA-AuthZ WG
>> and OGSA-WG next Thursday, April 6? OGSA-WG will have a F2F meeting
>> next week in San Francisco Bay Area and Frank Siebenlist will lead
>> this security session on Thursday.
>>
>> https://forge.gridforum.org/projects/ogsa-wg/document/2006Apr-OGSA-F2F-agenda 
>>
>>
>> I would like to proceed with our previous discussion in January.
>> Please have a look into attached meeting minutes from Jan 19 joint call.
>>
>> If David can make it, we can talk 1-2pm PDT (= 9-10pm UK = 5-6am JST)
>> same as January.
>>
>> Please let me know your availability and agenda items you want to
>> discuss.
>>
>> Thanks in advance,
>>
>>
>> ------------------------------------------------------------------------
>>
>> 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
>>        
>>          
> 
>