> I think the interpretation of RADIUS strings and opaque data would be > the same as far as we're concerned. GSS-API buffers don't tend to have a > trailing null in the C bindings, so I can't see a difference.
Don't forget that get_attribute provides a display_value (printable representation) and that this is supported in the Moonshot implementation -- but requires the RADIUS library be configured with dictionaries. value is always the raw data. > 2) Require that the GSS-EAP implementation understand the type and > multi-value semantics of anything it exposes. That's kind of undesirable > because we want the GSS-EAP implementation to eventually be a component > of the operating system and we expect deployments to extend the set of > attributes thought the use of vendor-specific attributes. We expect > facilities like Shibboleth to be able to map AAA attributes into local > attributes under the control of a configuration file. Isn't then the dictionary just another configuration file? > 3) Encode the type into the attribute name exposed through GSS-API > naming extensions. We'd need to decide how inquire_name_attrs works (an > API for enumerating all the attributes an application may request.) It > could assume things were strings but applications could request the > attribute with a different type if they knew better. Seems less desirable. -- Luke _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
