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

John Bradley ve7jtb at ve7jtb.com
Tue Dec 22 02:42:16 UTC 2015


The painful thing is that we need to move away from using email for account
recovery.

Long term we need to consider a federated account recovery protocol
potentially separate from SSO, for those RP that want to have local
accounts.

Even if a email is bound to an account today there is no real guarantee
that it will be tomorrow.

I see the verified flag as being good enough to subscribe the user to a
mailing list and ask them if it is still there email Y/N,  but not strong
enough for automatic account linking.

John B.
On Dec 21, 2015 8:51 PM, "William Denniss" <wdenniss at google.com> wrote:

> I agree that you would be authoritative in this scenario. The key is that
> a relationship exists between the OP and the mailbox provider to maintain
> identity consistency.
>
> This scenario definitely passes "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."
>
> Would you say that you are "managing" the mailbox, when you outsource it?
> Otherwise we can reword that line a bit. I basically put that there to
> serve as an example of the line before, perhaps I should make that fact
> more clear as well.  Does this read better? (new text emphasized)
>
> 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. *For example, *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.
>
>
>
>
> On Mon, Dec 21, 2015 at 3:01 PM, Nick Roy <nroy at internet2.edu> wrote:
>
>> What about the converse of 'as are OPs contracted by the owner of the
>> mailbox to provide identity services.'?  Example:
>>
>> I'm an OP that outsources my email to Google (a typical scenario in
>> higher education), but I maintain mail routing information about the target
>> of email aliases or outsourced mailboxes for my population within my IDMS.
>> Am I authoritative per this definition?  I think I should be.
>>
>> Best,
>>
>> Nick
>>
>> From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> on
>> behalf of William Denniss <wdenniss at google.com>
>> Date: Monday, December 21, 2015 at 1:11 PM
>> To: John Bradley <ve7jtb at ve7jtb.com>
>> Cc: "openid-specs-ab at lists.openid.net" <openid-specs-ab at lists.openid.net>
>>
>> Subject: Re: [Openid-specs-ab] Proposing a new 'email_authoritative' ID
>> Token claim
>>
>> 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/ac282dbb/attachment-0001.html>


More information about the Openid-specs-ab mailing list