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

William Denniss wdenniss at google.com
Thu Jan 7 18:13:20 UTC 2016


On Thu, Jan 7, 2016 at 10:09 AM, Hans Zandbelt <hzandbelt at pingidentity.com>
wrote:

> email_auth?


It's definitely brief! I worry that "auth" gets a bit overloaded in these
communities already though, and in this context it's not even AuthN or
AuthZ.



> On 1/7/16 1:00 PM, William Denniss wrote:
>
>> Re: "host", I took something similar to Yokohama ("email_hosted" IIRC),
>> but John pointed out that there are times when the IDP will be
>> authoritative without hosting the domain, like with an identity
>> directory. I agreed that we wanted to capture those cases too, which is
>> how we landed on the current definition, and changed the claim name to
>> "authoritative".
>>
>> Re: "current", I feel that the claim we are going for here is stronger
>> than that. Not only "We know the email address to be current", but "We
>> know the email address to be current /because/ we are in a position to
>> know this through hosting the email, or as a contracted identity
>> provider of the domain.".
>>
>> I think it would be ideal if the name had a close relationship to the
>> definition, while taking into consideration the valid size considerations.
>>
>> How about "email_authority"?  Close to the original proposal, but less
>> verbose (just 1 char more than "verified").
>>
>> On Thu, Jan 7, 2016 at 9:35 AM, Adam Dawes <adawes at google.com
>> <mailto:adawes at google.com>> wrote:
>>
>>     Email_host ?
>>
>>     -------
>>     sent from my hand phone
>>
>>     On Jan 7, 2016 1:13 AM, "Vladimir Dzhuvinov"
>>     <vladimir at connect2id.com <mailto:vladimir at connect2id.com>> wrote:
>>
>>         "email_current" is 6 chars shorter, but I wonder if there could
>>         be another somewhat better fitting synonym shorter than
>>         "email_authoritative"?
>>
>>         Is the proposed claim to be bound to the "email" scope?
>>
>>         Cheers,
>>
>>         Vladimir
>>
>>
>>         On 07/01/16 04:55, Mike Jones wrote:
>>
>>>         On 12/21/15 I wrote a note proposing at least the shorter claim
>>> name “email_current” that I haven’t seen a response to.  If you believe
>>> that you have go forward with this semantically, William, can you at least
>>> use the shorter claim name “email_current” rather than the longer
>>> “email_authoritative”.  Size still matters when claims are used in ID
>>> Tokens.
>>>
>>>
>>>  Thanks,
>>>                                                                    --
>>> Mike
>>>
>>>         From: Openid-specs-ab [mailto:
>>> openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nick Roy
>>>         Sent: Monday, January 4, 2016 3:32 PM
>>>         To: John Bradley<ve7jtb at ve7jtb.com> <mailto:ve7jtb at ve7jtb.com>;
>>> William Denniss<wdenniss at google.com> <mailto:wdenniss at google.com>
>>>         Cc:openid-specs-ab at lists.openid.net
>>>         <mailto:openid-specs-ab at lists.openid.net>
>>>         Subject: Re: [Openid-specs-ab] Proposing a new
>>> 'email_authoritative' ID Token claim
>>>
>>>         I can't post to the list directly since I havent yet signed the
>>> IPR.  I intend to do that, but I need to figure out if I can do it myself,
>>> or if Internet2 needs to do it for me.  In the meantime, William's revision
>>> looks good to me.  FWIW, any account recovery protocol that would serve for
>>> re-binding a local account at the RP to federated credentials is also
>>> necessary/likely acceptable for re-linking the identity at the RP with a
>>> different OP identity if the person so chooses.
>>>
>>>         Nick
>>>
>>>         From: John Bradley <ve7jtb at ve7jtb.com
>>>         <mailto:ve7jtb at ve7jtb.com><mailto:ve7jtb at ve7jtb.com>
>>>         <mailto:ve7jtb at ve7jtb.com>>
>>>         Date: Monday, December 21, 2015 at 7:42 PM
>>>         To: William Denniss <wdenniss at google.com
>>>         <mailto:wdenniss at google.com><mailto:wdenniss at google.com>
>>>         <mailto:wdenniss at google.com>>
>>>         Cc: "openid-specs-ab at lists.openid.net
>>>         <mailto:openid-specs-ab at lists.openid.net><mailto:
>>> openid-specs-ab at lists.openid.net>
>>>         <mailto:openid-specs-ab at lists.openid.net>" <
>>> openid-specs-ab at lists.openid.net
>>>         <mailto:openid-specs-ab at lists.openid.net><mailto:
>>> openid-specs-ab at lists.openid.net>
>>>         <mailto:openid-specs-ab at lists.openid.net>>, Nicholas Roy <
>>> nroy at internet2.edu
>>>         <mailto:nroy at internet2.edu><mailto:nroy at internet2.edu>
>>>         <mailto:nroy at internet2.edu>>
>>>         Subject: Re: [Openid-specs-ab] Proposing a new
>>> 'email_authoritative' ID Token claim
>>>
>>>
>>>         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
>>>         <mailto:wdenniss at google.com><mailto:wdenniss at google.com>
>>>         <mailto: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
>>>         <mailto:nroy at internet2.edu><mailto:nroy at internet2.edu>
>>>         <mailto: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
>>>         <mailto:openid-specs-ab-bounces at lists.openid.net><mailto:
>>> openid-specs-ab-bounces at lists.openid.net>
>>>         <mailto:openid-specs-ab-bounces at lists.openid.net>> on behalf of
>>> William Denniss <wdenniss at google.com
>>>         <mailto:wdenniss at google.com><mailto:wdenniss at google.com>
>>>         <mailto:wdenniss at google.com>>
>>>         Date: Monday, December 21, 2015 at 1:11 PM
>>>         To: John Bradley <ve7jtb at ve7jtb.com
>>>         <mailto:ve7jtb at ve7jtb.com><mailto:ve7jtb at ve7jtb.com>
>>>         <mailto:ve7jtb at ve7jtb.com>>
>>>         Cc: "openid-specs-ab at lists.openid.net
>>>         <mailto:openid-specs-ab at lists.openid.net><mailto:
>>> openid-specs-ab at lists.openid.net>
>>>         <mailto:openid-specs-ab at lists.openid.net>" <
>>> openid-specs-ab at lists.openid.net
>>>         <mailto:openid-specs-ab at lists.openid.net><mailto:
>>> openid-specs-ab at lists.openid.net>
>>>         <mailto: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, sayjanelle at acme.com
>>>         <mailto:janelle at acme.com><mailto:janelle at acme.com>
>>>         <mailto: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> <https://wdenniss.com/FastIDV>), then the
>>> owner of the Google account could potentially sign-in to accounts of the
>>> new owner ofjanelle at acme.com
>>>         <mailto:janelle at acme.com><mailto:janelle at acme.com>
>>>         <mailto:janelle at acme.com>.  If instead, the RP
>>>           were to s
>>>         end 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
>>>         <mailto:ve7jtb at ve7jtb.com><mailto:ve7jtb at ve7jtb.com>
>>>         <mailto: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
>>>         <mailto:Michael.Jones at microsoft.com><mailto:
>>> Michael.Jones at microsoft.com>
>>>         <mailto: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<mailto:wdenniss at google.com> <mailto:
>>> wdenniss at google.com>
>>>         Sent: ‎12/‎21/‎2015 11:08 AM
>>>         To: Mike Jones<mailto:Michael.Jones at microsoft.com>
>>>         <mailto:Michael.Jones at microsoft.com>
>>>         Cc:openid-specs-ab at lists.openid.net
>>>         <mailto:openid-specs-ab at lists.openid.net><mailto:
>>> openid-specs-ab at lists.openid.net>
>>>         <mailto: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>
>>>         <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
>>>         <mailto:wdenniss at google.com><mailto:wdenniss at google.com>
>>>         <mailto: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
>>>         <mailto:Michael.Jones at microsoft.com><mailto:
>>> Michael.Jones at microsoft.com>
>>>         <mailto: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<mailto:
>>> openid-specs-ab-bounces at lists.openid.net>
>>>         <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
>>>         <mailto:openid-specs-ab at lists.openid.net><mailto:
>>> openid-specs-ab at lists.openid.net>
>>>         <mailto: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>
>>>         <
>>> 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> <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
>>>         <mailto:Openid-specs-ab at lists.openid.net><mailto:
>>> Openid-specs-ab at lists.openid.net>
>>>         <mailto:Openid-specs-ab at lists.openid.net>
>>>         http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         Openid-specs-ab mailing list
>>>         Openid-specs-ab at lists.openid.net
>>>         <mailto:Openid-specs-ab at lists.openid.net>
>>>         http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>
>>         --
>>         Vladimir Dzhuvinov
>>
>>
>>         _______________________________________________
>>         Openid-specs-ab mailing list
>>         Openid-specs-ab at lists.openid.net
>>         <mailto:Openid-specs-ab at lists.openid.net>
>>         http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>>     _______________________________________________
>>     Openid-specs-ab mailing list
>>     Openid-specs-ab at lists.openid.net
>>     <mailto:Openid-specs-ab at lists.openid.net>
>>     http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
> --
> Hans Zandbelt              | Sr. Technical Architect
> hzandbelt at pingidentity.com | Ping Identity
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160107/7ec72bd5/attachment-0001.html>


More information about the Openid-specs-ab mailing list