<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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 cite="mid:4F0DF464.1080503@aol.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 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.
_______________________________________________
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>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
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>
<br>
</body>
</html>