<div dir="ltr">We did consider that alternative, including the option of simply applying that logic to our own implementation. I believe that a new claim is the correct approach in this instance, for a few reasons:<div><div><br></div><div>1) the two claims are semantically different. RPs can derive use from the email_verified claim, even when they don't get a email_authoritative claim (e.g. for lower-risk actions like users subscribing to a mailing list where a 'weaker' email verification will suffice).</div><div><br></div><div>2) given the semantic difference and the fact that specs should not change, I think it's too late to redefine email_verified to mean email_authoritative. People who have already implemented email_verified in a spec compliant way will be asserting this claim on email addresses they are not authoritative for (quite validly). If half the community then adopts the new meaning, but half retain the old, RPs won't know which logic to apply to the different OPs, and thus may mistakenly believe when an OP asserts email_verified on an email address that they are authoritative when in fact they are not, which could ultimately lead to account compromise at the RP for that account.</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 10, 2015 at 10:46 PM, Mike Jones <span dir="ltr"><<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">An alternative to defining a new claim would be to further specify the semantics of the existing one such that it works for the use cases we’re interested in. 
 We should definitely discuss that alternative before adding a new standard claim definition.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">                                                          -- Mike<u></u><u></u></span></p>
<p class="MsoNormal"><a name="1518fcace713b614__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"><u></u> <u></u></span></a></p>
<span></span>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Openid-specs-ab [mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>]
<b>On Behalf Of </b>William Denniss<br>
<b>Sent:</b> Thursday, December 10, 2015 10:43 PM<br>
<b>To:</b> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
<b>Subject:</b> [Openid-specs-ab] Proposing a new 'email_authoritative' ID Token claim<u></u><u></u></span></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Hi All,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">We support the email_verified claim on our OpenID Connect endpoints today, using the
<a href="http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims" target="_blank">spec-defined</a> meaning of the claim.  However, when looking at things like
<a href="http://wdenniss.com/fastidv" target="_blank">FastIDV</a>, where ID Tokens can be used for login via a trusted OP, some weaknesses of email_verified emerge.  Specifically that there is no guarantee as to
<i>when</i> the email address was verified. This leads us to think that this probably isn't a strong enough assertion for login or account recovery. Typical email-based account recovery requires the user perform a fresh email verification – so using the email_verified
 claim from an ID Token is technically weaker than the RP actually sending the user an email.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">In many cases though, we actually host the mailbox for the email address in question, or are otherwise in an authoritative position to state that if the user were to do an email verification, it would pass. I believe that many other OPs
 would be in a similar position.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I would like to propose a new ID Token claim to be able to assert this stronger email claim, defined as such:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">email_authoritative<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<blockquote style="margin-left:30.0pt;margin-right:0in">
<div>
<p class="MsoNormal">True if the OP authoritatively represents the End-User's email address; otherwise false. When this Claim Value is true, the OP asserts that the End-User is in control of the e-mail account, and would be able to pass email verification were
 it to be performed at that moment. OPs that manage the mailbox of the e-mail address are considered authoritative, as are OPs contracted by the owner of the mailbox to provide identity services. The exact logic to determine whether the OP is authoritative
 is dependent upon the trust framework or contractual agreements within which the parties are operating.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</blockquote>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">So basically I see "email_verified" as good enough proof to allow a user to perform an action like subscribe to a mailing list without separate email verification, but only "email_authoritative" should be used for login/account recovery
 purposes. Two distinct levels of proof, for widely different use-cases.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">We also considered simply re-defining our own handling of email_verified to return a more strict response (i.e. just not asserting it for non-authoritative addresses), but I see some risks in this, for example, that other OPs will continue
 to assert email_verified on Gmail accounts (quite validly), and that RPs may get confused if we document different semantics to the spec, potentially applying our logic to other OPs.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">In order to pass the specification required basis for a new public claim, I am thinking to add this new claim to the draft FastIDV spec as it is that use-case that has sparked this requirement.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Interested to hear your thoughts on this proposal.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Best,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">William<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">PS. Thank you John Bradley for the extremely productive conversation on this topic on the sidelines of IETF94. Originally I was going to proposed email_hosted, but you made some good points that OPs may still be able to authoritatively
 represent an email address they don't host. I incorporated that feedback into this proposal.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div></div></div>
</div>

</blockquote></div><br></div>