<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Oh, I see. So It's possible that AccountChooser does the server
resolution even when this server was never known before by the
authorization client? Because you wrote</p>
<br>
> AccountChooser presents the list of IdPs that the user has used
against the domain and let her chose it<br>
<br>
<p>And I understood that like I have to discover the IdP in advance.</p>
<p>I think you understood my use case correctly.<br>
</p>
<p>Well, the problem with the solution you propose (with
AccountChooser) is that I have to implement some
discovery-specific support on the diaspora site. The way the
custom protocol handlers work, the authorization client can
redirect to the custom protocol address from the login page (e.g.
the AccountChooser). And in order to use this to resolve the
remote host (diaspora) the IdP has to redirect it back to the
original service. So when I redirect to
"web+diaspora://authenticate" from the AccountChooser in order to
resolve the target host I'll have to redirect back from diaspora
to the URL of the authorization client with the host name in the
request parameters. And only after that I can do the OIDC
authorization flow. <br>
</p>
<p>Besides the fact that this way I'll have two redirect-callback
rounds between the same two services, it also has some privacy
issues, because implementing an endpoint which unconditionally
redirects back and telling your diaspora server host name can be
used to identify the host name even when user doesn't want it.
This issue can be solved by asking the user at the diaspora site
something like "Do you want to tell example.com your host name?"
but this would also mean that the user will be asked twice: once
for the host name and second time for the OIDC authorization
permission which is a terrible UX.</p>
<p>That's why I looked at the "implicit registration flow" which
actually combines this two things into one redirect-callback
round: it redirects to the custom protocol URL and then goes back
to the authorization client with the authorization response. If
the user refused the authorization we can redirect without telling
the hostname which solve the privacy concern.</p>
<p>Thanks for the detailed response, though!<br>
</p>
<div class="moz-cite-prefix">25.12.2018 10:13, n-sakimura пишет:<br>
</div>
<blockquote type="cite"
cite="mid:OSBPR01MB2869529313113860C823EA93F9B40@OSBPR01MB2869.jpnprd01.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"ＭＳ ゴシック";
panose-1:2 11 6 9 7 2 5 8 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@ＭＳ ゴシック";
panose-1:2 11 6 9 7 2 5 8 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
span.19
{mso-style-type:personal;
font-family:"Arial",sans-serif;
color:windowtext;}
span.20
{mso-style-type:personal-reply;
font-family:"Arial",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:99.25pt 3.0cm 3.0cm 3.0cm;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:714425180;
mso-list-type:hybrid;
mso-list-template-ids:-1188901486 1956534454 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;
mso-fareast-font-family:"ＭＳ ゴシック";
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:1248731252;
mso-list-type:hybrid;
mso-list-template-ids:2070153668 1956534454 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;
mso-fareast-font-family:"ＭＳ ゴシック";
mso-bidi-font-family:"Times New Roman";}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">Hmmm.
Then I am not understanding your use-case properly.
<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">What
I understood was as follows:
<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoListParagraph"
style="color:windowtext;margin-left:0cm;mso-list:l0 level1
lfo1">
<span style="font-family:"Arial",sans-serif">There
is a diaspora user who wants to login to a service.
<o:p></o:p></span></li>
<li class="MsoListParagraph"
style="color:windowtext;margin-left:0cm;mso-list:l0 level1
lfo1">
<span style="font-family:"Arial",sans-serif">However,
diaspora being distributed, there has to be a way to find
out which server the user is using.
<o:p></o:p></span></li>
</ul>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">So,
that is the objective, right?
<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">Your
proposed solution to it is to<o:p></o:p></span></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoListParagraph"
style="color:windowtext;margin-left:0cm;mso-list:l1 level1
lfo2">
<span style="font-family:"Arial",sans-serif">Utilize
a custom protocol handler so that the user can be
redirected to the service.
<o:p></o:p></span></li>
</ul>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">Is
this correct?
<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">If
so, my next question is why does it not suffice for the site
to find out the diaspora server URL using AccountChoser?
Once the client gets the address of the diaspora server, it
can register itself to it and start the standard OpenID
Connect flow. What is the reason that this does not work?
<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">Cheers,
<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">Nat
Sakimura<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="color:windowtext">From:</span></b><span
style="color:windowtext"> senya <a class="moz-txt-link-rfc2396E" href="mailto:senya@riseup.net"><senya@riseup.net></a>
<br>
<b>Sent:</b> Tuesday, December 25, 2018 4:12 PM<br>
<b>To:</b> n-sakimura <a class="moz-txt-link-rfc2396E" href="mailto:n-sakimura@nri.co.jp"><n-sakimura@nri.co.jp></a>; Nat
Sakimura <a class="moz-txt-link-rfc2396E" href="mailto:sakimura@gmail.com"><sakimura@gmail.com></a><br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:openid-specs@lists.openid.net">openid-specs@lists.openid.net</a><br>
<b>Subject:</b> Re: OpenID Connect with custom protocol
handlers in browser<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>Yeah, but that's not what I want.<o:p></o:p></p>
<div>
<p class="MsoNormal">25.12.2018 9:06, n-sakimura пишет:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">AccountChooser
presents the list of IdPs that the user has used against
the domain and let her chose it.
</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">Then,
the client receives the IdP that the user has selected so
that the normal federated login can be done.
</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">Cheers,
</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext">Nat</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:windowtext"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="color:windowtext">From:</span></b><span
style="color:windowtext"> specs
<a href="mailto:openid-specs-bounces@lists.openid.net"
moz-do-not-send="true"><openid-specs-bounces@lists.openid.net></a>
<b>On Behalf Of </b>senya<br>
<b>Sent:</b> Tuesday, December 25, 2018 3:44 PM<br>
<b>To:</b> Nat Sakimura <a
href="mailto:sakimura@gmail.com"
moz-do-not-send="true"><sakimura@gmail.com></a><br>
<b>Cc:</b> <a
href="mailto:openid-specs@lists.openid.net"
moz-do-not-send="true">openid-specs@lists.openid.net</a><br>
<b>Subject:</b> Re: OpenID Connect with custom
protocol handlers in browser</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p>Hello, Nat.<o:p></o:p></p>
<p>Thanks for the link, but however I can't see how it
overlaps with my use case. AccountChooser / OpenYOLO seem to
describe something like credential managers, while I want to
implement sign in with an authentication provider. It's like
"Sign in with Facebook", but with diaspora* social network
instead. The only difference is that diaspora* social
network is federated, therefore there is no single entry
point like "facebook.com" to send authentication request.
This is the problem that I'm trying to solve. I can't see
how the specifications you've referenced can help, but maybe
I'm just missing something?<o:p></o:p></p>
<div>
<p class="MsoNormal">24.12.2018 4:49, Nat Sakimura пишет:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Arial",sans-serif;background:white">TL;DR
but your usecase seems to somewhat overlap with
AccountChooser / OpenYOLO. Have you checked them? </span>
<o:p></o:p></p>
<div>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Arial",sans-serif;background:white"><br>
<br>
<br>
</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Arial",sans-serif;background:white"><a
href="https://openid.net/wg/ac/"
moz-do-not-send="true">https://openid.net/wg/ac/</a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Arial",sans-serif;background:white">Cheers, </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Arial",sans-serif;background:white">Nat </span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">2018<span
style="font-family:"ＭＳ ゴシック",serif"
lang="JA">年</span>12<span
style="font-family:"ＭＳ ゴシック",serif"
lang="JA">月</span>24<span
style="font-family:"ＭＳ ゴシック",serif"
lang="JA">日</span>(<span style="font-family:"ＭＳ
ゴシック",serif" lang="JA">月</span>) 3:15<span
style="font-family:"ＭＳ ゴシック",serif"
lang="JA">、</span>senya <span
style="font-family:"ＭＳ ゴシック",serif"
lang="JA">
さん（</span><a href="mailto:senya@riseup.net"
moz-do-not-send="true">senya@riseup.net</a><span
style="font-family:"ＭＳ ゴシック",serif"
lang="JA">）のメッセージ</span>:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0cm 0cm 0cm
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<p class="MsoNormal">Hello!<br>
<br>
I'm trying to figure out if it is possible to
implement OpenID Connect<br>
client authorization using a custom protocol handler
registered by a<br>
user in browser.<br>
<br>
I'm a software developer and I'm researching the
possibility of<br>
implementing "sign in with diaspora*" feature for 3rd
party websites to<br>
authenticate with diaspora* federated social network
accounts.<br>
Diaspora* supports OIDC with the Dynamic Client
Registration extension.<br>
<br>
<br>
Imagine there is a federated web service, which has
different web entry<br>
points. Imagine that this federated service supports
custom protocol<br>
handler. For example diaspora* supports registering
`web+diaspora://`<br>
protocol handler using `registerProtocolHandler`<br>
[<a
href="https://developer.mozilla.org/ru/docs/Web/API/Navigator/registerProtocolHandler"
target="_blank" moz-do-not-send="true">https://developer.mozilla.org/ru/docs/Web/API/Navigator/registerProtocolHandler</a>]<br>
browser API call.<br>
<br>
Each user has a specific entry point to this federated
service, i.e. a<br>
website where the user has login credentials. Users
can register a<br>
custom protocol handler for their entry points and
when the user follows<br>
the custom protocol link, the link will be opened on
the correct web<br>
site for this user. The login credentials represent
the user's identity<br>
in the federated service.<br>
<br>
My question is: whether it is possible to use OpenID
Connect to<br>
implement "sign in with" feature for 3rd party clients
to allow users to<br>
sign in using the user's federated identity with using
the custom<br>
protocol handlers to discover the entry point?<br>
<br>
I did some research, but I didn't find an answer.<br>
<br>
What I expect is that when a user requests "sign in
with diaspora*"<br>
button at the 3rd party web site, the browser
redirects this request to<br>
the custom protocol URI, which is resolved by the web
browser and opened<br>
on the proper federated service node, where the
authorization will<br>
happen and the redirected back to the 3rd party site
using the<br>
`redirect_url` according to OpenID Connect.<br>
<br>
So the main difference from most of the OpenID Connect
authorization<br>
providers is that the real address of the
authorization providers is not<br>
known in advance. However we suppose that the user has
registered a<br>
custom protocol handler in their browser. If we use
the custom protocol<br>
link at the authorization phase, then the user's web
browser will<br>
redirect the request to the correct web node. The
first problem here is<br>
that you can't use a preshared secret to identify the
3rd party site<br>
because the nodes are not predefined.<br>
<br>
I discovered the "OpenID Connect Federation"<br>
[<a
href="https://openid.net/specs/openid-connect-federation-1_0.html"
target="_blank" moz-do-not-send="true">https://openid.net/specs/openid-connect-federation-1_0.html</a>]<br>
specification draft which covers so called "Implicit
registration". This<br>
allows to register the OIDC client at the time when
the authorization<br>
request is made. This partially solved this problem.
So when OIDC client<br>
uses a custom protocol URI as an authorization
endpoint, the<br>
authorization provider will receive this request and
then discover the<br>
OIDC client using the dynamic registration protocol.<br>
<br>
So for example when you push the "sign in with
diaspora*" button you're<br>
being redirected to
`web+diaspora://authenticate?authorization_params`<br>
which is resolved for you into the<br>
`<a
href="https://your-federation-node.tld/link_handler?url=authenticate?authorization_params"
target="_blank" moz-do-not-send="true">https://your-federation-node.tld/link_handler?url=authenticate?authorization_params`</a><br>
URL which is then requested and upon the request the
original OIDC<br>
client is being discovered.<br>
<br>
By using this technique I managed to pass the
authorization phase.<br>
However there another problem arose. I don't know how
is it possible to<br>
pass the real host name of the OIDC auth provider back
to the OIDC client.<br>
<br>
In a simple setup when authorization is successful
authorization result<br>
is a code. However in my example, if we respond to the
OIDC client with<br>
a code, the OIDC client will not know where this code
came from. This is<br>
because the authorization request was sent to the
custom protocol URI,<br>
not the real URI. The only source of the information
here is HTTP<br>
referrer of the authorization callback which cannot be
relied upon.<br>
<br>
I found this document<br>
[<a
href="https://openid.net/specs/openid-financial-api-jarm-ID1.html#the-jwt-response-document"
target="_blank" moz-do-not-send="true">https://openid.net/specs/openid-financial-api-jarm-ID1.html#the-jwt-response-document</a>]<br>
which describes replying to authorization request
using a JWT token<br>
which includes the `iss` (issuer) field, which can be
used to identify<br>
the actual node of the federated service. However the
same document states:<br>
<br>
> Assumption: the client remembers the
authorization server to which it<br>
sent the authorization request and binds this
information to the user<br>
agent.<br>
<br>
> The client obtains the iss element from the JWT
and checks whether its<br>
value is well known and identifies the expected issuer
of the<br>
authorization process in examination. If the check
fails, the client<br>
MUST abort processing and refuse the response.<br>
<br>
However when combined with the implicit registration
the authorization<br>
server is not known at the point when we send the
authorization request.<br>
We can't remember the server at the request time
because we don't know<br>
the server and therefore we can't validate the
response. This means that<br>
it is not possible to use this JWT token authorization
response along<br>
with the implicit client registration which makes it
impossible to<br>
implement it without breaking the protocol. Did I get
that right?<br>
<br>
Is there a way to implement the described feature and
remain in comply<br>
with the OIDC protocols?<br>
<br>
Can JWT authorization response can be used in a
combination with the<br>
implicit client registration from OIDC Federation?<br>
<br>
With best regards,<br>
<br>
Senya.<br>
<br>
<br>
<br>
_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@lists.openid.net"
target="_blank" moz-do-not-send="true">specs@lists.openid.net</a><br>
<a
href="http://lists.openid.net/mailman/listinfo/openid-specs"
target="_blank" moz-do-not-send="true">http://lists.openid.net/mailman/listinfo/openid-specs</a><o:p></o:p></p>
</blockquote>
</div>
</blockquote>
</blockquote>
</div>
</blockquote>
</body>
</html>