<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Hi Pedro,<br>
<br>
Sorry for confusing the thread. I was responding to Nat's point
about structured headers. It's not really relevant to the issue
you are addressing. As for requirements for the back-channel call,
you can add a document on the wiki, or file a new issue on the
site as an enhancement for the working group to address and then
put in the ticket all the current requirements. Others can then
comment on the ticket and the working group can track it.<br>
<br>
Note, that for this back-channel capability to be relevant to an
RP, the RP must support the concept of "server side" sessions (or
maintain a "black list" of revoked sessions). This doesn't tend to
be capabilities that most RPs support.<br>
<br>
Thanks,<br>
George<br>
<br>
</font>
<div class="moz-cite-prefix">On 3/13/14 11:12 AM, Pedro Felix wrote:<br>
</div>
<blockquote
cite="mid:CAD+AFDsa8qPeBv41_eGGJzPqoAte7cCyxcPyV9-C-GBM3cw8Kw@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net"
target="_blank">Openid-specs-ab@lists.openid.net</a>
<br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net"
target="_blank">Openid-specs-ab@lists.openid.net</a>
<br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://connect.me/gffletch" title="View
full card on Connect.Me" target="_blank"><img
src="cid:part7.02070104.05070005@aol.com"
alt="George Fletcher" width="359"
height="113"></a></div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Openid-specs-ab mailing list
<a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<a href="http://connect.me/gffletch" title="View full card on
Connect.Me"><img src="cid:part13.07010303.04030702@aol.com"
alt="George Fletcher" width="359" height="113"></a></div>
</body>
</html>