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

George Fletcher gffletch at aol.com
Tue Feb 23 02:15:31 UTC 2016


In reading through the thread I'm trying to think through what the logic 
is for the relying party trying to use these new claims.

If the relying party is trying to determine whether it's safe to use the 
email address as an account recovery address for a new account at their 
site, then this flow helps ONLY if the email_authority is returned as 
true. If the email_authority is returned as false the RP must decide 
whether to ask the user for a different email address, send the user an 
email following the current standard email confirmation flow, or just 
ignore the possible risks and create the account anyway. If the RP asks 
the user for a different email address, then the RP will need to either 
try the flow again with this new email address (most likely needing to 
do some sort of discovery to find the IdP of this new email address) or 
send a confirmation email to the new email address.

This gets more complicated in that I can have an identity at both Google 
and AOL where the loginId is "foobar at aol.com". If the flow is starting 
from Account Chooser then the IdP MUST be pass as well and it will 
determine whether the RP gets back an "email_authority=true" or not. If 
Account Chooser has AOL as the IdP email_authority=true, where as if 
Account Chooser has Gmail as the IdP, email_authority=false.

All this has me wondering, how much we are saving the RP in complexity 
or UX flow by adding this feature.

Finally, an email used as a loginId does not necessarily mean the user 
wants that email address used as the recovery email address. In this use 
case, the RP will have to do some sort of discovery to determine where 
to send the user for fast verification of the user entered email 
address. If the RP has to do discovery anyway, can we just use standard 
OpenID Connect to verify the email?

If I'm asking questions that have already been asked and answered, 
please feel free to point me to the appropriate email threads:)

Thanks,
George

