[Openid-specs-ab] Credential revocation

George Fletcher gffletch at aol.com
Wed Jan 11 21:22:50 UTC 2012

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.


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>  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
> _______________________________________________
> 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/35ec22ea/attachment.html>

More information about the Openid-specs-ab mailing list