Recently I've tried to use draft-ietf-kitten-gssapi-naming-exts in the design of a GSS-API mechanism. I think this is a good start but is not quite done yet. draft-hartman-gss-eap-naming-00 discusses a couple of problems with naming extensions: * The format of attribute names proposed in this specification is incompatible with several of the things you'd like to name, in my case including SAML attributes. * The description of how to name SAML attributes currently in the document is inconsistent with the SAML base specification * The approach of naming things like SAML attributes entirely with a * The approach of letting a mechanism create authenticated attributes with an arbitrary URI makes the application's life really hard While not mentioned in my existing draft, I've noticed a number of other problems: * The document claims to name Kerberos entities such as authorization data elements but does not actually provide a name for them. * The document does not discuss the encoding of subjectAlternativeName elements. I suspect application authors will assume human-readable text and PKI folks will assume DER. In addition, there is no way to get the identity of the issuer of a name attribute. I've discussed these concerns with one of the authors, Nico Williams. I have also requested time to present my concerns at the kitten meeting at IETF 78. I'm happy to help resolve these concerns up to and including becoming an author of the document and writing significant text. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf