<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">This is a thread from the PAPE list showing another area where the IPR Process needs more clarity. Mike and I are both interpreting wording in two opposite ways.<div><br></div><div>--David<br><div><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>From: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica">Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>Date: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica">December 22, 2008 11:51:07 AM PST</font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>To: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica">"<a href="mailto:david@sixapart.com">david@sixapart.com</a>" <<a href="mailto:david@sixapart.com">david@sixapart.com</a>></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>Cc: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica">"<a href="mailto:specs-pape@openid.net">specs-pape@openid.net</a>" <<a href="mailto:specs-pape@openid.net">specs-pape@openid.net</a>>, Paul Madsen <<a href="mailto:paulmadsen@rogers.com">paulmadsen@rogers.com</a>></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>Subject: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica"><b>RE: [specs-pape] Feedback on PAPE 1.0 Draft 7</b></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div> </div><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div lang="EN-US" link="blue" vlink="purple" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div class="Section1"><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Just as the passage you quoted says, working groups may recommend approval of any of the three types of specs: Implementer’s Draft, Final Specification, or Errata. It’s the working group’s choice whether to release a draft as an implementer’s draft – explicitly planning for another round of revision after implementation feedback, or a final draft, requiring revision only if feedback during the 60 days (including from implementations that occur during the 60 days). This working group has produced a final specification and recommended approval and the approval vote should commence today.<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> -- Mike<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></div><div><div style="border-right-style: none; border-bottom-style: none; border-left-style: none; border-width: initial; border-color: initial; border-top-style: solid; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding-top: 3pt; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; "><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; "><span class="Apple-converted-space"> </span><a href="mailto:specs-pape-bounces@openid.net">specs-pape-bounces@openid.net</a> [<a href="mailto:specs-pape-bounces@openid.net" style="color: blue; text-decoration: underline; ">mailto:specs-pape-bounces@openid.net</a>]<span class="Apple-converted-space"> </span><b>On Behalf Of<span class="Apple-converted-space"> </span></b>David Recordon<br><b>Sent:</b><span class="Apple-converted-space"> </span>Monday, December 22, 2008 11:31 AM<br><b>To:</b><span class="Apple-converted-space"> </span>Mike Jones<br><b>Cc:</b><span class="Apple-converted-space"> </span><a href="mailto:specs-pape@openid.net" style="color: blue; text-decoration: underline; ">specs-pape@openid.net</a>; Paul Madsen<br><b>Subject:</b><span class="Apple-converted-space"> </span>Re: [specs-pape] Feedback on PAPE 1.0 Draft 7<o:p></o:p></span></div></div></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">I'm not sure that it actually is a misinterpretation. All sections talk about a draft becoming an Implementors Draft and then a Final Specification. Also read 5.5:<o:p></o:p></div><div><blockquote style="margin-top: 5pt; margin-bottom: 5pt; "><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><b><span style="font-size: 7pt; font-family: Verdana, sans-serif; ">5.5</span></b><b><span style="font-size: 7pt; font-family: Arial, sans-serif; "><span class="Apple-converted-space"> </span></span></b><b><span style="font-size: 7pt; font-family: Verdana, sans-serif; ">Final Approval.</span></b><span style="font-size: 7pt; font-family: Verdana, sans-serif; "> If there is consensus of, or a formal vote by, a WG to recommend approval of <o:p></o:p></span></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 7pt; font-family: Verdana, sans-serif; ">an Implementers Draft, Final Specification, or Errata, the applicable WG Editor(s) will notify the OIDF <o:p></o:p></span></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 7pt; font-family: Verdana, sans-serif; ">secretary, who will then post the applicable draft for review by the OIDF membership for a period of at least <o:p></o:p></span></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 7pt; font-family: Verdana, sans-serif; ">45 days and notify the OIDF membership of the WG recommendation to approve and of the proposed dates <o:p></o:p></span></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 7pt; font-family: Verdana, sans-serif; ">on which the review period will end and the vote of the OIDF membership to accept or reject the WG <o:p></o:p></span></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 7pt; font-family: Verdana, sans-serif; ">recommendation will occur. The notice and vote will be in accordance with the specifications in Table 1, but <o:p></o:p></span></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 7pt; font-family: Verdana, sans-serif; ">the pre-vote notice may be concurrent with the last 14 days of the draft review period.<o:p></o:p></span></div></div></blockquote><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 7pt; font-family: Verdana, sans-serif; "><o:p> </o:p></span></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">On Dec 22, 2008, at 11:21 AM, Mike Jones wrote:<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">No, this is a misinterpretation. It’s up to the working group whether to publish a draft specification as a final draft or an implementer’s draft. In this case, the working group went straight to a final specification. In both cases, the IPR processes provides IPR protection to implementers. For instance, because the working group declared draft 7 to be a final specification, for the last 60 days implementers have had IPR protection, and could have given us comments based on their implementations. (None did.)</span><span style="color: black; "><o:p></o:p></span></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span><span style="color: black; "><o:p></o:p></span></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">BTW, I’m working on the approval vote, but there is a software bug I’m working with Refresh Media on that is preventing the poll from starting. Hopefully this will start today, as scheduled.</span><span style="color: black; "><o:p></o:p></span></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span><span style="color: black; "><o:p></o:p></span></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> -- Mike</span><span style="color: black; "><o:p></o:p></span></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span><span style="color: black; "><o:p></o:p></span></div></div><div><div style="border-right-style: none; border-bottom-style: none; border-left-style: none; border-width: initial; border-color: initial; border-top-style: solid; padding-top: 3pt; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; border-width: initial; border-color: initial; "><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: black; ">From:</span></b><span class="apple-converted-space"><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: black; "> </span></span><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: black; ">David Recordon [<a href="mailto:drecordon@sixapart.com" style="color: blue; text-decoration: underline; ">mailto:drecordon@sixapart.com</a>]<span class="apple-converted-space"> </span><br><b>Sent:</b><span class="apple-converted-space"> </span>Monday, December 22, 2008 11:04 AM<br><b>To:</b><span class="apple-converted-space"> </span>Mike Jones<br><b>Cc:</b><span class="apple-converted-space"> </span><a href="mailto:specs-pape@openid.net" style="color: blue; text-decoration: underline; ">specs-pape@openid.net</a>; Paul Madsen<br><b>Subject:</b><span class="apple-converted-space"> </span>Re: [specs-pape] Feedback on PAPE 1.0 Draft 7</span><span style="color: black; "><o:p></o:p></span></div></div></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: black; "> <o:p></o:p></span></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: black; ">I think we've already broken the process quite a bit.<o:p></o:p></span></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: black; "> <o:p></o:p></span></div></div></div><div><blockquote style="margin-top: 5pt; margin-bottom: 5pt; "><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><b><span style="font-size: 7pt; font-family: Verdana, sans-serif; color: black; ">5.1</span></b><span class="apple-converted-space"><b><span style="font-size: 7pt; font-family: Arial, sans-serif; color: black; "> </span></b></span><b><span style="font-size: 7pt; font-family: Verdana, sans-serif; color: black; ">General.</span></b><span style="font-size: 7pt; font-family: Verdana, sans-serif; color: black; "> There are three stages of an OpenID Specification – draft, Implementers Draft, and </span><span style="color: black; "><o:p></o:p></span></div></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 7pt; font-family: Verdana, sans-serif; color: black; ">Final Specification. An OpenID Specification begins as a “draft” and retains this status until approved as an </span><span style="color: black; "><o:p></o:p></span></div></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 7pt; font-family: Verdana, sans-serif; color: black; ">Implementers Draft. An Implementers Draft may be further revised, and any revised Implementers Draft is </span><span style="color: black; "><o:p></o:p></span></div></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 7pt; font-family: Verdana, sans-serif; color: black; ">deemed a “draft” until it is approved as a new Implementers Draft. The most recent Implementers Draft </span><span style="color: black; "><o:p></o:p></span></div></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 7pt; font-family: Verdana, sans-serif; color: black; ">may be approved as a Final Specification.</span><span style="color: black; "><o:p></o:p></span></div></div></div></blockquote><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: black; "> <o:p></o:p></span></div></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: black; ">How I read this is that as we've not put out an Implementor's Draft (which has differnet IP impliciations than a Draft). This means that we still need to put out an Implementors Draft which has a 45 day review period followed by a Final Specification with a 60 day period. I'm guessing what we just did was treat a Draft like a Final Specification. Thus if I'm reading the process correctly, we must release an Implementor's Draft and then a Final Specification. :-\<o:p></o:p></span></div></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: black; "> <o:p></o:p></span></div></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: black; ">--David<o:p></o:p></span></div></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: black; "> <o:p></o:p></span></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 7pt; font-family: Verdana, sans-serif; color: black; "> </span><span style="color: black; "><o:p></o:p></span></div></div></div><div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: black; ">On Dec 18, 2008, at 7:45 AM, Mike Jones wrote:<o:p></o:p></span></div></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: black; "><br><br><br><o:p></o:p></span></div></div><div><div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">I’ve just read through these comments in detail. I agree that incorporating most of these suggestions would clarify the document. However, I also agree with Paul that these are not showstoppers; in the language of the procedures document, these are not “</span><span style="color: black; ">critical comments or objections to approval</span><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">”. The procedures also indicate that “</span><span style="color: black; ">No Substantive Change may be made to a Final Specification; any Substantive Change will require review and approval of a successor version of the applicable Final Specification according to these Processes.</span><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">” Hence, if we make any of these clarifying changes, I believe it will restart the 60 day review period.</span><span style="color: black; "><o:p></o:p></span></div></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span><span style="color: black; "><o:p></o:p></span></div></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Therefore, my recommendation is this: If any critical issues are identified during the review period that would cause us to change the draft, then we should absolutely also address Paul’s suggested clarifications. However if they are not, I believe that the community would be better served by prompt approval of the admittedly, somewhat imperfect, Draft 7 than by the creation and later approval of a Draft 8.</span><span style="color: black; "><o:p></o:p></span></div></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span><span style="color: black; "><o:p></o:p></span></div></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Do others concur with this position?</span><span style="color: black; "><o:p></o:p></span></div></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span><span style="color: black; "><o:p></o:p></span></div></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> -- Mike</span><span style="color: black; "><o:p></o:p></span></div></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span><span style="color: black; "><o:p></o:p></span></div></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">P.S. Paul, a few of your comments, such as suggested changes to protocol parameter names, would cause us to violate our charter, as we bound by the charter to maintain compatibility with Draft 2 implementations, and so these could not be accepted.</span><span style="color: black; "><o:p></o:p></span></div></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span><span style="color: black; "><o:p></o:p></span></div></div></div><div><div style="border-right-style: none; border-bottom-style: none; border-left-style: none; border-width: initial; border-color: initial; border-top-style: solid; padding-top: 3pt; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; border-width: initial; border-color: initial; border-width: initial; border-color: initial; "><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: black; ">From:</span></b><span class="apple-converted-space"><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: black; "> </span></span><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: black; "><a href="mailto:specs-pape-bounces@openid.net" style="color: blue; text-decoration: underline; ">specs-pape-bounces@openid.net</a><span class="apple-converted-space"> </span>[<a href="mailto:specs-pape-bounces@openid.net" style="color: blue; text-decoration: underline; ">mailto:specs-pape-bounces@openid.net</a>]<span class="apple-converted-space"> </span><b>On Behalf Of<span class="apple-converted-space"> </span></b>Paul Madsen<br><b>Sent:</b><span class="apple-converted-space"> </span>Friday, December 05, 2008 9:55 AM<br><b>To:</b><span class="apple-converted-space"> </span><a href="mailto:specs-pape@openid.net" style="color: blue; text-decoration: underline; ">specs-pape@openid.net</a><br><b>Subject:</b><span class="apple-converted-space"> </span>[specs-pape] Feedback on PAPE 1.0 Draft 7</span><span style="color: black; "><o:p></o:p></span></div></div></div></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: black; "> <o:p></o:p></span></div></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: black; ">Hi all, below are some comments (inline prefaced with PM ) on PAPE 1.0 Draft 7<br><br>I wouldn't characterize any as 'showstoppers'....<br><br>Thanks<br><br>Paul<br><br>--------------------------------------------------------------------------------------<br><br> OpenID Provider Auth Policy Extension October 2008<br><br><br>Abstract<br><br> This extension to the OpenID Authentication protocol provides a<br> mechanism by which a Relying Party can request that particular<br> authentication policies be applied by the OpenID Provider when<br> authenticating an End User. This extension also provides a mechanism<br> by which an OpenID Provider may inform a Relying Party which<br> authentication policies were used. Thus a Relying Party can request<br> that the End User authenticate, for example, using a phishing-<br> resistant or multi-factor authentication method.<br><br>PM: suggest adding to the end 'and the OP can then respond with the actual method' ....<br><br> This extension also provides a mechanism by which a Relying Party can<br> request that the OpenID Provider communicate the levels of<br> authentication used, as defined within one or more sets of requested<br> custom Assurance Levels, and for the OpenID Provider to communicate<br> the levels used.<br><br>PM: 'Authentication' and 'assurance' are used interchangeably. Some text<span class="apple-converted-space"> </span><br>explaining the relationship between the two would be useful.<br><br> This extension is not intended to provide all information regarding<br> the quality of an OpenID Authentication assertion. Rather, it is<br> designed to be balanced with information the Relying Party already<br> has with regard to the OpenID Provider and the level of trust it<br> places in it. If additional information is needed about processes<br> such as new End User enrollment on the OpenID Provider, such<br> information should either be transmitted out-of-band or in other<br> extensions such as OpenID Attribute Exchange. Other aspects (e.g.<br> security characteristics, credential provisioning, etc) could be<br> dealt with in the future.<br><br>PM: in fact, PAPE does indeed address other aspects like enrollment, albeit<span class="apple-converted-space"> </span><br>indirectly through the NIST levels or another framework. The relationship/differences between<span class="apple-converted-space"> </span><br>the PAPE authentication policies and the NIST assurance policies could<span class="apple-converted-space"> </span><br>be clarified.<br><br> This extension is optional, though its use is certainly recommended.<br> This extension can be used with OpenID Authentication versions 1.1<br> and 2.0.<br><br>PM: perhaps provide guidance on when the use of PAPE is appropriate?<br><br> While none of the information transmitted using this extension can be<br> verified by the Relying Party using technology alone, this does not<br> limit the utility of this extension. Because there is no trust model<br> specified by OpenID, Relying Parties must decide for themselves which<br> Providers are trustworthy; likewise, RPs can decide whether to trust<br> authentication policy claims from such OpenID Providers as well. As<br> with other OpenID extensions, it is the Relying Party's<br> responsibility to implement policy relative to the OpenID Provider's<br> response.<br><br>PM: the last seems an awkward reiteration of the previous sentences.<br><br><br><br><br><br><br><br><br>Recordon, et al. [Page 2]<br><br> OpenID Provider Auth Policy Extension October 2008<br><br><br>Table of Contents<br><br> 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4<br> 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4<br> 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4<br> 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4<br> 2. Extension Overview . . . . . . . . . . . . . . . . . . . . . . 6<br> 3. Advertising Supported Authentication Policies . . . . . . . . 7<br> 4. Defined Authentication Policies . . . . . . . . . . . . . . . 8<br> 4.1. Custom Assurance Level Name Spaces . . . . . . . . . . . . 9<br> 5. Authentication Protocol . . . . . . . . . . . . . . . . . . . 10<br> 5.1. Request Parameters . . . . . . . . . . . . . . . . . . . . 10<br> 5.2. Response Parameters . . . . . . . . . . . . . . . . . . . 11<br> 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14<br> 6.1. NIST Assurance Levels . . . . . . . . . . . . . . . . . . 14<br> Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 16<br> Appendix A.1. Authentication Method Classifications . . . . . . . 16<br> Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 20<br> 7. Normative References . . . . . . . . . . . . . . . . . . . . . 21<br> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>Recordon, et al. [Page 3]<br><br> OpenID Provider Auth Policy Extension October 2008<br><br><br>1. Definitions<br><br>1.1. Requirements Notation<br><br> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",<br> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this<br> document are to be interpreted as described in [RFC2119] .<br><br>1.2. Conventions<br><br> Throughout this document, values are quoted to indicate that they are<br> to be taken literally. When using these values in protocol messages,<br> the quotes MUST NOT be used as part of the value.<br><br> All OpenID 2.0 messages that contain a Provider Authentication Policy<br> Extension (PAPE) element MUST contain the following extension<br> namespace declaration, as specified in the Extensions section of<br> [OpenIDAuthentication2.0] .<br> openid.ns.<alias>=<a href="http://specs.openid.net/extensions/pape/1.0" style="color: blue; text-decoration: underline; ">http://specs.openid.net/extensions/pape/1.0</a><br><br> The actual extension namespace alias should be determined on a per-<br> message basis by the party composing the messages, in such a manner<br> as to avoid conflicts between multiple extensions. For the purposes<br> of this document and when constructing OpenID 1.1 messages, the<br> extension namespace alias SHALL be "pape".<br><br> Additionally, this specification uses name spaces for the custom<br> authentication level identification. It is in the form of<br> openid.pape.auth_level.ns.<cust>=<a href="http://some.authlevel.uri" style="color: blue; text-decoration: underline; ">http://some.authlevel.uri</a><br><br> The actual extension namespace alias should be determined on a per-<br> message basis by the party composing the messages, in such a manner<br> as to avoid conflicts between multiple extensions. For the purposes<br> of this document and when constructing OpenID 1.1 messages, the one<br> custom authentication level identification extension namespace<br> defined by this specification is "nist". Others may also be defined<br> and used by implementations, for example, "jisa".<br><br>1.3. Terminology<br><br> The following terms are defined in [OpenIDAuthentication2.0] :<br><br> o Identifier<br><br> o OpenID Provider (OP)<br><br> o Relying Party (RP)<br><br><br><br><br>Recordon, et al. [Page 4]<br><br> OpenID Provider Auth Policy Extension October 2008<br><br><br> o User-Agent<br><br> Authentication Method: An Authentication Method is a single<br> mechanism by which the End User authenticated to their OpenID<br> Provider, for example, a password or a hardware credential.<br><br> Authentication Policy: An Authentication Policy is a plain-text<br> description of requirements that dictate which Authentication<br> Methods can be used by an End User when authenticating to their<br> OpenID Provider. An Authentication Policy is defined by a URI<br> which must be previously agreed upon by one or more OPs and RPs.<br><br>PM: for above defn, suggest add that 'this spec defines 3 authentication policies'<br><br>PM: define 'assurance level' as well?<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>Recordon, et al. [Page 5]<br><br> OpenID Provider Auth Policy Extension October 2008<br><br><br>2. Extension Overview<br><br> 1. As part of the [Yadis] Discovery process, OpenID Providers can<br> optionally add supported authentication policies to an End User's<br> XRDS document. This aids Relying Parties in choosing between<br> multiple listed OPs depending on authentication policy<br> requirements.<br><br>PM: why constrain discovery to Yadis?<br><br> 2. The Relying Party includes parameters in the OpenID<br> Authentication request describing its preferences for<br> authentication policy for the current assertion.<br><br>PM: 'or assurance policy'<br><br> 3. The OpenID Provider processes the PAPE request, prompting the End<br> User to fulfill the requested policies during the authentication<br> process.<br><br> 4. As part of the OpenID Provider's response to the Relying Party,<br> the OP includes PAPE information around the End User's<br> authentication. An OP MAY include this response information even<br> if not requested by the RP.<br><br>PM: 'around' is awkward. Suggest 'describing'<br><br> 5. When processing the OpenID Provider's response, the Relying Party<br> takes the PAPE information into account when determining if the<br> End User should be sent through additional verification steps or<br> if the OpenID login process cannot proceed due to not meeting<br> policy requirements.<br><br>PM: suggest 'MAY take the PAPE information into account'<br><br>PM: I question the use of 'verification', as it may be interpreted as meaning<br> registration verification...<br><br>PM: 'if the OpenID login process cannot proceed due to not meeting<br> policy requirements' seems an awkward way to describe the RP choosing<span class="apple-converted-space"> </span><br>to not grant authz....<span class="apple-converted-space"> </span><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>Recordon, et al. [Page 6]<br><br> OpenID Provider Auth Policy Extension October 2008<br><br><br>3. Advertising Supported Authentication Policies<br><br> Via the use of [Yadis] within OpenID, Relying Parties are able to<br> discover OpenID Provider service information in an automated fashion.<br> This is used within OpenID Authentication for a RP to discover what<br> version of the protocol each OP listed supports as well as any<br> extensions, such as this one, that are supported. To aide in the<br> process of a Relying Party selecting which OP they wish to interact<br> with, it is STRONGLY RECOMMENDED that the following information be<br> added to the End User's XRDS document. An OP may choose to advertise<br> both custom levels and supported polices in the same <xrd:Service>.<br> An OP should only advertise the authentication policies and custom<br> assurance level namespaces that it supports.<br><br>PM: 'following information' could be made more precise, i.e. 'supported PAPE policies'.<br><br>PM: suggest tighten up to 'SHOULD/MUST only advertise the authentication policies'?<br><br> When advertising supported policies, each policy URI MUST be added as<br> the value of an <xrd:Type> element of an OpenID <xrd:Service> element<br> in an XRDS document.<br><br> Example:<br> <xrd><br> <Service><br> <Type><a href="http://specs.openid.net/auth/2.0/signon" style="color: blue; text-decoration: underline; ">http://specs.openid.net/auth/2.0/signon</a></Type><br> <Type><br> <span class="apple-converted-space"> </span><a href="http://schemas.openid.net/pape/policies/2007/06/phishing-resistant" style="color: blue; text-decoration: underline; ">http://schemas.openid.net/pape/policies/2007/06/phishing-resistant</a><br> </Type><br> <URI><a href="https://example.com/server" style="color: blue; text-decoration: underline; ">https://example.com/server</a></URI><br> </Service><br> </xrd><br><br> When advertising supported custom Assurance Level name spaces, each<br> name space URI MUST be added as the value of an <xrd:Type> element of<br> an OpenID <xrd:Service> element in an XRDS document.<br><br> Example:<br> <xrd><br> <Service><br> <Type><a href="http://specs.openid.net/auth/2.0/signon" style="color: blue; text-decoration: underline; ">http://specs.openid.net/auth/2.0/signon</a></Type><br> <Type><br> <span class="apple-converted-space"> </span><a href="http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf" style="color: blue; text-decoration: underline; ">http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf</a><br> </Type><br> <URI><a href="https://example.com/server" style="color: blue; text-decoration: underline; ">https://example.com/server</a></URI><br> </Service><br> </xrd><br><br><br><br><br><br><br><br><br>Recordon, et al. [Page 7]<br><br> OpenID Provider Auth Policy Extension October 2008<br><br><br>4. Defined Authentication Policies<br><br> The following are defined policies and policy identifiers describing<br> how the End User may authenticate to an OP. Additional policies can<br> be specified elsewhere and used without making changes to this<br> document. The policies described below are designed to be a starting<br> point to cover the most common use-cases. Additional polices can be<br> found at<span class="apple-converted-space"> </span><a href="http://schemas.openid.net/pape/policies/" style="color: blue; text-decoration: underline; ">http://schemas.openid.net/pape/policies/</a>.<br><br> When multiple policies are listed in the Relying Party's request, the<br> OpenID Provider SHOULD satisfy as many of the requested policies as<br> possible. This may require, for instance, that a user who has<br> already been authenticated using one authentication method be re-<br> authenticated with different or additional methods that satisfy the<br> request made by the Relying Party. It is always the responsibility<br> of the RP to determine whether the particular authentication<br> performed by the OP satisfied its requirements; this determination<br> may involve information contained in the PAPE response, specific<br> knowledge that the RP has about the OP, and additional information<br> that it may possess or obtain about the particular authentication<br> performed.<span class="apple-converted-space"> </span><br><br> o Phishing-Resistant Authentication<br><br><br> <span class="apple-converted-space"> </span><a href="http://schemas.openid.net/pape/policies/2007/06/phishing-resistant" style="color: blue; text-decoration: underline; ">http://schemas.openid.net/pape/policies/2007/06/phishing-resistant</a><br><br> An authentication mechanism where a party potentially under the<br> control of the Relying Party can not gain sufficient<br> information to be able to successfully authenticate to the End<br> User's OpenID Provider as if that party were the End User.<br> (Note that the potentially malicious Relying Party controls<br> where the User-Agent is redirected to and thus may not send it<br> to the End User's actual OpenID Provider).<br><br> o Multi-Factor Authentication<br><br><br> <span class="apple-converted-space"> </span><a href="http://schemas.openid.net/pape/policies/2007/06/multi-factor" style="color: blue; text-decoration: underline; ">http://schemas.openid.net/pape/policies/2007/06/multi-factor</a><br><br> An authentication mechanism where the End User authenticates to<br> the OpenID Provider by providing more than one authentication<br> factor. Common authentication factors are something you know,<br> something you have, and something you are. An example would be<br> authentication using a password and a software token or digital<br> certificate.<br><br>PM: the middle sentence feels more like belonging in a whitepaper ...<br><br><br><br>Recordon, et al. [Page 8]<br><br> OpenID Provider Auth Policy Extension October 2008<br><br><br> o Physical Multi-Factor Authentication<br><br><br> <span class="apple-converted-space"> </span><a href="http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical" style="color: blue; text-decoration: underline; ">http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical</a><br><br> An authentication mechanism where the End User authenticates to<br> the OpenID Provider by providing more than one authentication<br> factor where at least one of the factors is a physical factor<br> such as a hardware device or biometric. Common authentication<br> factors are something you know, something you have, and<br> something you are. This policy also implies the Multi-Factor<br> Authentication policy<br> (<a href="http://schemas.openid.net/pape/policies/2007/06/multi-factor" style="color: blue; text-decoration: underline; ">http://schemas.openid.net/pape/policies/2007/06/multi-factor</a>)<br> and both policies MAY BE specified in conjunction without<br> conflict. An example would be authentication using a password<br> and a hardware token.<br><br> Of the policies defined above, two are not independent. All<br> authentications satisfying the Multi-Factor Physical policy also<br> satisfy the Multi-Factor policy. Therefore, whenever the OP returns<br> a result saying that Multi-Factor Physical authentication was<br> performed it MUST also indicate that Multi-Factor authentication was<br> performed.<br><br>PM: While I understand the motivation for this, I suggest it introduces a<span class="apple-converted-space"> </span><br>dangerous precedent for dealing with dependencies between authentication policies.<span class="apple-converted-space"> </span><br><br><br>4.1. Custom Assurance Level Name Spaces<br><br> Custom Assurance Levels are optional. The namespaces may be defined<br> by various parties, such as country or industry specific standards<br> bodies, or other groups or individuals.<br><br> The namespace URI should be chosen with care to be unambiguous when<br> used as a <xrd:Type> element to advertise the namespaces supported by<br> the OP.<br><br> The custom Assurance Level namespace should define the meaning of the<br> strings that are returned by the OP in the<br> openid.pape.auth_level.<cust> element.<br><br>PM: why is 'should' not a 'MUST'? How could it be anything else?<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>Recordon, et al. [Page 9]<br><br> OpenID Provider Auth Policy Extension October 2008<br><br><br>5. Authentication Protocol<br><br>5.1. Request Parameters<br><br> The following parameters MUST be included during an OpenID<br> Authentication request [OpenIDAuthentication2.0] by the Relying Party<br> that uses this extension unless marked as optional.<br><br> o openid.ns.pape<br><br> Value:<br> <span class="apple-converted-space"> </span><a href="http://specs.openid.net/extensions/pape/1.0" style="color: blue; text-decoration: underline; ">http://specs.openid.net/extensions/pape/1.0</a><br><br> o openid.pape.max_auth_age<br><br> (Optional) If the End User has not actively authenticated to<br> the OP within the number of seconds specified in a manner<br> fitting the requested policies, the OP SHOULD authenticate the<br> End User for this request using the requested policies. The OP<br> MUST actively authenticate the user and not rely on a browser<br> cookie from a previous authentication.<br><br>PM: how can the SHOULD and MUST of the last two sentences be reconciled? By<span class="apple-converted-space"> </span><br>the OP freshly authenticating the user, but perhaps not with the requested<span class="apple-converted-space"> </span><br>policy mech?<br><br> Value: Integer value greater than or equal to zero in seconds.<br><br> If an OP does not satisfy a request for timely authentication,<br> the RP may decide not to grant the End User access to the<br> services provided by the RP. If this parameter is absent from<br> the request, the OP should authenticate the user at its own<br> discretion.<br><br>PM: the first sentence seems redundant, given the oft-stated ability of the<br> RP to do what it chooses<br><br> o openid.pape.preferred_auth_policies<br><br>PM: why is not 'preferred' used consistently on all of the request params?<br><br> Zero or more authentication policy URIs representing<br> authentication policies that the OP SHOULD satisfy when<br> authenticating the user. If multiple policies are requested,<br> the OP SHOULD satisfy as many of them as it can.<br><br> Value: Space separated list of authentication policy URIs.<br><br> If no policies are requested, the RP may be interested in other<br> information such as the authentication age.<br><br><br><br><br><br><br><br><br><br><br>Recordon, et al. [Page 10]<br><br> OpenID Provider Auth Policy Extension October 2008<br><br><br> Example:<br> openid.pape.preferred_auth_policies=<br> <span class="apple-converted-space"> </span><a href="http://schemas.openid.net/pape/policies/2007/06/phishing-resistant" style="color: blue; text-decoration: underline; ">http://schemas.openid.net/pape/policies/2007/06/phishing-resistant</a><br> <span class="apple-converted-space"> </span><a href="http://schemas.openid.net/pape/policies/2007/06/multi-factor" style="color: blue; text-decoration: underline; ">http://schemas.openid.net/pape/policies/2007/06/multi-factor</a><br><br> o openid.pape.auth_level.ns.<cust><br><br>PM: should this param not be named something like 'openid.pape.assur_level.ns.<cust>'<span class="apple-converted-space"> </span><br>in order to distinguish the assurance levels from the prior authentication URIs?<br> <span class="apple-converted-space"> </span><br><br> (Optional) The name space for the custom Assurance Level.<br> Assurance levels and their name spaces are defined by various<br> parties, such as country or industry specific standards bodies,<br> or other groups or individuals.<br><br> Value: URL that represents this Assurance Level.<br><br><br> Example:<br> openid.pape.auth_level.ns.nist=<br> <span class="apple-converted-space"> </span><a href="http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf" style="color: blue; text-decoration: underline; ">http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf</a><br> openid.pape.auth_level.ns.jisa=<br> <span class="apple-converted-space"> </span><a href="http://www.jisa.or.jp/spec/auth_level.html" style="color: blue; text-decoration: underline; ">http://www.jisa.or.jp/spec/auth_level.html</a><br><br> o openid.pape.preferred_auth_level_types<br><br>PM: likewise, suggest a name that acknowledges these are 'assurance levels'<span class="apple-converted-space"> </span><br>more so than 'authentication level' ...<br><br> (Optional) A list of the name space aliases for the custom<br> Assurance Level name spaces that the RP requests be present in<br> the response, in the order of its preference.<br><br><br>PM: Should not this param be mandatory in the request if the corresponding<span class="apple-converted-space"> </span><br>openid.pape.auth_level.ns.<cust> param is present? If omitted, how should<span class="apple-converted-space"> </span><br>the OP rank the assurance level frameworks?<br><br><br> Value: Space separated list of the name space aliases, in the<br> order of the RP's preference.<br><br> Example:<br> openid.pape.preferred_auth_levels=jisa nist<br><br>PM: the assymmetry between assurance level frameworks and authentication<span class="apple-converted-space"> </span><br>policies (i.e that an RP can indicate its preferences for the latter and<span class="apple-converted-space"> </span><br>not the former) is strange and warrants explanation/justification<br> <br><br>5.2. Response Parameters<br><br> In response to a Relying Party's request, the following parameters<br> MUST be included in the OpenID Authentication Response. All response<br> parameters MUST be included in the signature of the Authentication<br> Response. It is RECOMMENDED that an OP supporting this extension<br> include the following parameters even if not requested by the Relying<br> Party.<br><br>PM: the above seems to unduly emphasize the RP first scenario and neglect the<br> possibility of OP inititated?<span class="apple-converted-space"> </span><br><br> All response parameters MUST describe the End User's current session<br> with the OpenID Provider.<br><br><br>Recordon, et al. [Page 11]<br><br> OpenID Provider Auth Policy Extension October 2008<br><br><br> o openid.ns.pape<br><br> Value:<br> <span class="apple-converted-space"> </span><a href="http://specs.openid.net/extensions/pape/1.0" style="color: blue; text-decoration: underline; ">http://specs.openid.net/extensions/pape/1.0</a><br><br> o openid.pape.auth_policies<br><br> One or more authentication policy URIs representing policies<br> that the OP satisfied when authenticating the End User.<br><br> Value: Space separated list of authentication policy URIs.<br><br> Note: If no policies were met though the OP wishes to convey<br> other information in the response, this parameter MUST be<br> included with the value of<br> <span class="apple-converted-space"> </span><a href="http://schemas.openid.net/pape/policies/2007/06/none" style="color: blue; text-decoration: underline; ">http://schemas.openid.net/pape/policies/2007/06/none</a>.<br><br><br> Example:<br> openid.pape.auth_policies=<br> <span class="apple-converted-space"> </span><a href="http://schemas.openid.net/pape/policies/2007/06/multi-factor" style="color: blue; text-decoration: underline; ">http://schemas.openid.net/pape/policies/2007/06/multi-factor</a><br> <span class="apple-converted-space"> </span><a href="http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical" style="color: blue; text-decoration: underline; ">http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical</a><br><br> o openid.pape.auth_time<br><br> (Optional) The most recent timestamp when the End User has<br> actively authenticated to the OP in a manner fitting the<br> asserted policies.<br><br> Value: The timestamp MUST be formatted as specified in section<br> 5.6 of [RFC3339] , with the following restrictions:<br><br> + All times must be in the UTC time zone, indicated with a<br> "Z".<br><br> + No fractional seconds are allowed<br><br><br><br> Example:<br> 2005-05-15T17:11:51Z<br><br> Note: If the RP's request included the<br> "openid.pape.max_auth_age" parameter then the OP MUST include<br> "openid.pape.auth_time" in its response. If<br> "openid.pape.max_auth_age" was not requested, the OP MAY choose<br> to include "openid.pape.auth_time" in its response.<br><br><br><br>Recordon, et al. [Page 12]<br><br> OpenID Provider Auth Policy Extension October 2008<br><br><br> o openid.pape.auth_level.ns.<cust><br><br> (Optional) The name space for the custom Assurance Level<br> defined by various parties, such as a country or industry<br> specific standards body, or other groups or individuals.<br><br> Value: URL that represents this Assurance Level.<br><br><br><br> Example:<br> openid.pape.auth_level.ns.nist=<br> <span class="apple-converted-space"> </span><a href="http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf" style="color: blue; text-decoration: underline; ">http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf</a><br> openid.pape.auth_level.ns.jisa=<br> <span class="apple-converted-space"> </span><a href="http://www.jisa.or.jp/spec/auth_level.html" style="color: blue; text-decoration: underline; ">http://www.jisa.or.jp/spec/auth_level.html</a><br><br> o openid.pape.auth_level.<cust><br><br> (Optional) The Assurance Level as defined by the above<br> standards body, group, or individual that corresponds to the<br> authentication method and policies employed by the OP when<br> authenticating the End User. A custom Assurance Level<br> definition MAY define additional subparameter values that are<br> expressed within its namespace, although for reasons of<br> simplicity, this SHOULD be avoided if possible.<br><br>PM: The example below suggests that the OP MAY include multiple of these,<span class="apple-converted-space"> </span><br>one for each assurance framework. Suggest adding text in the above to make this explicit.<span class="apple-converted-space"> </span><br><br>PM: Is the OP precluded from adding multiple of these params for a single<span class="apple-converted-space"> </span><br>assurance level framework, i.e. to say nist=1 and nist=2 on the same response?<br><br> Value: Strings defined according to this Assurance Level.<br><br><br><br> Example:<br> openid.pape.auth_level.nist=1<br> openid.pape.auth_level.jisa=2<br><br><br><br><br><br><br><br><br>Recordon, et al. [Page 13]<br><br> OpenID Provider Auth Policy Extension October 2008<br><br><br>6. Security Considerations<br><br> Per commonly accepted security practices, it should be noted that the<br> overall strength of any authentication is only as strong as its<br> weakest step. It is thus recommended that provisioning of phishing-<br> resistant and other credentials stronger than shared secrets should<br> be accomplished using methods that are at least as strong as the<br> credential being provisioned. By counter-example, allowing people to<br> retrieve a phishing-resistant credential using only a phishable<br> shared secret negates much of the value provided by the phishing-<br> resistant credential itself. Similarly, sometimes using a phishing-<br> resistant method when a phishable method continues to also sometimes<br> be employed may still enable phishing attacks to compromise the<br> OpenID.<br><br>PM: the last sentence is awkward. Perhaps an example would clarify?<span class="apple-converted-space"> </span><br><br> OPs SHOULD attempt to satisfy the authentication policies requested<br> by the RP and the reply SHOULD minimally contain at least the subset<br> of the requested policies that the authentication performed<br> satisfied. The OP MAY also choose to return additional policies that<br> the authentication performed satisfied, even if not requested.<br><br>PM: how is the above a security consideration? It feels out of place<br><br> If the RP requested that an authentication level or levels be<br> returned and the OP supports some or all of those level types, then<br> the OP SHOULD return the actual level value for each of the supported<br> types requested, if available.<br><br>PM: similarly, this is not a security issue, but would seem a better fit as a<span class="apple-converted-space"> </span><br>normative rule for the openid.pape.auth_level.<cust> param of the response message<br><br><br>6.1. NIST Assurance Levels<br><br>PM: why is this section a sub-section of Security Considerations?<br><br>PM: Suggest adding some text to justify hiliting NIST above other assurance frameworks.<br><br> National Institute of Standards and Technology (NIST) in Special<br> Publication 800-63 [NIST_SP800-63] defines a set of Assurance Levels<br> from 1 to 4. These may be returned by the OP to the RP to<br> communicate which NIST level the identity proofing, authentication<br> method, and policies employed by the OP when authenticating the End<br> User corresponds to.<br><br> Value: Integer value between 0 and 4 inclusive.<br><br>PM: It seems misleading to arbitrarily append a level 0 onto the NIST range.<span class="apple-converted-space"> </span><br>Any why only for NIST? Why not JISA etc?<br><br> Note: Level 0 is not an assurance level defined by NIST, but rather<br> SHOULD be used to signify that the OP recognizes the parameter and<br> the End User authentication did not meet the requirements of Level 1.<br> See Appendix A.1.2 for high-level example classifications of<br> authentication methods within the defined levels. Authentication<br> using a long-lived browser cookie, for instance, is one example where<br> the use of "level 0" is appropriate. Authentications with level 0<br> should never be used to authorize access to any resource of any<br> monetary value whatsoever. The previous sentence should not be<br> construed as implying that any of the other levels are recommended or<br> appropriate for accessing resources with monetary value either<br><br>PM: how is 'never be used to authorize access to any resource of any<br> monetary value whatsoever' consistent with the frequent statements<span class="apple-converted-space"> </span><br>elsewhere that it is the RP's choice, non-normative text or otherwise?<br><br><br>Recordon, et al. [Page 14]<br><br> OpenID Provider Auth Policy Extension October 2008<br><br><br> without the Relying Party doing an appropriate risk assessment of the<br> particular OpenID provider asserting them and their issuance and<br> authentication procedures as they apply to the particular online<br> interaction in question.<br><br>PM: must the RP do the assessment, or could not some trusted 3rd party assessor ...?<br><br> Depending on the particular use case being satisfied by the<br> authentication response and PAPE information, the OpenID Provider<br> will have to make a decision, ideally with the consent of the End<br> User, as if it will include the "openid.pape.auth_level.nist"<br> parameter. This information is designed to give Relying Parties more<br> information around the strength of credentials used without actually<br> disclosing the specific credential type. Disclosing the specific<br> credential type can be considered a potential privacy or security<br> risk.<br><br>PM: The above warning gives the impression that for an OP to include a<span class="apple-converted-space"> </span><br>NIST level presents a greater privacy risk (and so it would be more<span class="apple-converted-space"> </span><br>appropriate to ask the user for consent) than would be the case for the<span class="apple-converted-space"> </span><br>PAPE defined authn policies? But NIST levels do not disclose specific<span class="apple-converted-space"> </span><br>credential types any more than the specific PAPE defined authn policies<br><br>PM: Could not the above be generalized into a 'Privacy Consideration' section,<span class="apple-converted-space"> </span><br>or pulled into Security Considerations?<br><br> It is RECOMMENDED that this parameter always be included in the<br> response from the OP. This holds true even in cases where the End<br> User authentication does not meet one of the defined Authentication<br> Policies. For example, if the End User is authenticating using a<br> password via HTTPS there is still value to the RP in knowing if the<br> strength of the Password corresponds to the entropy requirements laid<br> out by Level 1 or 2 or that it does not even meet the minimum<br> requirement for the lowest level. With that said, discretion needs<br> to be used by OP's as conveying that one of their End User's has a<br> weak password to an "un-trustworthy" RP would not generally be<br> considered a good idea.<o:p></o:p></span></div></div></div><div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: black; ">--<span class="apple-converted-space"> </span><br><a href="http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1" style="color: blue; text-decoration: underline; "><span style="text-decoration: none; "><image001.gif></span></a><o:p></o:p></span></div></div></div></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 9pt; font-family: Helvetica, sans-serif; color: black; ">_______________________________________________<br>specs-pape mailing list<br><a href="mailto:specs-pape@openid.net" style="color: blue; text-decoration: underline; ">specs-pape@openid.net</a><br><a href="http://openid.net/mailman/listinfo/specs-pape" style="color: blue; text-decoration: underline; ">http://openid.net/mailman/listinfo/specs-pape</a></span><span style="color: black; "><o:p></o:p></span></div></div></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="color: black; "> <o:p></o:p></span></div></div></div></div></div></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div></div></div></span></blockquote></div><br></div></body></html>