[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.html>
More information about the Openid-specs-ab
mailing list