On 2/22/16 4:30 PM, Mike Jones wrote:
> Ok
> ------------------------------------------------------------------------
> From: William Denniss <mailto:wdenniss at google.com>
> Sent: ‎2/‎22/‎2016 1:27 PM
> To: Mike Jones <mailto:Michael.Jones at microsoft.com>
> Cc: Justin Richer <mailto:jricher at mit.edu>; 
> openid-specs-ab at lists.openid.net Ab 
> <mailto:openid-specs-ab at lists.openid.net>
> Subject: Re: [Openid-specs-ab] Proposing a new 'email_authoritative' 
> ID Token claim
>
> Thanks for the suggestion. Having some semblance to the semantic 
> meaning is desirable, and "valid" is not what we are asserting. I 
> think "email_authority" is pretty reasonable, only 1 more character 
> than "email_verified".
>
> I can hold off on documenting *_time.
>
>
> On Mon, Feb 22, 2016 at 1:14 PM, Mike Jones 
> <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>> wrote:
>
>     Why not email_valid?
>
>     I would like to have s privacy discussion before the "_time"
>     claims are added. Unless they're critical to your use case please
>     don't add them at this time.
>
>     -- Mike
>     ------------------------------------------------------------------------
>     From: William Denniss <mailto:wdenniss at google.com>
>     Sent: ‎2/‎22/‎2016 1:00 PM
>     To: Mike Jones <mailto:Michael.Jones at microsoft.com>
>     Cc: Justin Richer <mailto:jricher at mit.edu>;
>     openid-specs-ab at lists.openid.net Ab
>     <mailto:openid-specs-ab at lists.openid.net>
>
>     Subject: Re: [Openid-specs-ab] Proposing a new
>     'email_authoritative' ID Token claim
>
>     I am not in favor of "current" as it isn't a good match to the
>     semantic meaning we are trying to assert with email_authoritative.
>     "authority" is the shortest synonym to authoritative that retains
>     the meaning that I can think of. I'm happy to go with that instead.
>
>     I have a specification under development which I will add these to
>     https://wdenniss.com/fastidv (which has been contributed to the
>     list under IPR previously). It's relevant for this spec, as it was
>     in the context of Fast IDV that these issues have arisen.
>
>     Unless there are objections, I'll go ahead and update the spec to
>     define:
>     email_authority
>     email_verified_time
>     phone_authority
>     phone_verified_time
>
>     On Mon, Feb 22, 2016 at 12:47 PM, Mike Jones
>     <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>>
>     wrote:
>
>         Why not the shorter email_current name that was previously
>         discussed?  Size matters.
>
>         BTW, of you want these to be standard claims, you should
>         create a specification that the working group can adopt. The
>         should register the names on the IANA JWT Claims registry.
>
>         -- Mike
>         ------------------------------------------------------------------------
>         From: William Denniss <mailto:wdenniss at google.com>
>         Sent: ‎2/‎22/‎2016 12:33 PM
>         To: Justin Richer <mailto:jricher at mit.edu>
>         Cc: openid-specs-ab at lists.openid.net Ab
>         <mailto:openid-specs-ab at lists.openid.net>
>
>         Subject: Re: [Openid-specs-ab] Proposing a new
>         'email_authoritative' ID Token claim
>
>         I'm inclined to agree Justin. I think they are semantically
>         different, and both potentially useful. In the interests of
>         moving forward, I propose we add:
>
>         email_authoritative (bool)
>         email_verified_time (int timestamp)
>
>         phone_authoritative (bool)
>         phone_verified_time (int timestamp)
>
>         With the expectation that OPs would generally assert at most
>         one (authoritative trumping verified time). This allows RPs to
>         look at the authoritative relationship (which I do believe is
>         useful outside of just account recovery / "current" email
>         verification checks), and optionally consider verification
>         time as well. Example logic: "if (email_authoritative)", "if
>         (phone_authoritative || phone_verified_time < 6.months)".
>
>         If the word "authoritative" is too long, then "authority"
>         could be used as a shorter synonym.
>
>         I can add these to the OpenID Fast IDV spec with the goal to
>         make them registered JWT claims.
>
>         Regarding Google's OP implementation: for email we would only
>         implement email_authoritative, as we don't have useful
>         information to impart with verified time (accounts are only
>         verified at creation, and we don't want to leak that
>         information).  We don't currently assert phone numbers.
>         Hypothetically if we were to assert phone numbers, I could see
>         us potentially asserting phone_authoritative over "Project Fi"
>         numbers, and phone_verified_time on the rest, assuming there
>         were some re-verification events for phone numbers (which
>         would be wise, as numbers do get recycled).
>
>         On Fri, Feb 19, 2016 at 7:48 AM, Justin Richer
>         <jricher at mit.edu <mailto:jricher at mit.edu>> wrote:
>
>             I really see these as different properties.
>             “Authoritative” means “does this IdP control the
>             assignment of email addresses in this domain”. A boolean
>             flag for this is helpful, but it’s still self-asserted by
>             the IdP as much as “email_verified” is in the first place.
>             When combined with a webfinger lookup on the email domain
>             that points to the IdP you’re talking to, then maybe
>             you’ve got something that’s a bit more trustworthy, and so
>             perhaps we can provide guidance in closing the trust loop
>             in the extension spec. Even with this, the presence of
>             “authoritative: false” is more trustworthy and telling
>             than “authoritative: true” will ever be.
>
>             I agree that the age of the verification isn’t useful in a
>             practical sense, especially because once again it’s all
>             self-asserted by the IdP.
>
>              — Justin
>
>>             On Feb 17, 2016, at 1:43 AM, Adam Dawes
>>             <adawes at google.com <mailto:adawes at google.com>> wrote:
>>
>>             I get your point on reassignability is kind of the same
>>             as authoritative. Unfortunately, reassignability is a
>>             local domain policy decision and as we all know, policies
>>             can change (see yahoo.com <http://yahoo.com/>). So, I
>>             don't think you can ever expect that contract to mean
>>             anything. Similarly, we should work to support cloud
>>             identity providers (like ping, okta, 1login) which do not
>>             explicitly manage mail and reassignability but should be
>>             able to be authoritative wrt identity. And for Google, we
>>             wouldn't be able to support reassignability for our
>>             enterprise customers because address recycling is their
>>             decision. But we should still be able to be authoritative
>>             for their domain.
>>
>>             We are not big fans of passing the verified time. It
>>             leaks information about the age of the account and we
>>             have seen some interesting attacks that can be performed
>>             when the attacker has an idea of when the account was
>>             created. Plus, what's the difference when the
>>             verification was 1 month, 6 months, 2 years? The security
>>             property differences are really tough to model to the
>>             point of not being very useful.
>>
>>             On Tue, Feb 16, 2016 at 5:05 AM, Nat Sakimura
>>             <sakimura at gmail.com <mailto:sakimura at gmail.com>> wrote:
>>
>>                 Good point. Some kind of indicator on the
>>                 reassignability would be useful. It could be the
>>                 create date instead.
>>
>>                 I imagine that unauthoritative answer could be useful
>>                 as well.
>>
>>                 BTW, how would you determine that the IdP really is
>>                 authoritative on the domain? DNS TXT record perhaps?
>>                 2016 年2月13日(土) 4:21 John Bradley
>>                 <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>>:
>>
>>                     The question with authoritative is if the email
>>                     is if the email is reassignable then there is no
>>                     difference between authoritative and verified now.
>>
>>                     If the time of verification is old the client
>>                     will want to prompt the user if they want to use
>>                     that email or another one.
>>
>>                     John B.
>>
>>>                     On Feb 12, 2016, at 3:13 PM, William Denniss
>>>                     <wdenniss at google.com
>>>                     <mailto:wdenniss at google.com>> wrote:
>>>
>>>                     Picking this up again, we need to get something
>>>                     into production soon to solve this problem.
>>>
>>>                     Before we talk about representation (bool vs
>>>                     timestamp, etc), a question I have is: is there
>>>                     value in representing the difference between
>>>                     "fresh verification" and "authoritative". While
>>>                     it's true that an authoritative source could
>>>                     assert "verified just now", so could a
>>>                     non-authoritative source. Is that a problem?
>>>
>>>                     Are there any operations that you would only
>>>                     want to perform on an authoritative IDP? Take
>>>                     account recovery, would an RP accept Google
>>>                     asserting authoritative on a gmail address, but
>>>                     ignore an non-authoritative IDP who asserted
>>>                     "fresh verification" on the same address? Are
>>>                     there any other cases? If there are none, then
>>>                     asserting the time would seem to be fine.
>>>
>>>                     What are the use-cases that sit between
>>>                     "verified now" and "verified once" where knowing
>>>                     the time would actually be useful? What advice
>>>                     would you give RPs around the verification age?
>>>
>>>                     I'm still leaning towards "email_authority" as
>>>                     it is a strong claim with a clear semantic
>>>                     meaning. Maybe there is value in the more
>>>                     flexible "email_verified_time" solution, but I'm
>>>                     just not sure how that flexibility would be
>>>                     utilized beyond the "verified in the last 5min"
>>>                     check which just seems like a more complex way
>>>                     to say "authoritative=true" (and technically
>>>                     means something a different semantically as well).
>>>
>>>                     Keen to hear your thoughts.
>>>
>>>
>>>                     On Thu, Jan 7, 2016 at 11:39 AM, John Bradley
>>>                     <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>>
>>>                     wrote:
>>>
>>>                         If we are not trying to say the email will
>>>                         be immutable then why not just use verified
>>>                         time.
>>>                         Those that are authoritative would always
>>>                         return now.
>>>
>>>                         The Value could just be seconds since
>>>                         verification.
>>>
>>>                         I know there is a sensitivity about leaking
>>>                         when the account was created, but we could
>>>                         perhaps address that.
>>>                         For the ones that Google would be
>>>                         authoritative on the value would always be 0
>>>                         so at-least in the google case no more info
>>>                         would be disclosed as long as the
>>>                         verification time is not required to be
>>>                         released.
>>>
>>>                         Some IdP may want to disclose the time if
>>>                         they revalidate the email.
>>>
>>>                         John B.
>>>
>>>>                         On Jan 7, 2016, at 2:12 PM, William Denniss
>>>>                         <wdenniss at google.com
>>>>                         <mailto:wdenniss at google.com>> wrote:
>>>>
>>>>                         OK, I think I misread, that's not what we
>>>>                         were trying to do here.
>>>>
>>>>                         Let me restate: is there value in an
>>>>                         assertion stronger than "we know the user
>>>>                         controls the email", but is instead "we
>>>>                         know the user controls the email, due to
>>>>                         our relationship with the user (hosted or
>>>>                         contracted)"?
>>>>
>>>>                         I can't really think of who would actually
>>>>                         be able to assert an "email_current" claim
>>>>                         without also being authoritative, unless
>>>>                         they did a real-time email verification
>>>>                         (which at this point does it add much value
>>>>                         over the RP doing that themselves?) – at
>>>>                         least, I can't see us doing this. Given
>>>>                         that, my tendency would be to make the
>>>>                         claim stronger ("email_authority"), so it
>>>>                         could be used for other purposes we have
>>>>                         yet to think of.
>>>>
>>>>                         And if there were IDPs who did continual
>>>>                         email verification (which we for one do
>>>>                         not), then I think "email_verified_date" is
>>>>                         more useful than "email_current", as it
>>>>                         would allow for non-real time
>>>>                         re-verification as well.
>>>>
>>>>                         So what if we had:
>>>>
>>>>                         email_verified: as today
>>>>                         email_verified_time: useful for IDPs who do
>>>>                         re-verification, without requiring this be
>>>>                         in real-time
>>>>                         email_authority: for hosts & contracted
>>>>                         identity providers
>>>>
>>>>                         We don't do email re-verification, so we
>>>>                         wouldn't assert "email_verified_date"
>>>>                         ourselves, but I'm open to documenting it
>>>>                         if others feel it's useful.
>>>>
>>>>                         On Thu, Jan 7, 2016 at 11:05 AM, John
>>>>                         Bradley <ve7jtb at ve7jtb.com
>>>>                         <mailto:ve7jtb at ve7jtb.com>> wrote:
>>>>
>>>>                             Yes, on the social web a providers
>>>>                             policy can change, though nothing stops
>>>>                             a IdP from issuing separate immutable
>>>>                             email addresses for this.   If this is
>>>>                             being used for account recovery they
>>>>                             don’t need to be human friendly.
>>>>
>>>>                             Perhaps for a non reassignable (account
>>>>                             recovery) email it should be a separate
>>>>                             claim form the corrilatable friendly
>>>>                             email eg:
>>>>                             email “ve7jtb at ve7jtb.com
>>>>                             <mailto:ve7jtb at ve7jtb.com>”
>>>>
>>>>                             authoritative-email
>>>>aflhdsjhf23q238yib2b at gmail.com
>>>>                             <mailto:aflhdsjhf23q238yib2b at gmail.com>”
>>>>
>>>>                             The RP would send in the friendly email
>>>>                             for my account and the Mail Provider
>>>>                             would return a non-reassignable one
>>>>                             along with a friendly one.
>>>>                             Effectively the authoritative one is a
>>>>                             alias and could be pairwise if that was
>>>>                             the IdP policy.
>>>>
>>>>                             To truly be non reassignable you would
>>>>                             need something like that.
>>>>
>>>>
>>>>>                             On Jan 7, 2016, at 1:53 PM, Adam Dawes
>>>>>                             <adawes at google.com
>>>>>                             <mailto:adawes at google.com>> wrote:
>>>>>
>>>>>                             Reassignability is a provider policy.
>>>>>                             As you can see with Yahoo, policies
>>>>>                             can change. So, I'm not sure what good
>>>>>                             3 is.
>>>>>
>>>>>                             On Thu, Jan 7, 2016 at 10:34 AM, John
>>>>>                             Bradley <ve7jtb at ve7jtb.com
>>>>>                             <mailto:ve7jtb at ve7jtb.com>> wrote:
>>>>>
>>>>>                                 The question with 3 is the email
>>>>>                                 reassignable. If we are saying
>>>>>                                 that it is not then we should
>>>>>                                 capture that.
>>>>>
>>>>>
>>>>>>                                 On Jan 7, 2016, at 1:25 PM,
>>>>>>                                 William Denniss
>>>>>>                                 <wdenniss at google.com
>>>>>>                                 <mailto:wdenniss at google.com>> wrote:
>>>>>>
>>>>>>                                 I guess #2 is the minimum needed
>>>>>>                                 for FastIDV, but what we were
>>>>>>                                 planning to assert was definitely
>>>>>>                                 #3. I wonder if the #3 claim has
>>>>>>                                 use beyond FastIDV, and might be
>>>>>>                                 more generally useful than #2?
>>>>>>
>>>>>>                                 The problem I see with #2 is the
>>>>>>                                 UX. I don't see us launching a
>>>>>>                                 product that would do this
>>>>>>                                 checking in real time, especially
>>>>>>                                 given we are authoritative for
>>>>>>                                 such a large percentage of our users.
>>>>>>
>>>>>>                                 Perhaps the set of claims to
>>>>>>                                 represent those three levels
>>>>>>                                 could be:
>>>>>>
>>>>>>                                  1. email_verified
>>>>>>                                  2. email_verified_date  (with
>>>>>>                                     the ability to represent
>>>>>>                                     "current", as you suggested
>>>>>>                                     earlier in this thread)
>>>>>>                                  3. email_authority
>>>>>>
>>>>>>                                 I'm not proposing we actually do
>>>>>>                                 #2, but (following your earlier
>>>>>>                                 suggestion) that is probably how
>>>>>>                                 I'd represent it if we *did* have
>>>>>>                                 such a re-verification feature to
>>>>>>                                 avoid the need for constant
>>>>>>                                 re-verification. I'd be happy to
>>>>>>                                 write up #2 along with #3 if
>>>>>>                                 people think it would be useful.
>>>>>>
>>>>>>                                 On Thu, Jan 7, 2016 at 10:13 AM,
>>>>>>                                 John Bradley <ve7jtb at ve7jtb.com
>>>>>>                                 <mailto:ve7jtb at ve7jtb.com>> wrote:
>>>>>>
>>>>>>                                     Yes, I think Nick pointed out
>>>>>>                                     that a university that is
>>>>>>                                     authoritative but outsourcing
>>>>>>                                     the mail box provisioning to
>>>>>>                                     Google/Yahoo/MS would still
>>>>>>                                     want to be considered
>>>>>>                                     authoritative.
>>>>>>
>>>>>>                                     I think there are really 3
>>>>>>                                     categories for email.
>>>>>>                                     1) The user has controlled
>>>>>>                                     this identifier at some time
>>>>>>                                      (What we mean by verified)
>>>>>>                                     2) The user controls the
>>>>>>                                     email now
>>>>>>                                     3) This email is a non
>>>>>>                                     reassignable identifier for
>>>>>>                                     this user.
>>>>>>
>>>>>>                                     I think google is trying to
>>>>>>                                     say 2.   The mechanism that a
>>>>>>                                     IdP can say 2 is by being
>>>>>>                                     authoritative or checking in
>>>>>>                                     real time,  for 3 they would
>>>>>>                                     need to be authoritative.
>>>>>>
>>>>>>                                     So far I haven’t seen people
>>>>>>                                     ask for 3 outside of some
>>>>>>                                     debate in R&E:)
>>>>>>
>>>>>>                                     John B.
>>>>>>
>>>>>>>                                     On Jan 7, 2016, at 1:00 PM,
>>>>>>>                                     William Denniss
>>>>>>>                                     <wdenniss at google.com
>>>>>>>                                     <mailto:wdenniss at google.com>> 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
>>>>>>>                                     <mailto:Openid-specs-ab at lists.openid.net>
>>>>>>>                                     http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                             -- 
>>>>>                             Adam Dawes | Sr. Product
>>>>>                             Manager |adawes at google.com
>>>>>                             <mailto:adawes at google.com> |+1
>>>>>                             650-214-2410 <tel:%2B1%20650-214-2410>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>                     _______________________________________________
>>                     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
>>
>>
>>
>>
>>             -- 
>>             Adam Dawes | Sr. Product Manager |adawes at google.com
>>             <mailto:adawes at google.com> |+1 650-214-2410
>>             <tel:%2B1%20650-214-2410>
>>
>>             _______________________________________________
>>             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

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher at teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160222/caf3dd15/attachment-0001.html>


More information about the Openid-specs-ab mailing list