Looks like a good foundation. A couple of comments/suggestions: - 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.) -Duane