<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">As I recall it was Facebook and Google who were keen on the implicit flow.<div><br></div><div>Part of the argument was that it was easier to get someone to implement it by dropping some JS code on their site for the callback URI and setting the id_token as a cookie.</div><div><br></div><div>It is a different approach than the more traditional library one, that fits the code flow better.</div><div><br></div><div>I am not personally attached to the implicit flow.</div><div><br></div><div>However we probably need wider feedback before changing the basic client profile.</div><div><br></div><div>John <br><div><div>On 2012-02-21, at 11:43 AM, Justin Richer wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
Yes, I certainly do. It's cleaner in design, its pattern is more
proven, and it can be implemented in all kinds of different clients,
even lightweight Javascript ones. The implicit flow is an
optimization for fewer network calls, and it's always felt more like
a codified hack than a real protocol flow to me. Whenever I've seen
somebody pressed on the issue of whether or not their clients could
really support the code flow, they've admitted that yes, they could,
but they didn't want to pay the time costs of a second round trip to
the server.<br>
<br>
We're also concentrating on the code flow for our own Connect
deployment, and we'll patch in the implicit flow sometime later.<br>
<br>
-- Justin<br>
<br>
On 02/21/2012 09:40 AM, John Bradley wrote:
<blockquote cite="mid:F7BC25BF-013E-479D-8124-6D01B6FAD434@ve7jtb.com" type="cite">No problem, sometimes even I am surprised by things
that have snuck in or are left over from older versions.
<div><br>
</div>
<div>Do you still prefer the code follow for the basic client
profile?</div>
<div><br>
</div>
<div>John<br>
<div>
<div>On 2012-02-21, at 11:23 AM, Justin Richer wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000"> Hrm. Reading through
the drafts again just now, it does clearly say that 'code'
and 'token id_token' are MTI, so I'm not sure where I got
that impression from. My mistake.<br>
<br>
-- Justin<br>
<br>
On 02/21/2012 09:14 AM, John Bradley wrote:
<blockquote cite="mid:BB3295CC-EA0F-4CFF-A686-A13703E97E71@ve7jtb.com" type="cite">Both code and 'token id_token' should be
mediatory to implement for servers.
<div><br>
</div>
<div>Is there a particular place that you are seeing
that in the spec. I think that is a bug, if true. I
will look for it today.</div>
<div><br>
</div>
<div>If the WG did want code to be the only MTI flow
then we would defiantly need to change the basic
profile to code.</div>
<div><br>
</div>
<div>John<br>
<div>
<div>On 2012-02-21, at 10:47 AM, Justin Richer
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000"> I would
prefer to have the Basic Client use the code
flow for another reason: the code flow is the
only one that's mandatory to implement for the
server. So what we have right now is advice for
servers to implement something that our advice
to clients say they don't have to.<br>
<br>
-- Justin<br>
<br>
On 02/20/2012 07:30 PM, John Bradley wrote:
<blockquote cite="mid:320D07FB-4DB3-413E-B29A-A7607F3C76AD@ve7jtb.com" type="cite">
<pre wrap="">Torsten,
From your tickets it looks like you are thinking that the Basic client profile is for JS clients in the browser doing canvas type Aps and directly accessing the check_id and user_info endpoints.
The idea for what i't worth was that it is intended to be a Web server profile that uses the browser side implicit flow, with a simple sever side callback that extracts the fragment and passes it to the server for processing and verification. That is why Cross Origin Resource sharing is not mentioned win that profile.
It is true that that profile could be used for a Canvas type JS app in the browser accessing the endpoints as well.
Would your preference have been to make the basic client use the code flow? It is arguably similar in complexity at the end of the day, but with better security for Web Server type applications.
I would probably just have the client base64 decode the id_token and forget calling the check_id endpoint. If the client doesn't have the correct token endpoint and gives the client secret to it checking the signature on the id_token is not very useful:)
Regards
John B.
On 2012-02-20, at 3:58 PM, Torsten Lodderstedt wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi all,
I'm unable to find out whether OpenID Connect supports public clients. It seems Connect assumes all clients register with the OP and obtain a client credential. If this observation is correct, what is the reason for being more restrictive than OAuth?
regards,
Torsten.
_______________________________________________
Openid-specs-ab mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a moz-do-not-send="true" 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>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a moz-do-not-send="true" 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>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote></div><br></div></body></html>