On 10/18/11 5:57 PM, "Sam Hartman" <[email protected]> wrote: > >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.
And I think the proposal is that the context appear inside the naming extension attribute name as a modifier? >It's probably a different context if you have third-party assertions >including attribute query results or somehow multiple authentication >statements. My current implementation of that doesn't distinguish that case (the attributes end up in the same bucket), but it's an easy fix. https://issues.shibboleth.net/jira/browse/SSPCPP-399 >First, have I got the context right? Much of the time the use of third party sources tends to be for "local" sources associated with the domain of the application, but I agree in principle with the need to distinguish that. I suppose in that sense the cases I've seen would match what you were referring to for Kerberos, the enterprise scenario. >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. Is it necessary that the value be fixed? If the application-specific names of the attributes themselves aren't fixed, do the contexts have to be? -- Scott _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
