During the review of the "Basic Security Profile - Secure Channel" today it was pointed out that Section 3.4 (Security Token), Section 4 (SAML Token Profile 1.0) and Appendix D (Key Information Exchange) are 'more basic' than the other parts of the profile and that it would be worth splitting them off in a separate document. Doing so would allow other future security profiles (e.g., an MLS profile) to use these sections without creating unnecessary dependencies with the Secure Channel (TLS) profile. Therefore the proposal is to separate these sections in an "OGSA Basic Security Profile" document. This document would expose the claim required to satisfy the WSRF BP security profile requirements (http://www.ggf.org/namespaces/2005/07/OGSABasicSecurity-1.0) but would have no normative dependency on the WSRF BP. In addition it was proposed that this profile would have explanatory text stating that it is defining an 'anonymous channel' (one requiring no security or authentication for service interaction) and would also expose the following claim: http://www.ggf.org/namespaces/2005/11/OGSABasicSecurityProfile-1.0-Anonymous... (This second proposal is optional and is primarily to reduce the number of security profiles we have to write.) The "Secure Channel" profile will then reference the "OGSA Basic Security Profile" and will expose in turn the following conformance claims: http://www.ggf.org/namespaces/2005/07/OGSABasicSecurity-1.0 (as required for composition with the WSRF BP) and http://www.ggf.org/namespaces/2005/08/OGSABasicSecurityProfile-1.0-SecureCha... Comments on the list, or please join next Monday's call where this proposal is scheduled to be discussed. Andreas

From the minutes: - 1698: Strictly speaking the features described in section 3.4 and section 4 are orthogonal to the rest of the profile. Tokens, and the key exchange mini-specification would apply to both TLS and MLS. - If this text is left here then the MLS profile would have to depend on this profile; or worse, duplicate the same text. - Frank proposed that if these sections are needed in general then it might be worth deleting these sections from the Secure Channel Profiel and adding them to the WSRF Basic Profile. - Agreed, in principle, to remove the sections from this spec. and discuss how to make them apply to any profile. - Andreas proposed that these sections should be part of a Basic Security Profile and that Profile could then be combined with the WSRF BP or be referenced by the Channel profiles. The Claim URI mechanism defined in the WSRF BP allows multiple Security profiles to be composed with it so there would be no problem with this approach. - Hiro proposed that such a Basic Security Profile could also serve as an 'anonymous' channel profile (one that makes no statements on channel security) and could also solve the problem of having a separate, essentially empty, profile document with no security statements. - Andreas was tasked to write up the proposal for splitting up the Secure Channel Profile and send it to the list to collect feedback from stakeholders not on the call.

-- Andreas Savva Fujitsu Laboratories Ltd