<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I can see different security requirements requiring different encryption. <div><br></div><div>In a LoA 3 situation using a asymmetric key may be a requirement. </div><div><br></div><div>The Key value token format is simple to process but has limitations. </div><div><br></div><div>It may be that using a structured Simple Web Token, JASON Web Token or XML format may work better in some applications.</div><div><br></div><div>I thought it was you that raised the Jason formatted token idea.</div><div><br></div><div>I don't necessarily want to define a bunch of token types now. </div><div><br></div><div>I do however think we should plan for it if it is something we will want to do later.</div><div><br></div><div>I do think that there needs to be a symmetrically or asymmetrically encrypted token type. </div><div><br></div><div>The alternatives to make openID LoA 2+ are much more painful.</div><div><br></div><div>John B.<br><div><div>On 2010-02-08, at 10:51 PM, Nat Sakimura wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">If the usecase is real, I am all for it, but I am not sure why RP wants to have a specific type of OP token. Could you elaborate a little more? <div><br></div><div>=nat</div><div><br></div><div>P.S., since we are talking about use cases etc., I am assuming it is still safe to do this at spes@. </div>
<div><br><div class="gmail_quote">On Tue, Feb 9, 2010 at 10:22 AM, John Bradley <span dir="ltr"><<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</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 wasn't referring to the artifact itself. I agree that should be opaque.<div><br></div><div>I am talking about the token that is returned from the direct communication.</div><div><br>
</div><div>That needs to be encrypted.</div><div><br></div><div>Encrypting it with the symmetric key works as a basic option.</div><div><br></div><div>The RP needs some way to signal the OP what token type it wants to get.</div>
<div><br></div><div>EG plain, plane + symetric, plane + asymetric, jason + asymetric etc.</div><div><br></div><div>I don't know that overloading PAPE is the best thing.</div><div><br></div><div>John B.</div><div><div>
</div><div class="h5"><div><br></div><div><br><div><div>On 2010-02-08, at 10:14 PM, Nat Sakimura wrote:</div><br><blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">
I changed the Subject to fit the discussion. <br>
<br>
It is not me who decides what but the WG so this is just my personal
opinion, <br>
but to me, Artifact is an opaque string to the RP. i.e., it can be
anything, and it does not matter. <br>
It is up to the OP to create and consume artifact. Only requirement in
the contributed <br>
document is that it has to be constructed partly from RFC1750
pseudorandom number sequence <br>
to thwart guessing. Since it is OP who creates and consume it, the OP
can encrypt it by <br>
his symmetric key. <br>
<br>
If you wanted to express whether it was encrypted or not, there are two
ways of doing it, IMHO. <br>
<br>
One is as you suggested, to do it in the AB itself. In this case, I
would support the idea of <br>
arbitrary token types. <br>
<br>
The other is to do it through PAPE. <br>
<br>
If it were just for LoA, I feel that keeping the Artifact completely
opaque and <br>
using PAPE for LoA purpose is the right way to do. <br>
<br>
=nat<br>
<br>
(2010/02/08 23:59), John Bradley wrote:
<blockquote type="cite">The Artifact binding will have to support a encrypted
token type or types if it is going to be LoA 2+ compliant.
<div><br>
</div>
<div>The question is if you are going to support 2 token types,
should it be generalized to support arbitrary token types.</div>
<div><br>
</div>
<div>John B.<br>
<div>
<div>On 2010-02-08, at 8:16 AM, Nat Sakimura wrote:</div>
<br>
<blockquote type="cite">Hmmm. OK. Got it.
<div><br>
</div>
<div>So, it probably is the topic that we might want to revisit
when we introduce new response type like JSON in v.next, if we ever do,
I suppose. There may be some cases that we might want to respond to the
request at once. (Do not know if there would be.) </div>
<div><br>
</div>
<div>Thanks. </div>
<div><br>
</div>
<div>=nat<br>
<br>
<div class="gmail_quote">On Mon, Feb 8, 2010 at 3:03 PM, Will
Norris <span dir="ltr"><<a href="mailto:will@willnorris.com" target="_blank">will@willnorris.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<div><br>
On Feb 7, 2010, at 8:45 PM, Nat Sakimura wrote:<br>
<br>
> (2010/02/08 10:50), Will Norris wrote:<br>
>> I've never thought of the "openid." prefix as part of the
parameter name, even in URL form encoded messages... it's simply a
namespace prefix to ensure URL parameters don't collide. It's
completely unnecessary in KVF encoded messages, and would add nothing
but extra size to the payload.<br>
><br>
> That's what I was thinking. But after Hideki's message, I started
to doubt that a bit.<br>
> Currently, we only use Direct Response in a very limited way: (1)
association response and (2) direct verification. In both case, we
actually only send openid.* parameters in the request, so we do not
need any name space qualifier in the response.<br>
<br>
</div>
Not necessarily. What about when the OpenID server's URL is "<a href="http://example.com/?service=openid" target="_blank">http://example.com/?service=openid</a>" ? This was
actually the case for the WordPress OpenID plugin for a long time, and
is still true for certain deployments, I believe. You can't make any
assumptions about what the base URL will be, or what additional
parameters may be present, hence why the "openid." is certainly
necessary in those cases.<br>
<div><br>
<br>
> If we do not send anything but openid parameters on the request,
openid.* as a part of url is redundant.<br>
> If there is value in having openid.* in the request, then that is
to send parameters in other name-spaces, in which case, the response
may include other parameters as well, and we need name-space qualifier.<br>
<br>
</div>
allowing non-OpenID parameters in a direct response has never been a
design goal, nor do I believe that it should be. KVF encoding is a new
format defined by the OpenID spec, so it is perfectly acceptable to
state that it is only for OpenID related parameters. This is not the
case for URL parameters.<br>
<div>
<div>_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <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><br>
</div>
_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
</blockquote>
</div>
<br>
</div>
<pre><fieldset></fieldset>_______________________________________________
specs mailing list
<a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a>
</pre>
</blockquote>
<br>
<br>
<pre cols="72">--
Nat Sakimura (<a href="mailto:n-sakimura@nri.co.jp" target="_blank">n-sakimura@nri.co.jp</a>)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547</pre>
</div>
_______________________________________________<br>specs mailing list<br><a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
</blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br>
</div>
</blockquote></div><br></div></body></html>