Project review: response sets

[Dmitri Pal]

On 07/13/2012 06:51 PM, Nico Williams wrote:
> On Fri, Jul 13, 2012 at 5:42 PM, Dmitri Pal <dpal at redhat.com> wrote:
>>> It is perfect opportunity to offset it to intermediary like SSSD or
>>> similar software for other platforms.
>> Over time if some of those get standardized they can be moved to the
>> common library under kerberos but for the time being it makes sense to
>> leave it to the application to deal with.
> I don't think we should conflate how to talk to a piece of hardware
> with how to talk to the user.
>
> I would rather see the application tell libkrb5/plugins how to access
> available hardware (e.g., "use this PKCS#11 DLL", "use these callbacks
> to talk to the token"), and to separate this from interaction with the
> user.
>
> If there are 5 tokens that can be accessed with three different
> libraries I'd expect the app to use some gic_opt to tell the plugin
> about the three libraries and let the plugin list the tokens.  Later
> the plugin might want the user to choose a token.  The question and
> response need not be anything more than strings, really, and the
> plugin can use the selected token with the correct library.
>
> Nico
> --
Why create a complexity from get go before we even know where the things
would turn and how the prompting would happen?
This is all just a pure speculation and anticipation of use cases.

Make it simple, try the implementation, see what happens, correct the
course.
Otherwise we are over-engineering things in advance.

The proposed approach is very simple. If is does not work we can correct
it by deprecating this interface and implementing a different one or
actually wrapping it to do marshaling and un-marshalling as you suggest.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/