<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">It could be some other
      signal. In many cases, the way a good user get's their account
      "back" is by going through a password reset flow. In this case,
      the only party capable of doing the "password reset flow" is the
      IdP. The key is to help the "good" user regain access to the
      services of the RP. In this case, the RP needs some assurance that
      the IdP has re-validated the user and is making a "claim" that
      this is a "good" user.<br>
      <br>
      Thanks,<br>
      George<br>
    </font><br>
    On 1/11/12 2:34 PM, John Bradley wrote:
    <blockquote
      cite="mid:402E2AF8-216B-4BE7-B01B-29FEC137027E@ve7jtb.com"
      type="cite">Breno, will google as a RP have this use case as well
      as a RP.
      <div><br>
      </div>
      <div>If you detect suspicious activity on an account will you want
        to ask for a password reset or raise some other signal to the
        IdP?</div>
      <div><br>
      </div>
      <div>I agree that id_token revocation should be part of the
        session management spec.</div>
      <div><br>
      </div>
      <div>John<br>
        <div>
          <div>On 2012-01-11, at 4:30 PM, George Fletcher wrote:</div>
          <br class="Apple-interchange-newline">
          <blockquote type="cite">
            <meta content="text/html; charset=ISO-8859-1"
              http-equiv="Content-Type">
            <div bgcolor="#FFFFFF" text="#000000"> <font
                face="Helvetica, Arial, sans-serif">I agree with Breno
                that "session" or "id_token" revocation is more
                important. <br>
                <br>
                The RP asking the user to perform a password reset at
                the IdP is interesting. However, is most of our
                experience this is really only needed with the user is
                marked for suspicious activity by the RP and the RP
                wants the user to go through some flow to "prove" that
                they own the account. As an RP, we do have this use
                case.<br>
                <br>
                Thanks,<br>
                George<br>
              </font><br>
              On 1/11/12 2:07 PM, Breno de Medeiros wrote:
              <blockquote
cite="mid:CAAJ++qGStrYxCAQ1XSPFmwwb7pUQGPWu4cLHF4VGFAzps1J_zg@mail.gmail.com"
                type="cite">
                <pre wrap="">A more useful feature would be instant session revocation on password
resets. That could be implemented entirely on the IDP as an
added-feature if the RP supports near-instant detection of session
state changes (which I am hoping to document for the JS API).

On Wed, Jan 11, 2012 at 11:04, John Bradley <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:ve7jtb@ve7jtb.com"><ve7jtb@ve7jtb.com></a> wrote:
</pre>
                <blockquote type="cite">
                  <pre wrap="">It was something that a number of RP brought up in the early discussions.

We are more IdP weighted at the moment.  I think it was Facebook that was most interested in this from the IdP.

It isn't a priority, but the NIST document reminded me it slipped from the feature list.

I agree the other things are higher priority.

Just interested in seeing if there is any real interest in the issue.

John B.
On 2012-01-11, at 3:47 PM, Mike Jones wrote:

</pre>
                  <blockquote type="cite">
                    <pre wrap="">I'd only add it to a list if we're seeing actual demand for it from deployers.

As it is, I think we should focus on addressing review comments received, completing session management, and completing JWE.  And when we finish those, adding self-issued IDs.  That's more than enough to keep us productively busy for the time being.

                              -- Mike

-----Original Message-----
From: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a> [<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:openid-specs-ab-bounces@lists.openid.net">mailto:openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of John Bradley
Sent: Wednesday, January 11, 2012 10:20 AM
To: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>
Subject: [Openid-specs-ab] Credential revocation

FYI a draft from NIST
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://csrc.nist.gov/publications/drafts/nistir-7817/Draft-NISTIR-7817.pdf">http://csrc.nist.gov/publications/drafts/nistir-7817/Draft-NISTIR-7817.pdf</a>

I don't think his conclusion is necessarily practical, however it is interesting to see what they are thinking.

We did talk about having a signalling mechanism from RP to IdP to request a password reset or provide other signalling.

That got dropped along the way.

Should this get added to a list of possible extensions?

John B.

</pre>
                  </blockquote>
                  <pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>

</pre>
                </blockquote>
                <pre wrap="">
</pre>
              </blockquote>
              <br>
              <pre class="moz-signature" cols="72">-- 
Chief Architect                   AIM:  gffletch
Identity Services Engineering     Work: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:george.fletcher@teamaol.com">george.fletcher@teamaol.com</a>
AOL Inc.                          Home: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:gffletch@aol.com">gffletch@aol.com</a>
Mobile: +1-703-462-3494           Blog: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://practicalid.blogspot.com/">http://practicalid.blogspot.com</a>
Office: +1-703-265-2544           Twitter: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://twitter.com/gffletch">http://twitter.com/gffletch</a>
</pre>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Chief Architect                   AIM:  gffletch
Identity Services Engineering     Work: <a class="moz-txt-link-abbreviated" href="mailto:george.fletcher@teamaol.com">george.fletcher@teamaol.com</a>
AOL Inc.                          Home: <a class="moz-txt-link-abbreviated" href="mailto:gffletch@aol.com">gffletch@aol.com</a>
Mobile: +1-703-462-3494           Blog: <a class="moz-txt-link-freetext" href="http://practicalid.blogspot.com">http://practicalid.blogspot.com</a>
Office: +1-703-265-2544           Twitter: <a class="moz-txt-link-freetext" href="http://twitter.com/gffletch">http://twitter.com/gffletch</a>
</pre>
  </body>
</html>