<div dir="ltr">+1 <div><br></div><div>There may be other considerations that we may want to give to this html encoding option. </div><div>In the old day, I remember something peculiar about IE8's behavior around its XSS Filter. </div>
<div>We might want to advise the readers that they might need to use X-XSS-Protection: 0 header. </div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/10/19 George Fletcher <span dir="ltr"><<a href="mailto:gffletch@aol.com" target="_blank">gffletch@aol.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">I agree with Nat. While we
call the flow a POST-redirect binding (and in the OpenID2 case it
more naturally fits this model), the response_mode choices of
query and fragment most naturally fit with html_form. The
mechanism used to submit the form is the POST-redirect mechanism.<br>
<br>
As for the plan to address this in the specs, I'd prefer just
describing the response_mode parameter in it's optional state with
the description that additional response_modes can be added at a
later time. Then do the rest of the 'html_form' flow as an
extension. This makes sure the specs are extensible to others like
postMessage and CORS while not adding functionality to the current
specs. This also ensures that OpenID Connect Providers must
understand the parameter name even if for now they ignore it.<br>
<br>
It also allows current implementations to continue with their
implementation without being out of compliance with the spec;
meaning they have an extension point for this functionality.<br>
<br>
That said, with adding the new response_mode parameter, do we need
to add new text around things like what happens with the client
sends response_mode=query for an implicit request and the AS is
not willing to return the data in the query string? Is this an
6749 'invalid_request' error or a 'unsupported_response_type'?<br>
<br>
Another thought, do we have to explicitly require that if the
html_form response_mode is used, then the redirect_url MUST have a
scheme of https? If the initial request is from a 'confidential'
client then OAuth2 and OpenID Connect allow the redirect_url to be
http.<br>
<br>
Given the above, I have some concerns that by trying to rush the
additions into the specs we are going to miss something important.<br>
<br>
Thanks,<br>
George<br>
<br>
</font><div><div class="h5">
<div>On 10/18/13 2:00 PM, Mike Jones wrote:<br>
</div>
<blockquote type="cite">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Or
possibly “form_POST”? What do others think?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I’ve
updated Discovery to add proposed text for the
“response_modes_supported” parameter. See:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
<a href="http://self-issued.info/docs/openid-connect-discovery-1_0-18-Oct-13.html" target="_blank">http://self-issued.info/docs/openid-connect-discovery-1_0-18-Oct-13.html</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
<a href="http://self-issued.info/docs/openid-connect-discovery-1_0-18-Oct-13-diffs.docx" target="_blank">http://self-issued.info/docs/openid-connect-discovery-1_0-18-Oct-13-diffs.docx</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
also updated the Multiple Response Types drafts posted to
specify the encoding for the POST response, as Breno
suggested.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I’ll
finish the updates to Core to update the normative text that
currently requires fragment encoding Implicit and Hybrid
response parameters when I get back from an appointment in a
few hours.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
-- Mike<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">
n-sakimura [<a href="mailto:n-sakimura@nri.co.jp" target="_blank">mailto:n-sakimura@nri.co.jp</a>]
<br>
<b>Sent:</b> Friday, October 18, 2013 10:49 AM<br>
<b>To:</b> Mike Jones<br>
<b>Cc:</b> Breno de Medeiros; John Bradley;
<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
<b>Subject:</b> Re: [Openid-specs-ab] proposed POST
response type for OAuth/Connect<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">POST is a misleading name for the
response mode / response encoding.
<br>
<br>
Even with fragment, one could potentially use POST. In fact,
that would be one of the easiest implementation choice for
the fragment encoding case: it is just a few lines of
Javascript code, such as:<br>
<br>
<br>
<u></u><u></u></p>
<pre style="background:white"><span style="font-size:9.0pt;color:#333333"> <span>RelayToken</span><span>:</span> </span><span><span style="font-size:9.0pt;color:#004080">function</span></span><span style="font-size:9.0pt;color:#333333"> <span>(</span><span>url</span><span>,</span><span>callback</span><span>)</span> <span>{</span><u></u><u></u></span></pre>
<pre style="background:white"><span style="font-size:9.0pt;color:#333333"> </span><span><i><span style="font-size:9.0pt;color:#999988">// calllback proto = function(data){ .... } </span></i></span><span style="font-size:9.0pt;color:#333333"><u></u><u></u></span></pre>
<pre style="background:white"><span style="font-size:9.0pt;color:#333333"> <span>token</span> <span>=</span> <span>$</span><span>.</span><span>FVAR</span><span>(</span></span><span><span style="font-size:9.0pt;color:#bb8844">"token"</span></span><span><span style="font-size:9.0pt;color:#333333">);</span></span><span style="font-size:9.0pt;color:#333333"><u></u><u></u></span></pre>
<pre style="background:white"><span style="font-size:9.0pt;color:#333333"> <span>state</span> <span>=</span> <span>$</span><span>.</span><span>FVAR</span><span>(</span></span><span><span style="font-size:9.0pt;color:#bb8844">"state"</span></span><span><span style="font-size:9.0pt;color:#333333">)</span></span><span style="font-size:9.0pt;color:#333333"><u></u><u></u></span></pre>
<pre style="background:white"><span style="font-size:9.0pt;color:#333333"> </span><span><span style="font-size:9.0pt;color:#004080">if</span></span><span style="font-size:9.0pt;color:#333333"> <span>(</span><span>token</span><span>)</span> <span>{</span><u></u><u></u></span></pre>
<pre style="background:white"><span style="font-size:9.0pt;color:#333333"> <span>$</span><span>.</span><span>post</span><span>(</span><span>url</span><span>,</span> <span>{</span> <span>token</span><span>:</span> <span>token</span><span>,</span> <span>state</span><span>:</span> <span>state</span> <span>}).</span><span>done</span><span>(</span><span>callback</span><span>);</span><u></u><u></u></span></pre>
<pre style="background:white"><span style="font-size:9.0pt;color:#333333"> <span>}</span><u></u><u></u></span></pre>
<pre style="background:white"><span style="font-size:9.0pt;color:#333333"> <span>}</span><u></u><u></u></span></pre>
<p class="MsoNormal"> <br>
<br>
What you are describing as POST in fact is the
representation of the authorization grant in HTML Form. So,
instead of POST, 'html_form' or simply 'html' is a more
approriate description.
<br>
<br>
(2013/10/19 1:22), Mike Jones wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">These
versions are updated to use Response Mode and to be more
explicit about always using the specified response mode,
including for errors:<u></u><u></u></p>
<p class="MsoNormal">
<a href="http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-18-Oct-13.html" target="_blank">http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-18-Oct-13.html</a><u></u><u></u></p>
<p class="MsoNormal">
<a href="http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-18-Oct-13-diffs.docx" target="_blank">http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-18-Oct-13-diffs.docx</a><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Breno,
you’re right that you shouldn’t try to use POST or other
non-default response modes if you haven’t first verified
that the server supports it.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">
-- Mike<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><b>From:</b>
Breno de Medeiros [<a href="mailto:breno@google.com" target="_blank">mailto:breno@google.com</a>]
<br>
<b>Sent:</b> Friday, October 18, 2013 9:18 AM<br>
<b>To:</b> John Bradley<br>
<b>Cc:</b> Mike Jones; Vladimir Dzhuvinov / NimbusDS; <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">
openid-specs-ab@lists.openid.net</a><br>
<b>Subject:</b> Re: [Openid-specs-ab] proposed POST
response type for OAuth/Connect<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p>I meant errors for unsupported response_mode (I don't
think encoding is a good name even for POST since encoding
would be x-www-form-urlencoded, not POST)<u></u><u></u></p>
<div>
<p class="MsoNormal">On
Oct 18, 2013 9:15 AM, "Breno de Medeiros" <<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>>
wrote:<u></u><u></u></p>
<p>I agree w/ Mike that the sensible way to return error
responses should stay in default encoding for backward
compatibility. I am pointing out that if a client asks
for POST encoding and gets a fragment encoded error
response it will likely not be able to parse it. Since
the state parameter in particular will be missing it is
difficult to see how clients would recover.<u></u><u></u></p>
<p>So if POST is not MTI the client should establish ahead
of time that the IDP is compliant via discovery or other
means. It cannot rely on automatically recovering by
handling an error message. Which may be obvious but I am
just pointing out.<u></u><u></u></p>
<div>
<p class="MsoNormal">On
Oct 18, 2013 8:50 AM, "John Bradley" <<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>>
wrote:<u></u><u></u></p>
<div>
<p class="MsoNormal">I
am OK with response_mode or response_encoding.<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">John
B.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On
2013-10-18, at 12:46 PM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>>
wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">I’m
flexible on the parameter name. I didn’t
use “transport” or “response_transport”
because it didn’t read as well as
“response_encoding”, but I hear what
you’re saying about postMessage and CORS
not really being encodings. I think I
like your “response_mode” suggestion the
best. What do others think?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">If
I don’t hear objections or alternative
suggestions, I’ll change to using that.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">
-- Mike<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><b>From:</b> Breno
de Medeiros [mailto:<a href="mailto:breno@" target="_blank">breno@</a><a href="http://google.com" target="_blank">google.com</a>] <br>
<b>Sent:</b> Friday, October 18, 2013 5:48
AM<br>
<b>To:</b> Vladimir Dzhuvinov / NimbusDS<br>
<b>Cc:</b> Mike Jones; <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">
openid-specs-ab@lists.openid.net</a><br>
<b>Subject:</b> Re: [Openid-specs-ab]
proposed POST response type for
OAuth/Connect<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p>I mean when server cannot support specified
encoding. I am skeptical we can provide a
backwards compatible solution though I am
not sure one is needed if MTI is only the
default.<u></u><u></u></p>
<p>I would prefer response_transport or
response_mode instead of encoding since
neither POST, postMessage, or CORS (to
mention future candidates) feel like
alternative encodings. They are really more
than that.<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On
Oct 18, 2013 5:42 AM, "Breno de
Medeiros" <<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>>
wrote:<u></u><u></u></p>
</div>
<p>The main issue I see here is that error
messages no longer feel right being
supplied in the default encoding for type.
Case in point: if client requests POST
because it wants ID_token but can't parse
fragments, returning a fragment-encoded
response will not help the caller.<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On
Oct 18, 2013 1:49 AM, "Vladimir
Dzhuvinov / NimbusDS" <<a href="mailto:vladimir@nimbusds.com" target="_blank">vladimir@nimbusds.com</a>>
wrote:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Hi
Mike, hi guys,<br>
<br>
I read the proposed spec and it looks
good to me. Making the "what" and<br>
the "how" orthogonal parameters is
great.<br>
<br>
Vladimir<br>
<br>
--<br>
Vladimir Dzhuvinov : <a href="http://www.NimbusDS.com" target="_blank">www.NimbusDS.com</a> : <a href="mailto:vladimir@nimbusds.com" target="_blank">vladimir@nimbusds.com</a><br>
<br>
<br>
<br>
<br>
-------- Original Message --------<br>
Subject: Re: [Openid-specs-ab]
proposed POST response type for<br>
OAuth/Connect<br>
From: Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>><br>
Date: Fri, October 18, 2013 8:02 am<br>
To: "<<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>>"<br>
<<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br>
<br>
As Breno suggested, I’ve made the
proposed changes to the Multiple<br>
Response Types spec. These changes do
two things:<br>
1. Disentangle the specification
of what parameters are to be<br>
returned (which is done with the
response_type parameter) from the<br>
specification of how they are to be
returned (which is done with the<br>
response_encoding parameter).<br>
2. Define a POST response
encoding that can be used to request<br>
that parameters be returned via form
POST.<br>
<br>
The response_encoding parameter is
only used when a non-default<br>
encoding is requested, so these
changes will no effect on current<br>
implementations.<br>
<br>
I’ve posted an updated version at<br>
<a href="http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-17-Oct-13.html" target="_blank">http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-17-Oct-13.html</a>.<br>
The .xml source is posted there as
well. Also, diffs from the current<br>
BitBucket version can be viewed as
tracked changes in the Word version<br>
at<br>
<a href="http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-17-Oct-13-diffs.docx" target="_blank">http://self-issued.info/docs/oauth-v2-multiple-response-types-1_0-17-Oct-13-diffs.docx</a>.<br>
<br>
Tomorrow I’ll review the current
Connect specs and make the following<br>
related proposed changes:<br>
· Add the
response_encodings_supported discovery
parameter.<br>
· Review the places where
fragment encoding is explicitly or<br>
implicitly specified, making sure the
language doesn’t prohibit using<br>
the POST response encoding instead.
(Note that we should do this now,<br>
even should we don’t adopt POST as
part of the core now, so we don’t<br>
preclude it in the future.)<br>
(I’d make these changes now, but it’s
probably better that I do it<br>
when I’m not tired.)<br>
<br>
Anyway, this wasn’t hard and the
result isn’t difficult to<br>
understand or implement. (And
implementation will remain optional.)<br>
<br>
Thanks to Breno, John, and Brian for
the feedback on how this should<br>
work. Thanks especially to Brian for
posting his draft, which I<br>
borrowed some text and the example
from.<br>
<br>
-- Mike<br>
<br>
From: Breno de Medeiros [mailto:<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>]<br>
Sent: Thursday, October 17, 2013 4:02
PM<br>
To: Mike Jones<br>
Cc: Brian Campbell; <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br>
Subject: Re: [Openid-specs-ab]
proposed POST response type for<br>
OAuth/Connect<br>
<br>
<br>
<br>
On Thu, Oct 17, 2013 at 11:37 AM,
Mike Jones<br>
<<a href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>>
wrote:<br>
Thanks, Brian. This is really
useful. I suspect I’ll be using<br>
some of your text in my write-up. J<br>
<br>
I just spent some time on the phone
with Breno discussing this and he<br>
agreed that defining a POST response
at this point is reasonable. When<br>
talking about possible ways of
specifying the POST response behavior,
he<br>
stated the principle that when a
behavioral change is being requested,<br>
that this should be done so
dynamically, rather than via
registration.<br>
That way, particular clients can be
updated to use this behavior without<br>
requiring a new client registration.
(He likes using registration to<br>
specify behavioral restrictions,
however, such as requiring particular<br>
signing/encryption algorithms, etc.)<br>
<br>
He said that the way that he’d do it
is to include a<br>
“transport=POST” parameter in the
authorization request. So<br>
that’s what I’ll write up. We could
later than define<br>
“transport=postMessage”,
“transport=CORS”, etc. if we decide to<br>
do so.<br>
<br>
<br>
<br>
<br>
I think this is sufficiently small
that we might be able to undertake in<br>
a short time-frame. I believe that
POST support will prove useful. I'd<br>
recommend this to be added to the new
response types part of the spec:<br>
<a href="http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html" target="_blank">http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html</a>,<br>
for a number of reasons: It already
has the burden to deal with the<br>
security properties of different
encoding formats for different
response<br>
types, and would be a small change in
scope to change it to talk about<br>
'transport' modes instead of encoding.
That spec also has been stable<br>
and changed little for a long time, so
the chance that it can be<br>
re-written w/o side-effects is
probably higher.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
As an aside, Breno also said that the
reason that he thinks Session<br>
Management isn’t yet ready to be
final, is that he’d like us to<br>
explore the option of using a CORS
transport, rather than postMessage<br>
within Session Management. I’ll leave
it to Breno to say more about<br>
this.<br>
<br>
Thanks<br>
all,<br>
-- Mike<br>
<br>
From: <a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a><br>
[mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>]
On Behalf Of Brian<br>
Campbell<br>
Sent: Thursday, October 17, 2013 8:56
AM<br>
To: <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br>
Subject: [Openid-specs-ab] proposed
POST response type for<br>
OAuth/Connect<br>
<br>
As discussed during today's call
[1], attached is the<br>
pseudo-standard document I wrote up
earlier this year describing an HTTP<br>
POST response type (effectively a POST
binding) for OAuth/OIDC.<br>
<br>
I know everyone has a lot of docs to
read right now but this one is<br>
*very* short and has a good example.<br>
<br>
We've found this approach to work well
in practice and be easy to<br>
implement.<br>
<br>
It can be done as a straight
extension, as illustrated with this
doc, or<br>
could incorporated into core connect.<br>
<br>
<br>
<br>
As John mentioned, the main drawback
of this approach is proliferation<br>
of the Response Types registry. Which
is kind of ugly but something that<br>
no one will care much about once it's
done. It's also more of a<br>
consequence of the response type
constructs put forth by OAuth than it<br>
is with this particular extension.<br>
<br>
Thanks,<br>
Brian<br>
<br>
<br>
[1]<br>
<a href="http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20131014/004062.html" target="_blank">http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20131014/004062.html</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
--<br>
--Breno<br>
<br>
<br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><u></u><u></u></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br>
<br>
<u></u><u></u></p>
<pre>_______________________________________________<u></u><u></u></pre>
<pre>Openid-specs-ab mailing list<u></u><u></u></pre>
<pre><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><u></u><u></u></pre>
<pre><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><u></u><u></u></pre>
</blockquote>
<p class="MsoNormal"><br>
<br>
<br>
<u></u><u></u></p>
<pre>-- <u></u><u></u></pre>
<pre>Nat Sakimura (<a href="mailto:n-sakimura@nri.co.jp" target="_blank">n-sakimura@nri.co.jp</a>)<u></u><u></u></pre>
<pre>Nomura Research Institute, Ltd. <u></u><u></u></pre>
<pre><a href="Tel:+81-3-6274-1412" target="_blank">Tel:+81-3-6274-1412</a> Fax:<a href="tel:%2B81-3-6274-1547" value="+81362741547" target="_blank">+81-3-6274-1547</a><u></u><u></u></pre>
<pre><u></u> <u></u></pre>
<pre><span style="font-family:"MS Gothic"">本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ござ</span>ӓ<u></u><u></u></pre>
<pre> 6;|<u></u><u></u></pre>
<pre>14;<span style="font-family:"MS Gothic"">せんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。</span><u></u><u></u></pre>
<pre>PLEASE READ:<u></u><u></u></pre>
<pre>The information contained in this e-mail is confidential and intended for the named recipient(s) only.<u></u><u></u></pre>
<pre>If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.<u></u><u></u></pre>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a 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>
</div></div><span class="HOEnZb"><font color="#888888"><div>-- <br>
<a href="http://connect.me/gffletch" title="View full card on
Connect.Me" target="_blank"><img src="cid:part40.06020404.03030106@aol.com" alt="George Fletcher" height="113" width="359"></a></div>
</font></span></div>
<br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en" target="_blank">http://twitter.com/_nat_en</a>
</div>