>>>>> "Luke" == Luke Howard <[email protected]> writes:
>> 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.
Luke> Don't forget that get_attribute provides a display_value
Luke> (printable representation) and that this is supported in the
Luke> Moonshot implementation -- but requires the RADIUS library be
Luke> configured with dictionaries. value is always the raw data.
Why do we (kitten--Nico, Leif and I) do these things to ourselves?
>> 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.
Luke> Isn't then the dictionary just another configuration file?
Yes. For that use it's probably OK. However it requires you get the
dictionary set up correctly even if your application understands what
RADIUS attribute it wants.
>> 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.
Luke> Seems less desirable.
Agreed.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
