[Openid-specs-ab] Credential revocation

Justin Richer jricher at mitre.org
Wed Jan 11 21:08:32 UTC 2012

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>  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>  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] 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 NIST
>>> http://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 list
>>> Openid-specs-ab at lists.openid.net
>>> http://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/2e92846a/attachment-0001.html>

More information about the Openid-specs-ab mailing list