Hello, About this topic we would like to comment that -in analogy to non Grid PKIs- revocation of a N-level Proxy Certificate should only be performed by its Issuer (N-1 level entity, does not matter if it is an EEC or another Proxy) *and* by any other entity up to the Root CA itself (that is hierarchy levels N-2...0). When a certificate is revoked, then their issued certificates (again does not matter if EEC or Proxies) should be considered revoked. The "one-request" mechanism proposed in OGRO (embedding the whole Proxy Cert Path in one OCSP Request ) could manage this proposal with some modifications, because when the OCSP Response is received then it could invalidate the Cert Path just below the certificate whose status is not "Good". We have been exploring also the "direct Proxy revocation" method: when a Proxy is destroyed or revoked for any other reason then an "administrative" message is sent to the OCSP Service so the revocation is done directly in its certificate status database. The authorization checking on such admin message is based on a very simple system that verifies if the issuer (message originator) is able to revoke such credential (i.e. is part of the Certificate Path and can be found in any level above the Certificate being revocated).This should be customizable by the relying party, i.e. in a new rule of the Grid Validation Policy. Based on this, we don't think encoding the AIA into the Proxy Certificate should be mandated, but instead it would be better to apply the same provisions of section "4.4 Responder discovery" (from the current version of the document). In any case a mechanism like OGRO's Grid Validation Policy may deliver this feature to relying parties. We hope to have understood the same idea that you presented with the PPT back at the GGF15, but in any case please let us know what you think. Regards, Oscar & Jesus