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

William Denniss wdenniss at google.com
Fri Dec 11 06:42:53 UTC 2015


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20151210/952f9584/attachment.html>


More information about the Openid-specs-ab mailing list