On Feb 27, 2013, at 4:29 PM, Russ Allbery wrote: > But if the userinfo service knows what type of OTP the user is going to > use, why would WebLogin need to then tell it, in the validate call, what > type the user used? Oh, because it doesn't know the destination URL and > can't duplicate the same information.
Right.. we could send the URL along in the validate call, but then the validate code would need to do the same lookup dance that the userinfo just did -- seems like we could just skip it and get right to sending the token along to the appropriate backend. > Hm, yes, we could add <factor> as an optional element in the > <multifactor-required>, which specifies the factor the user needs to use. > Although at that point why not just limit the configured <factors> > returned by the user information service? All the code is already in > place to handle that. Hm.. yes -- so instead of <factors> being the list of all the factors a user is capable of using, it would be the list of factors that WebLogin should enforce for this user/WAS combo, if we decide to enforce them. What happens if a WAS wants o3, but userinfo only sends along o2 because it was configured to subset the factors for this user/WAS combo? If <factors> are the full list of capable factors, then we wouldn't have to worry about userinfo sending along only a subset, or having to modify the userinfo configuration if a WAS decides to require a different factor. An additional corner-case: if <factors> is the complete list of user-capable factors, a WAS requires o2, and userinfo requires o3. Would WebLogin need to loop through the factor types? Display both forms at once? I think we could live with this working either way -- I didn't realize that <factors> might be a subset. Ben
