• Section (7.1.1).  This section discusses the necessity for shared-semantics amongst authorization token formats.  Instead of "VOMS extensions", which is unclear what that means, I think you mean "FQAN-equivalent semantics for describing VO groups/roles."   

• Section (7.2).  If we have the semantic equivalences described in (7.1), then the incoming message-processing stack of a PGI-compliant service endpoint should be able process all three types of client-credentialing mechanisms equivalently:

• Clients supply SAML attributes authenticated by End-Entity Certificates at the SOAP level (Idealized Unicore)
• Clients supply SAML attributes authenticated by Proxy-Certificates at the SOAP level (Idealized Genesis II)
• Clients supply VOMS-style Attribute Certificates authenticated by (and embedded within) Proxy Certificates at the SSL/TLS level (Idealized gLite/ARC/Naregi)  

By the time message-processing reaches a policy-decision module, the service has distilled an authenticated set of distinguished names, FQAN groups/roles, and restriction policies that look the same, independent of how they were supplied.   

 

By mandating a "receiver-makes-right" strategy (section 7.7), you obviate the complexity of sections (7.3) and (7.5).  Such reduced complexity affords us a quicker incremental roadmap in which clients can remain largely unchanged, while additional infrastructure complexity is only initially needed at those service endpoints intended for advertisement within multiple infrastructures.

• Section (7.4).  Be careful with your language: do not mandate the management of authz/authn information not relevant to inter-grid interaction.  (E.g., Genesis II does not make use of local-UID mappings ).  

• The document is missing a brief consensus on SOAP-over-HTTPS communication that mandates a specific variant of SSL/TLS (i.e., anything that implements RFC-2246, The TLS Protocol Version 1.0, which excludes GSI-OpenSSH.)