[Openid-specs-ab] Proposing a new 'email_authoritative' ID Token claim

William Denniss wdenniss at google.com
Mon Dec 21 20:11:37 UTC 2015


This is the proposed claim definition:

email_authoritative

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.



The risk we see with email_verified is the following: user creates an
account at Google, say janelle at acme.com. We verify the email, and return
email_verified:true forever which is valid as per spec.  The user then
loses control of the the email address (say it was recycled or maybe the
domain itself passed to a new owner). If an RP is using Fast IDV to do
login or account recovery (as we are suggesting
<https://wdenniss.com/FastIDV>), then the owner of the Google account could
potentially sign-in to accounts of the new owner of janelle at acme.com.  If
instead, the RP were to send the user an email for account recovery, only
the new owner would be able to login – so clearly there is a difference
here between the email_verified claim, and doing an email verification that
moment.

The proposal is to add "email_authoritative" as a stronger claim of
confidence on the link between the owner of the account, and the owner of
the email address. This would also rely on the existing trust framework. We
would assert this on all consumer mail we host, and also any enterprises
who contract us to provide identity services (i.e. as part of Google Apps
for Work).  In this case, if the RP were to send an email for account
recovery, the IDP is asserting that this email would go to the same user,
thus for the RP, accepting this claim (from a trusted IDP) is equivalent to
doing an email verification at that moment.

To me, email_verified is still useful for many cases like allowing users to
subscribe to a mailing list without a manual email verification, but
email_authoritative would be more appropriate for email-based login /
account recovery.

On Mon, Dec 21, 2015 at 11:32 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> Mike,  The difference is important in new account registration.
>
> There is a big difference between is this the email address for the
> account now and, has this email ever been linked to the account.
>
> We always knew that email verified would be trustable from some IdP and
> not others.
> This is not a difference of if the IdP is trusted or not, that is a trust
> framework issue agreed.
>
> But having some IdP use email verified to indicate this is the current
> email vs one that was once verified will also lead to confusion and the
> inability to express the difference.
>
> Google and others have three posable states for email  unverified,
> verified (at some date), and current (one tied to the account permanently
> like gmail)
>
> One possibility I raised was  returning the date of the email
> verification.   The downside to that is it leaks privacy information about
> when the account was created.
> A mitigation for that would be to have the IdP check on the currency of
> the email from time to time for account recovery, that way the date would
> not be tied to account establishment.
>
> I agree that having two similar things is not ideal, however having a
> overloaded meaning for one thing and no way to discover which it means is
> probably a larger problem.
>
> John B.
>
>
>
>
> On Dec 21, 2015, at 4:20 PM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:
>
> Can you post the text defining the meaning of the proposed claim to the
> last four review?
>
> This still seems redundant to me, for what it's worth. Of you go back to
> the discussions in which email_verified was defined, our was always the
> case that the exact semantics were going to be service dependant - and
> potentially also dependent on the trust framework in place between the
> parties.  I don't see any practical problem with you using the existing
> claim to meet your needs.  Can you explain the problem you perceive?
>
> Whereas having two claims with almost exactly the same meaning is almost
> certain to cause interop problems and confusion.
>
> -- Mine
> ------------------------------
> From: William Denniss <wdenniss at google.com>
> Sent: ‎12/‎21/‎2015 11:08 AM
> To: Mike Jones <Michael.Jones at microsoft.com>
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Proposing a new 'email_authoritative' ID
> Token claim
>
> Hi All,
>
> We're planning to move forward with this claim in production in the new
> year.
>
> Does anyone have any feedback on the semantic meaning, or the name? Once
> we release we can't change our production usage. So if anyone has feedback
> I'd prefer to hear it now while we can still modify things, not later when
> finalizing the spec.
>
> Regarding the specification required review for the IANA registry, my plan
> is to put it in the Fast IDV spec – this claim will be important for the
> security considerations of that spec. I see
> <https://tools.ietf.org/html/rfc7519#section-10.1> that  "Designated
> Experts may approve registration once they are satisfied that such a
> specification will be published". How far along does the spec need to be to
> satisfy that requirement?
>
> William
>
>
>
> On Thu, Dec 10, 2015 at 11:40 PM, William Denniss <wdenniss at google.com>
> wrote:
>
>> 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:
>>
>> 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).
>>
>> 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.
>>
>> On Thu, Dec 10, 2015 at 10:46 PM, Mike Jones <Michael.Jones at microsoft.com
>> > wrote:
>>
>>> 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.
>>>
>>>
>>>
>>>                                                           -- Mike
>>>
>>>
>>>
>>> *From:* Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net]
>>> *On Behalf Of *William Denniss
>>> *Sent:* Thursday, December 10, 2015 10:43 PM
>>> *To:* openid-specs-ab at lists.openid.net
>>> *Subject:* [Openid-specs-ab] Proposing a new 'email_authoritative' ID
>>> Token claim
>>>
>>>
>>>
>>> Hi All,
>>>
>>>
>>>
>>> We support the email_verified claim on our OpenID Connect endpoints
>>> today, using the spec-defined
>>> <http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims>
>>> meaning of the claim.  However, when looking at things like FastIDV
>>> <http://wdenniss.com/fastidv>, 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 *when* 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.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> I would like to propose a new ID Token claim to be able to assert this
>>> stronger email claim, defined as such:
>>>
>>>
>>>
>>> email_authoritative
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> Interested to hear your thoughts on this proposal.
>>>
>>>
>>>
>>> Best,
>>>
>>> William
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>>
>>
>>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20151221/ea7ae37e/attachment-0001.html>


More information about the Openid-specs-ab mailing list