<font size=2 face="sans-serif">This post is longer relevant - it was from
a while back, and was hacked-up by the mailing list server when Nat cleared
my posting status.</font>
<br><font size=2 face="sans-serif">We're in the process of converting our
proprietary extensions to OIDC.</font>
<table width=223 style="border-collapse:collapse;">
<tr height=8>
<td width=223 bgcolor=white style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><font size=1 face="Verdana"><b><br>
Todd Lainhart<br>
Rational software<br>
IBM Corporation<br>
550 King Street, Littleton, MA 01460-1250</b></font><font size=1 face="Arial"><b><br>
2-276-4705 (T/L)<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Todd W Lainhart/Lexington/IBM@IBMUS</font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">"Richer, Justin
P." <jricher@mitre.org>, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:      
 </font><font size=1 face="sans-serif">"openid-specs-ab@lists.openid.net
Working Group" <openid-specs-ab@lists.openid.net>, openid-specs-ab-bounces@lists.openid.net</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">01/14/2014 10:34 AM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [Openid-specs-ab]
An alternative session management proposal</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:    
   </font><font size=1 face="sans-serif">openid-specs-ab-bounces@lists.openid.net</font>
<hr noshade>
<br><font size=2 face="sans-serif">FWIW, we needed session semantics in
our application, so we ended up with defining new token, response and grant
types for session, along with endpoints for validating (introspecting),
extending, and terminating a session (i.e. it uses the network).  This
using the extensibility mechanisms described in 6749.</font>
<table width=7 style="border-collapse:collapse;">
<tr height=8>
<td width=5 bgcolor=white style="border-style:solid;border-color:#000000;border-width:0px 0px 0px 0px;padding:1px 1px;"></table>
<br><font size=3><br>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
From:        </font><font size=1 face="sans-serif">"Richer,
Justin P." <jricher@mitre.org></font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>
To:        </font><font size=1 face="sans-serif">"openid-specs-ab@lists.openid.net
Working Group" <openid-specs-ab@lists.openid.net></font><font size=3>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
Date:        </font><font size=1 face="sans-serif">11/04/2012
11:40 PM</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>
Subject:        </font><font size=1 face="sans-serif">[Openid-specs-ab]
An alternative session management proposal</font><font size=3> </font><font size=1 color=#5f5f5f face="sans-serif"><br>
Sent by:        </font><font size=1 face="sans-serif">openid-specs-ab-bounces@lists.openid.net</font><font size=3>
<hr noshade><font size=3><br>
</font><tt><font size=2><br>
I would like to propose an alternative method of handling session management
in OpenID Connect. I believe that we can build this capability by making
use of the id_token with a set of existing and proposed token management
capabilities in OAuth2. <br>
Starting a new session is easy -- this is just vanilla OpenID Connect token
issuance as it exists today. The id_token that you get issued is the representation
of your session.<br>
Checking on the status is done through an Introspection Endpoint, using
the id_token as an access_token. The community hasn't fully centered around
a draft for an Introspection Endpoint yet, but there was a lot of interest
in it at the last IIW and I think that there are some legs to this general
mechanism. This also gives you dumb-client validation, which was thrown
out with the Check ID Endpoint.<br>
Renewing the session is a little tricky, but since the id_token is a JWT,
I think we can use the Assertion flow of OAuth2 to trade in one id_token
for a new one. There are also a handful of approaches being discussed around
methods of trading in one access token for another access token which might
apply here.<br>
Ending a session is simply calling the Revocation Endpoint with the id_token.
Note that this might keep the refresh token and access token still valid
in the wild, depending on the application. Separation of these life cycles
is, I argue, a good thing.<br>
This differs significantly from the current spec approach as it uses network
calls as opposed to a JavaScript API to accomplish its goals. I already
know this is going to cause cries of overusing the network, but I think
that unless you're Google this isn't going to be as huge of a problem as
it's been made out to be. In my view, this approach trades the extreme
runtime scalability for a devleopment-time simplicity and flexibility (and
therefore, deployment scalability, as it doesn't rely on a single vendor's
implementation or a single runtime environment, like JavaScript). You can
use the same functions on either the front channel (in the browser) or
in the back channel, depending on your application's construction, with
no differences to the protocol. It also works on native applications without
relying on an embedded browser panel. Finally, it doesn't run afoul of
browser cookie policies.<br>
In summary, I think this approach is much more simple to implement and
architecturally more elegant, and all of the tools it would use to do its
job would have general applicability in the wider OAuth2 world.<br>
-- Justin<br>
Openid-specs-ab mailing list<br>
Openid-specs-ab@lists.openid.net</font></tt><font size=3 color=blue><u><br>
</u></font><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"><tt><font size=2 color=blue><u>http://lists.openid.net/mailman/listinfo/openid-specs-ab</u></font></tt></a><tt><font size=2><br>
</font></tt><font size=3><br>
</font><tt><font size=2>_______________________________________________<br>
Openid-specs-ab mailing list<br>
</font></tt><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"><tt><font size=2>http://lists.openid.net/mailman/listinfo/openid-specs-ab</font></tt></a><tt><font size=2><br>