Hi. As a recollection while working on draft-hartman-gss-eap-naming which became draft-ietf-abfab-gss-eap-naming I introduced the concept of a naming extensions context. The idea is that two attributes are different depending on some broad context of their interpretation. The idea is for example that Kerberos attributes in an enterprise context probably want to be interpreted differently than SAML attributes in a federated context.
Since then this concept has been worked into the core naming extensions document. (Perhaps some day we'll publish that) However, now it's time to align things between GSS-EAP and SAML ECP and other things. I think we're talking about basically the same context in both mechanisms for the SAML assertion and attributes. We're talking about what I'll call the basic federated context. Attributes are asserted by a party associated with the authentication of the subject. The attributes are integrity protected and their origin authenticated. That is in EAP, if the RADIUS integrity protection fails we won't get this far. In SAML ECP, if we don't trust metadata for the IDP or if the SAML assertion is not signed, we won't make it this far. It's probably OK in this context to include attributes asserted by a third party that are re-asserted or otherwise vouched for by the IDP. It's probably a different context if you have third-party assertions including attribute query results or somehow multiple authentication statements. The key distinguisher of the context is that the IDP and acceptor are in different trust domains but thet IDP and attributes are in the same trust domains. First, have I got the context right? Second, what URN do we want to use. The current URNurn:ietf:params:gss-eap:saml-aaa-assertion has gss-eap and aaa in it both of which are wrong. Comments welcome. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
