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 <[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 specs@openid.net http://openid.net/mailman/listinfo/specs
