Hi, OPS-DIR, Stefan, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Section 1.2 (deployment) is helpful to exhibit a real world deployment, nice to keep. Section 2, mixing XML (as proposed by this I-D) and ASN.1 (per X.509 certificates) force all implementations to support both XML and ASN.1 syntaxes. This complicates deployments. Moreover this could also inflate the size of certificates and potentially add one round-trip when doing a TLS exchange. Section 3.1.2 even goes further in complication by explaining that OID must be expressed as strings in the XML. Section 2, marking the extension as critical should state that this is wrt to RFC 5280. And, the extension is either critical or not: saying 'MAY be marked as critical' is ambiguous. Section 3.1.1 makes a reference to section 3.3 which is not in the document. Section 3.1.1 talks about time but without mentioning whether it is UTC. It is also unclear from my reading of the I-D whether the content of the certificate can be traced back to a specific SAML operation (for debugging/auditing for example). I was also unable to find information about the other certificate attributes when used with this extension (for example which value for validity period or for the CRL). This comment applies more to the use case than on the specific proposed extension; in the same vein, the enrollment process should probably be described. I would welcome a few words about the scalability (notably in terms of GUI or local secure storage) when this system is used to get X.509 certificates from several identity providers for which the subject can have multiple identities. Nits: a lot of missing '.' at end of sentences or some 's' at the end of some verbs :-) Hope this helps -éric