[Openid-specs-ab] Credential revocation

Breno de Medeiros breno at google.com
Wed Jan 11 21:27:46 UTC 2012


Sounds reasonable. Agree also that we should postpone designing a solution
to a later time.
On Jan 11, 2012 1:23 PM, "George Fletcher" <gffletch at aol.com> wrote:

>  Totally agree.
>
> 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?
>
> 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.
>
> Thanks,
> George
>
> On 1/11/12 4:08 PM, Justin Richer wrote:
>
> 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.
>
>  -- Justin
>
> On 01/11/2012 03:43 PM, George Fletcher wrote:
>
> Just to make sure I understand...
>
> 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.
>
> 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.
>
> 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.
>
> Thanks,
> George
>
> On 1/11/12 3:12 PM, Breno de Medeiros wrote:
>
> On Wed, Jan 11, 2012 at 11:39, George Fletcher <gffletch at aol.com> <gffletch at aol.com> wrote:
>
>  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.
>
>  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.
>
>
>  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 <ve7jtb at ve7jtb.com> <ve7jtb at ve7jtb.com> 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: openid-specs-ab-bounces at lists.openid.net
> [mailto:openid-specs-ab-bounces at lists.openid.net <openid-specs-ab-bounces at lists.openid.net>] On Behalf Of John Bradley
> Sent: Wednesday, January 11, 2012 10:20 AM
> To: openid-specs-ab at lists.openid.net
> Subject: [Openid-specs-ab] Credential revocation
>
> FYI a draft from NISThttp://csrc.nist.gov/publications/drafts/nistir-7817/Draft-NISTIR-7817.pdf
>
> 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 listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120111/01204da7/attachment-0001.html>


More information about the Openid-specs-ab mailing list