<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Yes unless there is some obvious way to work it into session management.<div><br></div><div>RP sends message to IdP account is blocked at RP, plus redirects user back to IdP.</div><div><br></div><div>IdP includes claim of password reset as of some time in subsequent authentication.</div><div><br></div><div>I can see legitimate users being in a deadlock situation if a RP blocks there federated account.</div><div><br></div><div>That is no different than openID 2 though.</div><div><br></div><div>I would never have a IdP lock an account based on a message from a RP without some sort of trust framework in place.</div><div><br></div><div>John B.</div><div><br><div><div>On 2012-01-11, at 6:27 PM, Breno de Medeiros wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><p>Sounds reasonable. Agree also that we should postpone designing a solution to a later time.</p>
<div class="gmail_quote">On Jan 11, 2012 1:23 PM, "George Fletcher" <<a href="mailto:gffletch@aol.com">gffletch@aol.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">
<font face="Helvetica, Arial, sans-serif">Totally agree. <br>
<br>
To complete the thought that the RP shouldn't trigger "password
resets" at the IdP... if the RP does notify the IdP, and the IdP
does interact with the user and "resolve something"... how does
the IdP inform the RP that it's safe for the RP to remove it's
"block" and allow the user to login again?<br>
<br>
Just wanted to complete the full thought/use case so we can
address it later if necessary. Right now the other things are more
important.<br>
<br>
Thanks,<br>
George<br>
</font><br>
On 1/11/12 4:08 PM, Justin Richer wrote:
<blockquote type="cite">
Just echoing that session management is worth more here, but I do
see some value in the RP signaling the IdP that they think
something is up. However, I think that it should be left up to the
IdP to do something about that. An automated action here would be
too ripe for abuse. If I had the ability to tell Google to make
all of its users reset their password simultaneously, I don't
think Google would be really deploying that for very long. Also,
take the instance where your "password" with the IdP is actually a
client-side certificate -- the cost of revocation and reissue is
enormous and in no way would you want an RP to be able to
invalidate all certificates issued by an IdP.<br>
<br>
-- Justin<br>
<br>
On 01/11/2012 03:43 PM, George Fletcher wrote:
<blockquote type="cite">
<font face="Helvetica, Arial, sans-serif">Just to make sure I
understand...<br>
<br>
You are suggesting that the RPs collect the user's mobile
phone number and use it to help the user recover their account
at the RP if their account at the IdP is compromised in some
way. <br>
<br>
This is a fair amount of work for the RP and significantly
reduces the benefit of out-sourcing the authentication to the
IdP. In the use case that I was considering (let's say the RP
provides an online chat capability) the RP detects that the
federated user has received too many complaints for SPIM and
so the RP marks that federated user as not being able to use
the service. At this point, when the "blocked" user tries to
use the services (with a valid assertion from the federated
IdP), the RP will want to try and help the user do "something"
to prove they are the "good" user. This is a non trivial use
case. As the RP doesn't really have anyway to determine if the
federated user is just a "bad" user or a "good" user whose
account has been compromised. <br>
<br>
Maybe what we need is a new message that allows the RP to
inform the IdP that they have "blocked" the user for some
reason. The IdP could then potentially return some code as to
whether the IdP thinks the user "good" or not. Basically, the
RP and the IdP need to coordinate in some way to help the
"good" user get access to their services. It's kind of a joint
problem. I do agree that the IdP doesn't want to be constantly
pushed to do "password reset" flows.<br>
<br>
Thanks,<br>
George<br>
</font><br>
On 1/11/12 3:12 PM, Breno de Medeiros wrote:
<blockquote type="cite">
<pre>On Wed, Jan 11, 2012 at 11:39, George Fletcher <a href="mailto:gffletch@aol.com" target="_blank"><gffletch@aol.com></a> wrote:
</pre>
<blockquote type="cite">
<pre>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.
</pre>
</blockquote>
<pre>I think password reset is tricky because it's a very expensive
operation in terms of user experience impact. I expect that IDPs will
not want to honor RP requests for this in the absence of first-hand
knowledge of security practices established by the RP and how they
arrive at the conclusion that password reset is needed.
A more likely route for RPs to do is to implement account recovery
processes. For example, by collecting a phone number for SMS-based
account reset -- and requiring users to go through a flow where they
attest that they changed their IDP password and provide the requested
recovery information.
</pre>
<blockquote type="cite">
<pre>Thanks,
George
On 1/11/12 2:34 PM, John Bradley wrote:
Breno, will google as a RP have this use case as well as a RP.
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?
I agree that id_token revocation should be part of the session management
spec.
John
On 2012-01-11, at 4:30 PM, George Fletcher wrote:
I agree with Breno that "session" or "id_token" revocation is more
important.
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.
Thanks,
George
On 1/11/12 2:07 PM, Breno de Medeiros wrote:
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 href="mailto:ve7jtb@ve7jtb.com" target="_blank"><ve7jtb@ve7jtb.com></a> wrote:
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:
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 href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>
[<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">mailto:openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of John Bradley
Sent: Wednesday, January 11, 2012 10:20 AM
To: <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>
Subject: [Openid-specs-ab] Credential revocation
FYI a draft from NIST
<a href="http://csrc.nist.gov/publications/drafts/nistir-7817/Draft-NISTIR-7817.pdf" target="_blank">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.
_______________________________________________
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>
</blockquote>
<br>
<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>
<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>
<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>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-specs-ab<br></blockquote></div><br></div></body></html>