Hi All, Yesterday we had a few discussions internally that led to the following thoughts on how AA should be tackled for NSI 1.0. This is a very short/briefly written summary of the general direction - these should be elaborated in the CS specification with more explanatory text: 1. Pairwise trust between NSAs. This means that if NSA A and NSA B trust each other will agree to exchange NSI messages between their NSAs through a secure connection. Authentication mechanisms are needed to establish the secure connection and exchange messages 2. As part of the pairwise agreement, they may choose to do their AA using a security profile agreed on by OGF NSI group or a common set of attributes for a custom security profile they both bilaterally agree to. 3. The NSI message will carry information on the type of security profile chosen, and then an opaque block of attributes/SAML assertions/whatever that are specified as part of the security profile. 4. The NSA receiving the message should be able to look at the security profile "type" and determine if it can process the AA attributes block presented. If it can, it should parse the opaque block and expect it in the format as specified by the security profile. If it cannot, it SHOULD reject the message, but that really depends on local policy. 5. Intermediate NSAs may have multiple pairwise agreements and are responsible for segmenting the ingress service request. In order to segment the request, they will need to make an appropriate decision, based on local policies and the ingress AA attributes, on what AA information to present to the pairwise NSAs for the various segmented service requests. 6. A set of default security profiies SHOULD be supported by all NSA's to enhance the chances of interoperability. **We need to see if we can get an agreement on this quickly ***** (FOR EXAMPLE ONLY: A security profile called USERPASS could be chosen which specify the username and password attributes, and how they should be represented, OR a security profile called INCOMMON could be chosen with the set of attributes that have been agreed upon by entities supporting INCOMMON federation for path setup. 7. The above method is not risk free. Security considerations section should highlight the risks. We can discuss this more on the Wednesday morning call - since I have only captured bullet points in this email, some nuances that are important may not get through. I look forward to your comments to this broad direction, so we can decide to put in the effort to specify these security profiles or have some security experts do so. Inder -- Inder Monga 510-486-6531 http://www.es.net Follow us on Twitter: ESnetUpdates/Twitter <http://bit.ly/bisCAd> Visit our blog: ESnetUpdates Blog <http://bit.ly/9lSTO3> Facebook: ESnetUpdates/Facebook <http://bit.ly/d2Olql>