<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">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
cite="mid:CAAJ++qF=yt_z6HXypn5gYj43ry3TeqcRq=wsbato-2PVc8iAWw@mail.gmail.com"
type="cite">
<pre wrap="">On Wed, Jan 11, 2012 at 11:39, George Fletcher <a class="moz-txt-link-rfc2396E" href="mailto:gffletch@aol.com"><gffletch@aol.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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 wrap="">
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 wrap="">
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 class="moz-txt-link-rfc2396E" href="mailto:ve7jtb@ve7jtb.com"><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 class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>
[<a 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 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 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.
_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a 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>
</blockquote>
<br>
</body>
</html>