Some PAPE Wording Clarifications

[David Recordon]

Cool, committed.
http://svn.openid.net/diff.php?repname=specifications&path=% 
2Fprovider_authentication_policy_extension%2F1.0%2Ftrunk%2Fopenid- 
provider-authentication-policy-extension-1_0.xml&rev=378&sc=1

We ready to publish Draft 2?

--David

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 <drecordon at sixapart.com> 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
>>>
>>
>>
>>