<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">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.<br>
<br>
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.<br>
<br>
This gets more complicated in that I can have an identity at both
Google and AOL where the loginId is <a class="moz-txt-link-rfc2396E" href="mailto:foobar@aol.com">"foobar@aol.com"</a>. 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.<br>
<br>
All this has me wondering, how much we are saving the RP in
complexity or UX flow by adding this feature. <br>
<br>
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?<br>
<br>
If I'm asking questions that have already been asked and answered,
please feel free to point me to the appropriate email threads:)<br>
<br>
Thanks,<br>
George<br>
</font><br>
<div class="moz-cite-prefix">On 2/22/16 4:30 PM, Mike Jones wrote:<br>
</div>
<blockquote
cite="mid:BY2PR03MB4429F6F52C221D589F50C85F5A30@BY2PR03MB442.namprd03.prod.outlook.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta content="text/html; charset=utf-8">
<div>
<div style="font-family:Calibri,sans-serif; font-size:11pt">Ok</div>
</div>
<div dir="ltr">
<hr>
<span style="font-family:Calibri,sans-serif; font-size:11pt;
font-weight:bold">From:
</span><span style="font-family:Calibri,sans-serif;
font-size:11pt"><a moz-do-not-send="true"
href="mailto:wdenniss@google.com">William Denniss</a></span><br>
<span style="font-family:Calibri,sans-serif; font-size:11pt;
font-weight:bold">Sent:
</span><span style="font-family:Calibri,sans-serif;
font-size:11pt">2/22/2016 1:27 PM</span><br>
<span style="font-family:Calibri,sans-serif; font-size:11pt;
font-weight:bold">To:
</span><span style="font-family:Calibri,sans-serif;
font-size:11pt"><a moz-do-not-send="true"
href="mailto:Michael.Jones@microsoft.com">Mike Jones</a></span><br>
<span style="font-family:Calibri,sans-serif; font-size:11pt;
font-weight:bold">Cc:
</span><span style="font-family:Calibri,sans-serif;
font-size:11pt"><a moz-do-not-send="true"
href="mailto:jricher@mit.edu">Justin Richer</a>;
<a moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net
Ab</a></span><br>
<span style="font-family:Calibri,sans-serif; font-size:11pt;
font-weight:bold">Subject:
</span><span style="font-family:Calibri,sans-serif;
font-size:11pt">Re: [Openid-specs-ab] Proposing a new
'email_authoritative' ID Token claim</span><br>
<br>
</div>
<div>
<div dir="ltr">
<div>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".</div>
<div><br>
</div>
<div>I can hold off on documenting *_time.</div>
<div><br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Feb 22, 2016 at 1:14 PM,
Mike Jones <span dir="ltr">
<<a moz-do-not-send="true"
href="mailto:Michael.Jones@microsoft.com"
target="_blank">Michael.Jones@microsoft.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;
border-left:1px #ccc solid; padding-left:1ex">
<div>
<div>
<div style="font-family:Calibri,sans-serif;
font-size:11pt">Why not email_valid?<br>
<br>
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.<br>
<br>
-- Mike</div>
</div>
<div dir="ltr">
<hr>
<span style="font-family:Calibri,sans-serif;
font-size:11pt; font-weight:bold">From:
</span><span style="font-family:Calibri,sans-serif;
font-size:11pt"><a moz-do-not-send="true"
href="mailto:wdenniss@google.com"
target="_blank">William Denniss</a></span><br>
<span style="font-family:Calibri,sans-serif;
font-size:11pt; font-weight:bold">Sent:
</span><span style="font-family:Calibri,sans-serif;
font-size:11pt">2/22/2016 1:00 PM</span><br>
<span style="font-family:Calibri,sans-serif;
font-size:11pt; font-weight:bold">To:
</span><span style="font-family:Calibri,sans-serif;
font-size:11pt"><a moz-do-not-send="true"
href="mailto:Michael.Jones@microsoft.com"
target="_blank">Mike Jones</a></span><br>
<span style="font-family:Calibri,sans-serif;
font-size:11pt; font-weight:bold">Cc:
</span><span style="font-family:Calibri,sans-serif;
font-size:11pt"><a moz-do-not-send="true"
href="mailto:jricher@mit.edu" target="_blank">Justin
Richer</a>;
<a moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank">openid-specs-ab@lists.openid.net
Ab</a></span>
<div>
<div><br>
<span style="font-family:Calibri,sans-serif;
font-size:11pt; font-weight:bold">Subject:
</span><span
style="font-family:Calibri,sans-serif;
font-size:11pt">Re: [Openid-specs-ab]
Proposing a new 'email_authoritative' ID Token
claim</span><br>
<br>
</div>
</div>
</div>
<div>
<div>
<div>
<div dir="ltr">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.
<div><br>
</div>
<div>I have a specification under development
which I will add these to <a
moz-do-not-send="true"
href="https://wdenniss.com/fastidv"
target="_blank"><a class="moz-txt-link-freetext" href="https://wdenniss.com/fastidv">https://wdenniss.com/fastidv</a></a>
(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.</div>
<div><br>
</div>
<div>Unless there are objections, I'll go
ahead and update the spec to define:</div>
<div>email_authority</div>
<div>email_verified_time</div>
<div>phone_authority</div>
<div>phone_verified_time</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Feb 22, 2016
at 12:47 PM, Mike Jones <span dir="ltr">
<<a moz-do-not-send="true"
href="mailto:Michael.Jones@microsoft.com"
target="_blank">Michael.Jones@microsoft.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex; border-left:1px
#ccc solid; padding-left:1ex">
<div>
<div>
<div
style="font-family:Calibri,sans-serif;
font-size:11pt">Why not the shorter
email_current name that was
previously discussed? Size matters.<br>
<br>
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.<br>
<br>
-- Mike</div>
</div>
<div dir="ltr">
<hr>
<span
style="font-family:Calibri,sans-serif;
font-size:11pt; font-weight:bold">From:
</span><span
style="font-family:Calibri,sans-serif;
font-size:11pt"><a
moz-do-not-send="true"
href="mailto:wdenniss@google.com"
target="_blank">William Denniss</a></span><br>
<span
style="font-family:Calibri,sans-serif;
font-size:11pt; font-weight:bold">Sent:
</span><span
style="font-family:Calibri,sans-serif;
font-size:11pt">2/22/2016 12:33
PM</span><br>
<span
style="font-family:Calibri,sans-serif;
font-size:11pt; font-weight:bold">To:
</span><span
style="font-family:Calibri,sans-serif;
font-size:11pt"><a
moz-do-not-send="true"
href="mailto:jricher@mit.edu"
target="_blank">Justin Richer</a></span><br>
<span
style="font-family:Calibri,sans-serif;
font-size:11pt; font-weight:bold">Cc:
</span><span
style="font-family:Calibri,sans-serif;
font-size:11pt"><a
moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>
Ab</a></span>
<div>
<div><br>
<span
style="font-family:Calibri,sans-serif;
font-size:11pt;
font-weight:bold">Subject:
</span><span
style="font-family:Calibri,sans-serif;
font-size:11pt">Re:
[Openid-specs-ab] Proposing a
new 'email_authoritative' ID
Token claim</span><br>
<br>
</div>
</div>
</div>
<div>
<div>
<div>
<div dir="ltr">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:
<div><br>
</div>
<div>email_authoritative (bool)</div>
<div>email_verified_time (int
timestamp)</div>
<div><br>
</div>
<div>phone_authoritative (bool)</div>
<div>phone_verified_time (int
timestamp)</div>
<div><br>
</div>
<div>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)".</div>
<div><br>
</div>
<div>If the word "authoritative"
is too long, then "authority"
could be used as a shorter
synonym.</div>
<div><br>
</div>
<div>I can add these to the
OpenID Fast IDV spec with the
goal to make them registered
JWT claims.</div>
<div><br>
</div>
<div>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).</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On
Fri, Feb 19, 2016 at 7:48
AM, Justin Richer <span
dir="ltr">
<<a
moz-do-not-send="true"
href="mailto:jricher@mit.edu"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:jricher@mit.edu">jricher@mit.edu</a></a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0 0 0 .8ex;
border-left:1px #ccc
solid; padding-left:1ex">
<div
style="word-wrap:break-word">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.
<div><br>
</div>
<div>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. </div>
<span><font
color="#888888">
<div><br>
</div>
<div> — Justin</div>
</font></span>
<div>
<div>
<div><br>
<div>
<blockquote
type="cite">
<div>On Feb
17, 2016, at
1:43 AM, Adam
Dawes <<a
moz-do-not-send="true"
href="mailto:adawes@google.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:adawes@google.com">adawes@google.com</a></a>>
wrote:</div>
<br>
<div>
<div dir="ltr">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
<a
moz-do-not-send="true"
href="http://yahoo.com/" target="_blank">yahoo.com</a>). 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.
<div><br>
</div>
<div>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. <br>
<div
class="gmail_extra"><br>
<div
class="gmail_quote">On
Tue, Feb 16,
2016 at 5:05
AM, Nat
Sakimura <span
dir="ltr">
<<a
moz-do-not-send="true"
href="mailto:sakimura@gmail.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:sakimura@gmail.com">sakimura@gmail.com</a></a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0
0 0 .8ex;
border-left:1px
#ccc solid;
padding-left:1ex">
Good point.
Some kind of
indicator on
the
reassignability
would be
useful. It
could be the
create date
instead.
<br>
<br>
I imagine that
unauthoritative
answer could
be useful as
well. <br>
<br>
BTW, how would
you determine
that the IdP
really is
authoritative
on the domain?
DNS TXT record
perhaps?
<br>
<div
class="gmail_quote">
<div dir="ltr">2016
年2月13日(土) 4:21
John Bradley
<<a
moz-do-not-send="true"
href="mailto:ve7jtb@ve7jtb.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a></a>>:<br>
</div>
<div>
<div>
<blockquote
class="gmail_quote"
style="margin:0
0 0 .8ex;
border-left:1px
#ccc solid;
padding-left:1ex">
<div
style="word-wrap:break-word">The
question with
authoritative
is if the
email is if
the email is
reassignable
then there is
no difference
between
authoritative
and verified
now.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>John B.</div>
</div>
<div
style="word-wrap:break-word">
<div><br>
<div>
<blockquote
type="cite">
<div>On Feb
12, 2016, at
3:13 PM,
William
Denniss <<a
moz-do-not-send="true" href="mailto:wdenniss@google.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:wdenniss@google.com">wdenniss@google.com</a></a>>
wrote:</div>
<br>
<div>
<div dir="ltr">
<div>Picking
this up again,
we need to get
something into
production
soon to solve
this problem.</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
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.
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>Keen to
hear your
thoughts.</div>
<div><br>
</div>
<div>
<div
class="gmail_extra"><br>
<div
class="gmail_quote">On
Thu, Jan 7,
2016 at 11:39
AM, John
Bradley <span
dir="ltr">
<<a
moz-do-not-send="true"
href="mailto:ve7jtb@ve7jtb.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a></a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0px
0px 0px 0.8ex;
border-left-width:1px;
border-left-color:rgb(204,204,204);
border-left-style:solid;
padding-left:1ex">
<div
style="word-wrap:break-word">If
we are not
trying to say
the email will
be immutable
then why not
just use
verified time.
<div>Those
that are
authoritative
would always
return now. </div>
<div><br>
</div>
<div>The Value
could just be
seconds since
verification.
</div>
<div><br>
</div>
<div>I know
there is a
sensitivity
about leaking
when the
account was
created, but
we could
perhaps
address that.</div>
<div>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.</div>
<div><br>
</div>
<div>Some IdP
may want to
disclose the
time if they
revalidate the
email.</div>
<div><br>
</div>
<div>John B.</div>
<div>
<div>
<div><br>
</div>
<div>
<div>
<blockquote
type="cite">
<div>On Jan 7,
2016, at 2:12
PM, William
Denniss <<a
moz-do-not-send="true" href="mailto:wdenniss@google.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:wdenniss@google.com">wdenniss@google.com</a></a>>
wrote:</div>
<br>
<div>
<div dir="ltr">
<div>OK, I
think I
misread,
that's not
what we were
trying to do
here.</div>
<div><br>
</div>
<div>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)"?</div>
<div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>So what
if we had:</div>
<div><br>
</div>
<div>email_verified:
as today</div>
<div>email_verified_time:
useful for
IDPs who do
re-verification,
without
requiring this
be in
real-time</div>
<div>email_authority:
for hosts
&
contracted
identity
providers</div>
<div><br>
</div>
<div>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.</div>
<div>
</div>
</div>
</div>
<div
class="gmail_extra"><br>
<div
class="gmail_quote">On
Thu, Jan 7,
2016 at 11:05
AM, John
Bradley <span
dir="ltr">
<<a
moz-do-not-send="true"
href="mailto:ve7jtb@ve7jtb.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a></a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0px
0px 0px 0.8ex;
border-left-width:1px;
border-left-color:rgb(204,204,204);
border-left-style:solid;
padding-left:1ex">
<div
style="word-wrap:break-word">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.
<div><br>
</div>
<div>Perhaps
for a non
reassignable
(account
recovery)
email it
should be a
separate claim
form the
corrilatable
friendly email
eg:</div>
<div>email “<a
moz-do-not-send="true" href="mailto:ve7jtb@ve7jtb.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a></a>”</div>
<div><br>
</div>
<div>authoritative-email
“<a
moz-do-not-send="true"
href="mailto:aflhdsjhf23q238yib2b@gmail.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:aflhdsjhf23q238yib2b@gmail.com">aflhdsjhf23q238yib2b@gmail.com</a></a>” </div>
<div><br>
</div>
<div>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. </div>
<div>Effectively
the
authoritative
one is a alias
and could be
pairwise if
that was the
IdP policy.</div>
<div><br>
</div>
<div>To truly
be non
reassignable
you would need
something like
that.
<div>
<div><br>
<div><br>
</div>
<div>
<div>
<blockquote
type="cite">
<div>On Jan 7,
2016, at 1:53
PM, Adam Dawes
<<a
moz-do-not-send="true"
href="mailto:adawes@google.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:adawes@google.com">adawes@google.com</a></a>>
wrote:</div>
<br>
<div>
<div dir="ltr">Reassignability
is a provider
policy. As you
can see with
Yahoo,
policies can
change. So,
I'm not sure
what good 3
is.</div>
<div
class="gmail_extra"><br>
<div
class="gmail_quote">On
Thu, Jan 7,
2016 at 10:34
AM, John
Bradley <span
dir="ltr">
<<a
moz-do-not-send="true"
href="mailto:ve7jtb@ve7jtb.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a></a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0px
0px 0px 0.8ex;
border-left-width:1px;
border-left-color:rgb(204,204,204);
border-left-style:solid;
padding-left:1ex">
<div
style="word-wrap:break-word">The
question with
3 is the email
reassignable.
If we are
saying that it
is not then we
should capture
that.
<div>
<div>
<div><br>
</div>
<div><br>
<div>
<blockquote
type="cite">
<div>On Jan 7,
2016, at 1:25
PM, William
Denniss <<a
moz-do-not-send="true" href="mailto:wdenniss@google.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:wdenniss@google.com">wdenniss@google.com</a></a>>
wrote:</div>
<br>
<div>
<div dir="ltr">
<div>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?</div>
<div><br>
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.</div>
<div><br>
</div>
<div>Perhaps
the set of
claims to
represent
those three
levels could
be:</div>
<div>
<ol>
<li>email_verified</li>
<li>email_verified_date
(with the
ability to
represent
"current", as
you suggested
earlier in
this thread)</li>
<li>email_authority</li>
</ol>
<div>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.</div>
</div>
</div>
<div
class="gmail_extra"><br>
<div
class="gmail_quote">On
Thu, Jan 7,
2016 at 10:13
AM, John
Bradley <span
dir="ltr">
<<a
moz-do-not-send="true"
href="mailto:ve7jtb@ve7jtb.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a></a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0px
0px 0px 0.8ex;
border-left-width:1px;
border-left-color:rgb(204,204,204);
border-left-style:solid;
padding-left:1ex">
<div
style="word-wrap:break-word">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.
<div><br>
</div>
<div>I think
there are
really 3
categories for
email. </div>
<div>1) The
user has
controlled
this
identifier at
some time
(What we mean
by verified)</div>
<div>2) The
user controls
the email now </div>
<div>3) This
email is a non
reassignable
identifier for
this user.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>So far I
haven’t seen
people ask for
3 outside of
some debate in
R&E:)</div>
<div><br>
</div>
<div>John B.</div>
<div>
<div>
<div><br>
<div>
<blockquote
type="cite">
<div>On Jan 7,
2016, at 1:00
PM, William
Denniss <<a
moz-do-not-send="true" href="mailto:wdenniss@google.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:wdenniss@google.com">wdenniss@google.com</a></a>>
wrote:</div>
<br>
<div>
<div dir="ltr">
<div>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".<br>
</div>
<div><br>
</div>
<div>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
<i>because</i>
we are in a
position to
know this
through
hosting the
email, or as a
contracted
identity
provider of
the domain.".</div>
<div><br>
</div>
<div>I think
it would be
ideal if the
name had a
close
relationship
to the
definition,
while taking
into
consideration
the valid size
considerations.</div>
<div><br>
</div>
<div>How about
"email_authority"?
Close to the
original
proposal, but
less verbose
(just 1 char
more than
"verified").</div>
</div>
<div
class="gmail_extra"><br>
<div
class="gmail_quote">On
Thu, Jan 7,
2016 at 9:35
AM, Adam Dawes
<span
dir="ltr">
<<a
moz-do-not-send="true"
href="mailto:adawes@google.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:adawes@google.com">adawes@google.com</a></a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0px
0px 0px 0.8ex;
border-left-width:1px;
border-left-color:rgb(204,204,204);
border-left-style:solid;
padding-left:1ex">
<p dir="ltr">Email_host
?</p>
<p dir="ltr">-------<br>
sent from my
hand phone</p>
<div>
<div>
<div
class="gmail_quote">On
Jan 7, 2016
1:13 AM,
"Vladimir
Dzhuvinov"
<<a
moz-do-not-send="true"
href="mailto:vladimir@connect2id.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:vladimir@connect2id.com">vladimir@connect2id.com</a></a>>
wrote:<br
type="attribution">
<blockquote
class="gmail_quote"
style="margin:0px
0px 0px 0.8ex;
border-left-width:1px;
border-left-color:rgb(204,204,204);
border-left-style:solid;
padding-left:1ex">
<div
bgcolor="#FFFFFF">"email_current"
is 6 chars
shorter, but I
wonder if
there could be
another
somewhat
better fitting
synonym
shorter than
"email_authoritative"?<br>
<br>
Is the
proposed claim
to be bound to
the "email"
scope?<br>
<br>
Cheers,<br>
<br>
Vladimir<br>
<br>
<br>
<div>On
07/01/16
04:55, Mike
Jones wrote:<br>
</div>
<blockquote
type="cite">
<pre>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 [<a moz-do-not-send="true" href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">mailto:openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of Nick Roy
Sent: Monday, January 4, 2016 3:32 PM
To: John Bradley <a moz-do-not-send="true" href="mailto:ve7jtb@ve7jtb.com" target="_blank"><ve7jtb@ve7jtb.com></a>; William Denniss <a moz-do-not-send="true" href="mailto:wdenniss@google.com" target="_blank"><wdenniss@google.com></a>
Cc: <a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>
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 <<a moz-do-not-send="true" href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a><a moz-do-not-send="true" href="mailto:ve7jtb@ve7jtb.com" target="_blank"><mailto:ve7jtb@ve7jtb.com></a>>
Date: Monday, December 21, 2015 at 7:42 PM
To: William Denniss <<a moz-do-not-send="true" href="mailto:wdenniss@google.com" target="_blank">wdenniss@google.com</a><a moz-do-not-send="true" href="mailto:wdenniss@google.com" target="_blank"><mailto:wdenniss@google.com></a>>
Cc: "<a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank"><mailto:openid-specs-ab@lists.openid.net></a>" <<a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank"><mailto:openid-specs-ab@lists.openid.net></a>>, Nicholas Roy <<a moz-do-not-send="true" href="mailto:nroy@internet2.edu" target="_blank">nroy@internet2.edu</a><a moz-do-not-send="true" href="mailto:nroy@internet2.edu" target="_blank"><mailto:nroy@internet2.edu></a>>
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" <<a moz-do-not-send="true" href="mailto:wdenniss@google.com" target="_blank">wdenniss@google.com</a><a moz-do-not-send="true" href="mailto:wdenniss@google.com" target="_blank"><mailto:wdenniss@google.com></a>> 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 <<a moz-do-not-send="true" href="mailto:nroy@internet2.edu" target="_blank">nroy@internet2.edu</a><a moz-do-not-send="true" href="mailto:nroy@internet2.edu" target="_blank"><mailto:nroy@internet2.edu></a>> 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 <<a moz-do-not-send="true" href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a><a moz-do-not-send="true" href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank"><mailto:openid-specs-ab-bounces@lists.openid.net></a>> on behalf of William Denniss <<a moz-do-not-send="true" href="mailto:wdenniss@google.com" target="_blank">wdenniss@google.com</a><a moz-do-not-send="true" href="mailto:wdenniss@google.com" target="_blank"><mailto:wdenniss@google.com></a>>
Date: Monday, December 21, 2015 at 1:11 PM
To: John Bradley <<a moz-do-not-send="true" href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a><a moz-do-not-send="true" href="mailto:ve7jtb@ve7jtb.com" target="_blank"><mailto:ve7jtb@ve7jtb.com></a>>
Cc: "<a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank"><mailto:openid-specs-ab@lists.openid.net></a>" <<a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank"><mailto:openid-specs-ab@lists.openid.net></a>>
Subject: Re: [Openid-specs-ab] Proposing a new 'email_authoritative' ID Token claim
This is the proposed claim definition:
email_authoritative
True if the OP authoritatively represents the End-User's email address; otherwise false. When this Claim Value is true, the OP asserts that the End-User is in control of the e-mail account, and would be able to pass email verification were it to be performed at that moment. OPs that manage the mailbox of the e-mail address are considered authoritative, as are OPs contracted by the owner of the mailbox to provide identity services. The exact logic to determine whether the OP is authoritative is dependent upon the trust framework or contractual agreements within which the parties are operating.
The risk we see with email_verified is the following: user creates an account at Google, say <a moz-do-not-send="true" href="mailto:janelle@acme.com" target="_blank">janelle@acme.com</a><a moz-do-not-send="true" href="mailto:janelle@acme.com" target="_blank"><mailto:janelle@acme.com></a>. 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<a moz-do-not-send="true" href="https://wdenniss.com/FastIDV" target="_blank"><https://wdenniss.com/FastIDV></a>), then the owner of the Google account could potentially sign-in to accounts of the new owner of <a moz-do-not-send="true" href="mailto:janelle@acme.com" target="_blank">janelle@acme.com</a><a moz-do-not-send="true" href="mailto:janelle@acme.com" target="_blank"><mailto:janelle
@acme.com
></a>. 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 <<a moz-do-not-send="true" href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a><a moz-do-not-send="true" href="mailto:ve7jtb@ve7jtb.com" target="_blank"><mailto:ve7jtb@ve7jtb.com></a>> 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 <<a moz-do-not-send="true" href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a><a moz-do-not-send="true" href="mailto:Michael.Jones@microsoft.com" target="_blank"><mailto:Michael.Jones@microsoft.com></a>> 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<a moz-do-not-send="true" href="mailto:wdenniss@google.com" target="_blank"><mailto:wdenniss@google.com></a>
Sent: 12/21/2015 11:08 AM
To: Mike Jones<a moz-do-not-send="true" href="mailto:Michael.Jones@microsoft.com" target="_blank"><mailto:Michael.Jones@microsoft.com></a>
Cc: <a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank"><mailto:openid-specs-ab@lists.openid.net></a>
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<a moz-do-not-send="true" href="https://tools.ietf.org/html/rfc7519#section-10.1" target="_blank"><https://tools.ietf.org/html/rfc7519#section-10.1></a> 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 <<a moz-do-not-send="true" href="mailto:wdenniss@google.com" target="_blank">wdenniss@google.com</a><a moz-do-not-send="true" href="mailto:wdenniss@google.com" target="_blank"><mailto:wdenniss@google.com></a>> 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 <<a moz-do-not-send="true" href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a><a moz-do-not-send="true" href="mailto:Michael.Jones@microsoft.com" target="_blank"><mailto:Michael.Jones@microsoft.com></a>> 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 [<a moz-do-not-send="true" href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">mailto:openid-specs-ab-bounces@lists.openid.net</a><a moz-do-not-send="true" href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank"><mailto:openid-specs-ab-bounces@lists.openid.net></a>] On Behalf Of William Denniss
Sent: Thursday, December 10, 2015 10:43 PM
To: <a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><a moz-do-not-send="true" href="mailto:openid-specs-ab@lists.openid.net" target="_blank"><mailto:openid-specs-ab@lists.openid.net></a>
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<a moz-do-not-send="true" href="http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims" target="_blank"><http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims></a> meaning of the claim. However, when looking at things like FastIDV<a moz-do-not-send="true" href="http://wdenniss.com/fastidv" target="_blank"><http://wdenniss.com/fastidv></a>, 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
<a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank"><mailto:Openid-specs-ab@lists.openid.net></a>
<a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Openid-specs-ab mailing list
<a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
<pre cols="72">--
Vladimir Dzhuvinov</pre>
</div>
<br>
_______________________________________________<br>
Openid-specs-ab
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></a><br>
<a
moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
rel="noreferrer"
target="_blank"><a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></a><br>
<br>
</blockquote>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Openid-specs-ab
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></a><br>
<a
moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
rel="noreferrer"
target="_blank"><a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></a><br>
<br>
</blockquote>
</div>
<br>
</div>
_______________________________________________<br>
Openid-specs-ab
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></a><br>
<a
moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
target="_blank"><a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br
clear="all">
<div><br>
</div>
-- <br>
<div>
<div dir="ltr">
<div
style="line-height:1.5em;
padding-top:10px;
margin-top:10px;
color:rgb(85,85,85);
font-family:sans-serif;
font-size:small">
<span
style="border-width:2px
0px 0px;
border-style:solid;
border-color:rgb(213,15,37);
padding-top:2px;
margin-top:2px">Adam Dawes |</span><span style="border-width:2px 0px
0px;
border-style:solid;
border-color:rgb(51,105,232);
padding-top:2px;
margin-top:2px"> Sr. Product Manager |</span><span
style="border-width:2px
0px 0px;
border-style:solid;
border-color:rgb(0,153,57);
padding-top:2px;
margin-top:2px"> <a moz-do-not-send="true"
href="mailto:adawes@google.com"
target="_blank">adawes@google.com</a> |</span><span
style="border-width:2px
0px 0px;
border-style:solid;
border-color:rgb(238,178,17);
padding-top:2px;
margin-top:2px"> <a moz-do-not-send="true"
href="tel:%2B1%20650-214-2410"
value="+16502142410" target="_blank">+1 650-214-2410</a></span></div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
_______________________________________________<br>
Openid-specs-ab
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></a><br>
<a
moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
rel="noreferrer"
target="_blank"><a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></a><br>
</blockquote>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Openid-specs-ab
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></a><br>
<a
moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
rel="noreferrer"
target="_blank"><a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></a><br>
<br>
</blockquote>
</div>
<br>
<br
clear="all">
<div><br>
</div>
-- <br>
<div>
<div dir="ltr">
<div
style="line-height:1.5em;
padding-top:10px;
margin-top:10px;
color:rgb(85,85,85);
font-family:sans-serif;
font-size:small">
<span
style="border-width:2px
0px 0px;
border-style:solid;
border-color:rgb(213,15,37);
padding-top:2px;
margin-top:2px">Adam Dawes |</span><span style="border-width:2px 0px
0px;
border-style:solid;
border-color:rgb(51,105,232);
padding-top:2px;
margin-top:2px"> Sr. Product Manager |</span><span
style="border-width:2px
0px 0px;
border-style:solid;
border-color:rgb(0,153,57);
padding-top:2px;
margin-top:2px"> <a moz-do-not-send="true"
href="mailto:adawes@google.com"
target="_blank">adawes@google.com</a> |</span><span
style="border-width:2px
0px 0px;
border-style:solid;
border-color:rgb(238,178,17);
padding-top:2px;
margin-top:2px"> <a moz-do-not-send="true"
href="tel:%2B1%20650-214-2410"
value="+16502142410" target="_blank">+1 650-214-2410</a></span></div>
<br>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br>
Openid-specs-ab
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></a><br>
<a
moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
target="_blank"><a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Openid-specs-ab mailing
list<br>
<a moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
rel="noreferrer"
target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Chief Architect
Identity Services Engineering Work: <a class="moz-txt-link-abbreviated" href="mailto:george.fletcher@teamaol.com">george.fletcher@teamaol.com</a>
AOL Inc. AIM: gffletch
Mobile: +1-703-462-3494 Twitter: <a class="moz-txt-link-freetext" href="http://twitter.com/gffletch">http://twitter.com/gffletch</a>
Office: +1-703-265-2544 Photos: <a class="moz-txt-link-freetext" href="http://georgefletcher.photography">http://georgefletcher.photography</a>
</pre>
</body>
</html>