On Tue, Oct 18, 2011 at 8:10 PM, Cantor, Scott <[email protected]> wrote: > On 10/18/11 8:17 PM, "Sam Hartman" <[email protected]> wrote: >>So, I'd prefer the context be fixed. I think we need it to be fixed for >>GSS-EAP. If the use cases for ECP are going to be different then we >>should consider that. However it would be valuable if you could plug one >>in case of the other. > > I guess the way I look at it is that as a consumer of the GSS naming > extensions, I'd be physically ill shipping code that hardcoded any names, > so I see it all as a config time question. > > But then I'm also accused of designing systems that are too complex.
We should want to not hard-code mechanism OIDs, for example, but we have little choice but to hard-code things whose semantics must be embedded in the application. For example: name types. We've added mechanism attributes as a way to avoid hard-coding mechanism OIDs: hard-code the semantics you want rather than the mechanisms you know at that time support those semantics. We could do that with mechanisms, but name-types seem to basic a unit for further decomposition. Ditto, I think, naming attributes, though perhaps not because they are so basic as because there's too much left to run-time interpretation. Fortunately, I think we'll be able to make some types of authorization operations configurable so that naming attributes need not be hard-coded but configurable (e.g., group-membership-like attributes). That said, I don't yet understand what Sam means by "context" here. Nico -- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
