<html><head><base href="x-msg://8027/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">We could describe the token format in the lite spec, but that is going to make it longer. <div>The goal was to have something around the 10-15 page mark.</div><div><br></div><div>The id_token is a signed JWT.</div><div><br></div><div>They are described in session management. Sec 3.1.1. </div><div><a href="http://openid.net/specs/openid-connect-session-1_0.html">http://openid.net/specs/openid-connect-session-1_0.html</a></div><div><br></div><div>Now I also note looking at that spec sec 3.2.2 is referring to the introspection endpoint as Check Session. </div><div>They are the same thing. I am happy to go with Check Session rather than introspection. </div><div>We should have only one.</div><div><br></div><div>The introspection/Check session endpoint is just verifying the signature of the JWT that is passed as it's access token and returning the unpacked contents.</div><div>That became less clear when we tried to accommodate sending the user_info access token.</div><div>We removed that, so we should put back the simple explanation of what that endpoint is doing.</div><div><br></div><div>John</div><div><br></div><div><div><div>On 2011-08-10, at 2:19 PM, Edmund Jay wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font-family: tahoma, 'new york', times, serif; font-size: 10pt; "><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">It could be that I missed the discussion about the id_token being opaque only in the Lite spec.<br>In the Session Management spec, it is a JWT.<br>Breno, does that remain valid?<br>If so, I will update the Messages spec.<br><br><br>-- Edmund<br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font-family: tahoma, 'new york', times, serif; font-size: 10pt; "><br><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font-family: arial, helvetica, sans-serif; font-size: 10pt; "><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold; ">From:</span></b><span class="Apple-converted-space"> </span>John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>><br><b><span style="font-weight: bold; ">To:</span></b><span class="Apple-converted-space"> </span>Johnny Bufu <<a href="mailto:jbufu@janrain.com">jbufu@janrain.com</a>><br><b><span style="font-weight: bold; ">Cc:</span></b><span class="Apple-converted-space"> </span>Edmund Jay <<a href="mailto:ejay@mgi1.com">ejay@mgi1.com</a>>; <a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br><b><span style="font-weight: bold; ">Sent:</span></b><span class="Apple-converted-space"> </span>Wed, August 10, 2011 11:09:43 AM<br><b><span style="font-weight: bold; ">Subject:</span></b><span class="Apple-converted-space"> </span>Re: [Openid-specs-ab] Spec call notes 08-Aug-11<br></font><br>There is additional session related information in the id_token. It is only opaque ti the lite spec. <span class="Apple-converted-space"> </span><br>A Full client just needs to check the signature and not use the introspection endpoint at all. <span class="Apple-converted-space"> </span><br>This is the same thing Facebook is doing with signed request, we have just added a way for a client that docent understand crypto to validate the token.<br><br>Why not use the id_token both places. <span class="Apple-converted-space"> </span><br><br>We received strong push back that people had existing formats for access tokens that they did not want to change.<br>My original preference was to use the same JWT for both. <span class="Apple-converted-space"> </span><br><br>Google, SalesForce and others wanted a separation between the two.<br>T-Mobile also expressed that that was their preference when I talked to them at the IETF.<br><br>Allowing the client to send a access token to the introspection endpoint was also problematic for people like DT who want introspection to be stateless.<br><br>I guess the simple answer is that there may be different info in the two tokens.<br><br>John B.<br><br>On 2011-08-10, at 1:51 PM, Johnny Bufu wrote:<br><br>> Why are two tokens needed (access_token and id_token)? I don't see in the spec any reason that would prevent the use of just one token with both introspection and userinfo endpoints.<br>><span class="Apple-converted-space"> </span><br>> Johnny<br>><span class="Apple-converted-space"> </span><br>> On 11-08-08 05:15 PM, Edmund Jay wrote:<br>>><span class="Apple-converted-space"> </span><br>>> Spec call notes 08-Aug-11<br>>><span class="Apple-converted-space"> </span><br>>> Pam Dingle<br>>> John Bradley<br>>> Nat Sakimura<br>>> Johnny Bufu<br>>> George Fletcher<br>>> Edmund Jay<br>>><span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>>> John made some changes to the OpenID Lite spec<br>>> * changed the Introspection endpoint from GET request to POST request<br>>> due to the fact the<br>>> the ID Token may be intercepted by referral URLs/Logs, and other methods.<br>>> Breno said in chat with Nat that GET and JSONP may be needed<br>>> John to contact Breno offline for further discussions<br>>> * made other non-controversial changes from feedback<br>>><span class="Apple-converted-space"> </span><br>>> John will work on first draft of OpenID 2.0 compatibility/migration<br>>> spec. Maybe available tomorrow.<br>>><span class="Apple-converted-space"> </span><br>>> Edmund will post first draft of OpendID Connect Messages spec to the<br>>> mailing list.<br>>><span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>>> Discussion of JWT and long header names:<br>>> * most preferred longer names<br>>> * most feel that it's too late to make major changes to spec<br>>> * longer or shorter names can be implemented by defining long constant<br>>> values by developers vice versa<br>>> * perhaps better documentation in specs for short names<br>>><span class="Apple-converted-space"> </span><br>>> Pam has written a OpenID Connect landing page which will be posted to<br>>> the list for feedback<br>>><span class="Apple-converted-space"> </span><br>>> WG to setup new support mailing list not encumbered by IPR agreements<br>>> for general and support questions and feedback.<br>>><span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>>> <<a href="http://openid.net/specs/openid-connect-framework-1_0.html" target="_blank">http://openid.net/specs/openid-connect-framework-1_0.html</a>><br>>><span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>>><span class="Apple-converted-space"> </span><br>>> _______________________________________________<br>>> Openid-specs-ab mailing list<br>>><span class="Apple-converted-space"> </span><a ymailto="mailto:Openid-specs-ab@lists.openid.net" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>>><span class="Apple-converted-space"> </span><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>><span class="Apple-converted-space"> </span><a ymailto="mailto:Openid-specs-ab@lists.openid.net" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>><span class="Apple-converted-space"> </span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></div></div></div></div></blockquote></div><br></div></body></html>