<div dir="ltr">1) Since I'm rather new in this group, what would be the best way to continue this discussion? In this email thread? By trying to produce a requirements doc on the wiki?<div>Most probably, I will be working on an implementation of this feature in the near future.<br>
<div><br></div><div>2) Picking up on Justin's reply: an approach would be to also use the "aud" and the "sub" to identify the session to cleanup. I don't like the idea of requiring a round-trip to the introspection endpoint in order to check the token purpose. Makes sense?</div>
</div><div><br></div><div>Thanks</div><div>Pedro</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 13, 2014 at 2:12 PM, Justin Richer <span dir="ltr"><<a href="mailto:jricher@mitre.org" target="_blank">jricher@mitre.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
A number of our apps use this combined approach -- the server sends
out a signed JWT that the client can check the "iss" field and
signature, then (if it cares to do so) the client does introspection
with the server at "iss" to see if the token's still valid and what
it's good for.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- Justin</font></span><div><div class="h5"><br>
<br>
<div>On 03/13/2014 09:48 AM, George Fletcher
wrote:<br>
</div>
<blockquote type="cite">
<font face="Helvetica, Arial, sans-serif">On the "structured
token" side of things I remember having a discussion about this
at IIW (a few back) and I thought someone and written something
up. It was needed in a number of cases that were using the token
introspection endpoint as a way to identifier the authorization
server to send the token to for introspection. I can't find my
notes on the conversation but maybe someone else remembers?<br>
<br>
I think conceptually it was as simple as a non-signed JWT
containing iss and token fields. Obviously, the rest of JOSE
could be applied for signed or encrypted tokens.<br>
<br>
Thanks,<br>
George<br>
<br>
</font>
<div>On 3/12/14 9:02 PM, n-sakimura wrote:<br>
</div>
<blockquote type="cite">Let's
just write up requirements on the WG wiki (@bitbucket). <br>
Once we agree on the requirements, it should be straight forward
to turn it into a spec. <br>
<br>
On the side note, perhaps it is actually for OAuth WG, but it
would be nice to spec out the structured (access) token. it
could be pseudo opaque as well as long as you can find the
authorization server from the token but we at least need to be
able to find out the iss. <br>
<br>
Nat <br>
<br>
(2014/03/13 3:58), John Bradley wrote: <br>
<blockquote type="cite">We have discussed creating a backchannel
push method for the IdP to notify the RP. <br>
<br>
So far noting is written up. I have a bad feeling that it
might be me that needs to create the first draft. <br>
<br>
John B. <br>
<br>
On Mar 12, 2014, at 3:54 PM, Pedro Felix <a href="mailto:pmhsfelix@gmail.com" target="_blank"><pmhsfelix@gmail.com></a>
wrote: <br>
<br>
<blockquote type="cite">Hi, <br>
<br>
I've a scenario where a OIDC OP is acting as a bridge
between upstream IdPs using non-OIDC protocols (e.g
Shibboleth) and downstream RPs using OIDC. <br>
In this scenario I have the following requirements <br>
1) The upstream IdP notifies the OP of a session
termination via back-channel <br>
2) The OP propagate this cleanup notification to the
downstream RPs, also via back-channel (a back-channel to
front-channel is not possible) <br>
<br>
Unfortunately, the OIDC session management spec does not
provide any way to perform this back-channel cleanup,
however I remember reading some meeting notes about this
possibility. <br>
<br>
Is there anything that can be shared? I would like to align
our solution with what is being developed by this working
group. <br>
<br>
Thanks <br>
Pedro <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>
</blockquote>
<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>
</blockquote>
<br>
<br>
</blockquote>
<br>
<div>-- <br>
<a href="http://connect.me/gffletch" title="View full card on Connect.Me" target="_blank"><img src="cid:part6.06090108.04030006@mitre.org" alt="George
Fletcher" height="113" width="359"></a></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></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></div></div>