Project review: response sets

[Nathaniel McCallum]

On Tue, 2012-07-17 at 11:42 -0500, Nico Williams wrote:
> On Fri, Jul 13, 2012 at 5:53 PM, Dmitri Pal <dpal at redhat.com> wrote:
> > On 07/13/2012 06:45 PM, Nico Williams wrote:
> >>> It is perfect opportunity to offset it to intermediary like SSSD or
> >>> similar software for other platforms.
> >> Well, I can see that SSSD might want to tell libkrb5/whatever plugin
> >> what PKCS#11 implementation to use to talk to a smartcard, say --
> >> that's quite fair.  For OTPs this may be different because perhaps
> >> there's no standard API to access hardware OTPs (again, please excuse
> >> my ignorance).
> >>
> >
> > I would agree with you 100% if all that would have been standardized in
> > the same way as smart cards but the technology is not there.
> > By assuming that libkrb5 would be in charge of all these methods from
> > get go we are creating a barrier for adoption. This of a third party
> > app. One case they can do everything in their tree and another they have
> > to get the code to be a part of the libkrb5.
> >
> > I would rather let the app do it and then when the prompter
> > implementations mature move them under library over time.
> 
> I've thought long and hard about this over the weekend.  My conclusion
> is that you're conflating two things in this API that you should not
> want to conflate: user interaction, and hardware interaction.

I don't think this is really true. The API doesn't mandate anything
related to hardware vs software. It is entirely possible that moving
hardware token support into libkrb5 will require no API changes.

It is also worth noting that the otp client plugin is currently out of
tree, so this can be discussed in greater detail when we propose merger.

Nathaniel