<div dir="ltr">I wasn't thinking a token exchange, I was thinking it would just do a new authentication request with different scope, etc..</div><div class="gmail_extra"><br><div class="gmail_quote">On 2 May 2016 at 14:54, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</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">
<p>I have no idea. What you are describing is different. Its
scope, SAML probably has it, but I don't know what it is. You
also describe a token exchange service<br>
</p><div><div class="h5">
<br>
<div>On 5/2/2016 4:56 AM, Stian Thorgersen
wrote:<br>
</div>
<blockquote type="cite">
<p dir="ltr">Wouldn't saml support it fairly easily? It's just
another auth request with SE different params?</p>
<div class="gmail_quote">On 29 Apr 2016 16:19, "Bill Burke" <<a href="mailto:bburke@redhat.com" target="_blank"></a><a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Sounds great. I hope
we don't have to implement this for SAML too ;)<br>
<br>
<div>On 4/29/2016 12:02 AM, Stian Thorgersen wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Clients should be able to obtain tokens with
reduced scope and longer or shorter expiration, then
later request new tokens with increased scope and
different expiration. They should also be able to
require different levels of authentication and also
require re-authentication.<br>
</div>
<div><br>
</div>
<div>An application may for example:</div>
<div><br>
</div>
<div>* At first only need users email - this would allow
showing the name + email. In this situation a long
expiration access token in combination with implicit
flow would do. It's also not necessary to
re-authenticate the user and a user that has been
logged-in for months or even a year is fine. </div>
<div><br>
</div>
<div>* When a user clicks on orders it would require the
password and extend scope to be able to view orders.
Now you'll want to switch to short expiration access
tokens and authorization code grant. You'll also want
to make sure the user logged-in fairly recently, max
30 days could be sensible.</div>
<div><br>
</div>
<div>* When a user tries to purchase something the user
now has to provide the OTP to be able to purchase with
saved credit card details. You'll also want to make
sure the user logged-in very recently, max a day could
be required. There may also be cases where you always
want the user to re-authenticate, for example when
trying to purchase something over a certain price
level.</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
keycloak-dev mailing list
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
<pre cols="72">--
Bill Burke
JBoss, a division of Red Hat
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a></pre>
</div>
<br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</blockquote>
</div>
</blockquote>
<br>
<pre cols="72">--
Bill Burke
JBoss, a division of Red Hat
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a></pre>
</div></div></div>
</blockquote></div><br></div>