Cool, committed. 

We ready to publish Draft 2?


On Oct 23, 2007, at 2:46 PM, Barry Ferg wrote:

> Yes, there are arguments to be made for both sides here.  I have to
> agree with Johnny and David's point on this; lets give the RP what it
> can be reasonably expected to understand.
> On 10/23/07, David Recordon <[EMAIL PROTECTED]> wrote:
>> I see both sides of this.  At the end of the day the RP is ultimately
>> making the decision as to if the user can proceed or not.  Just as in
>> SREG if the RP says email is required and the user/OP choose not to
>> provide it, the RP still has to decide what to do.
>> I do agree that it is easier on a RP to not have to understand any
>> relationships between policies.  In this case of the three defined
>> policies I see that as less important, but the argument that it
>> becomes increasingly likely that the RP may not understand a given
>> policy created by an OP is quite legit.  Also as you argue, the OP
>> knows what actually happened so can best place that within the  
>> policies.
>> I'm alright changing the recommendation to the OP at least including
>> the specific policies requested by the RP and shifting some of that
>> burden back to the OP.  That also is in line with general OpenID
>> philosophy of making the OP do the heavy lifting.
>> Barry, I was talking to you about this yesterday, you alright with
>> this as well?
>> In any-case, lets get Draft 2 out in the next 2-3 hours.
>> Thanks,
>> --David
>> On Oct 23, 2007, at 10:05 AM, Johnny Bufu wrote:
>>> +       [...] For example it is recommended that if the OP
>>> +        specified the Multi-Factor Physical Authentication policy
>>> and the RP
>>> +        requested the Multi-Factor Authentication policy, that the
>>> RP's
>>> +        requirements were met.
>>> This puts undue requirements on the RP implementations. As a design
>>> principle, I believe the goals were to make required effort and
>>> adoption and as easy as possible for RPs, and have more happening
>>> on the OP where possible. I would at least complement, if not
>>> replace, this patch with:
>>> "For example, if the RP requested Multi-Factor and the OP supports
>>> Multi-Factor Physical, it is recommended that the OP includes both
>>> policies in the response."
>>> As I argued on the osis list, the OP is in the best position to
>>> make judgments about the qualities of its authentication
>>> mechanisms, and it should respond to the point to the RP's
>>> requests. What if the RP knows what Multi-Factor means, but has no
>>> idea (and no interest) in Multi-Factor-Physical?
>>> Johnny

specs mailing list

Reply via email to