Pretty much the *only* relationship that exists between the RP and the
IdP is that the authentication method is trustworthy because the user
has decided it is.  I believe this proposal places additional demands on
that, and that those are demands that the protocol cannot fully support.

When you ask an OpenID IdP for information, you are not asking some
ultimately trusted third party, you're asking whomever End User chose to
appoint as her agent.  Which is quite possibly an entity entirely
controlled by End User herself.  All information sent by the IdP is
*only as true as the user wants it to be.*

So I think the question is, who will catch the blame when the RP's
requirements for credentials checking aren't followed?  Will you be able
to say "End User chose to ignore our requirements, so it's End User's
problem."?  If so, this proposal is okay.  But if your Draconian
Security Officer will say "When I said to require up-to-the-moment
credential checks to access our resources, I did mean REQUIRE, not just
'require *if the user feels like it.*'  Your implementation failed to
enforce our requirements.  You're fired," then that is not so good for

My worry is that features like this will mislead the RP developers into
thinking they have more control over the authentication protocol than
they really do, into thinking that they can exert the level of control
required by that Draconian Security Officer, when OpenID actually leaves
all those controls in the hands of the user and their chosen IdP.

Session age isn't the only thing application developers will be
accustomed to having control over.  Password strength and password
lifetime are a few other obvious examples.  (Although I think it's rare
to see password lifetime restrictions on the Web these days, it was
popular to do in other applications for a while.)  But with OpenID, the
RP won't have real control over of any of those things.  I'm concerned
that adding parameters that suggest it does will do more harm than good.

The RP doesn't even have the capacity to audit any of those processes,
to find out what procedure was followed.  Now that I think about it,
that may be the real problem: How useful is it to specify security
requirements that you can't audit?

specs mailing list

Reply via email to