RE: [PROPOSAL] authentication age
I don't see a problem with the wording of: In the spec, I would say auth age is a request the RP MAY make, and that the IdP SHOULD accept, and that there is no certainty that the IdP will accept it. I don't think however that enough consensus will be reached on this proposal to place it in the spec though. That is why I'd advise it be written as an extension and then merged into the specification in a future version. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Thursday, October 05, 2006 9:25 AM To: Kevin Turner Cc: specs@openid.net Subject: Re: [PROPOSAL] authentication age Kevin, thanks for the well articulated argument. I do see this as something that is completely within the End Users control, and if the End User chose to ignore it, then that is their choice. The use case is that for convenience, a site wants to let the user do certain functions without having to have authenticated recently. Some functions require a fresh authentication. For example it is easy to browse around Amazon.com, but when you go to purchase something, they want to make sure that it is still you, and prompt you for your password. Of course I can have my browser configured to autocomplete the password prompt and all I have to do is press enter, which circumvents proving it is me since someone walking up to my computer does not need to know my password to complete a purchase. The point is that the Amazon.com has made an effort to increase the certainty that it is me, and it is my choice to not take advantage of it. If OpenID does NOT have this functionality, sites that have requirements similar to Amazon.com will be reluctant to adopt OpenID. In the spec, I would say auth age is a request the RP MAY make, and that the IdP SHOULD accept, and that there is no certainty that the IdP will accept it. To look at it another way, there is no requirement for the IdP to ask me if I want to respond to an RP that I have never been to before. I could have an IdP that responds positively to ever request with no interaction from myself. There is nothing in OpenID that proves I approved the request, or for that matter that there is actually a person at the end of the browser. On 4-Oct-06, at 6:29 PM, Kevin Turner wrote: > 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 you. > > 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 > specs@openi
Re: [PROPOSAL] authentication age
Kevin, thanks for the well articulated argument. I do see this as something that is completely within the End Users control, and if the End User chose to ignore it, then that is their choice. The use case is that for convenience, a site wants to let the user do certain functions without having to have authenticated recently. Some functions require a fresh authentication. For example it is easy to browse around Amazon.com, but when you go to purchase something, they want to make sure that it is still you, and prompt you for your password. Of course I can have my browser configured to autocomplete the password prompt and all I have to do is press enter, which circumvents proving it is me since someone walking up to my computer does not need to know my password to complete a purchase. The point is that the Amazon.com has made an effort to increase the certainty that it is me, and it is my choice to not take advantage of it. If OpenID does NOT have this functionality, sites that have requirements similar to Amazon.com will be reluctant to adopt OpenID. In the spec, I would say auth age is a request the RP MAY make, and that the IdP SHOULD accept, and that there is no certainty that the IdP will accept it. To look at it another way, there is no requirement for the IdP to ask me if I want to respond to an RP that I have never been to before. I could have an IdP that responds positively to ever request with no interaction from myself. There is nothing in OpenID that proves I approved the request, or for that matter that there is actually a person at the end of the browser. On 4-Oct-06, at 6:29 PM, Kevin Turner wrote: > 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 > you. > > 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 > specs@openid.net > http://openid.net/mailman/listinfo/specs > > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] authentication age
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 you. 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 specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] authentication age
Dick Hardt wrote: > I find the argument that IdPs will just return success all the time > to be baseless. A good IdP will do what it thinks is best for its > users. A bad IdP will not have any users for any period of time. I suppose it depends on what you consider to be "bad". Consider this: * We have an RP that asks for a session age limit of one hour. * GoodCitizen-IdP respects the session age thing and asks user to log in again if it's been over an hour since they last did so. * BadCitizen-IdP just ignores the flag and has sessions that last until the user closes his browser, but it lies to the RP and says that it respected the flag. The user experience on GoodCitizen-IdP is "damnit, why do I have to keep logging in over and over again?!". The user is likely to be much happier with BadCitizen-IdP because he only has to log in once each day. While it's true that BadCitizen-IdP might put its users at more risk, it's been my experience that users are willing to trade an awful lot of security to avoid software nagging at them repeatedly. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] authentication age
On 2-Oct-06, at 11:51 AM, Kevin Turner wrote: > On Sun, 2006-10-01 at 20:07 +0100, Martin Atkins wrote: > [...] >> then some/most IdPs just won't bother. [...] >> a completely uncheckable assumption and is therefore broken by >> design. >> >> The best we can do is make it a MAY (that is, max_age is a >> *suggestion* >> from the RP) and hope that most IdPs do the right thing; we shouldn't >> write the spec in a way that misleads RP implementers into thinking >> they've actually got any real control here. > > What he said. > > I'd suggest drafting this feature as an extension. I know that > weakens > it, but as Martin says, you can't count on it being there in any case, > so I think an optional extension is a much more straightforward way of > representing when this functionality is actually available. I still think this should be in the auth spec and not an extension. An IdP will already be doing some type of session age management, and what we want is for the RP to indicate to the IdP what session age is acceptable for what it is doing with the user. David asked about LJ and should it expire the LJ session. If that is how LJ is determining wether to AuthN me while acting as an IdP, then perhaps. Many apps have different levels of session age, and I think the lack of this feature will hinder adoption by many sites. I find the argument that IdPs will just return success all the time to be baseless. A good IdP will do what it thinks is best for its users. A bad IdP will not have any users for any period of time. Given the portability of URLs, being an IdP is competitive, and people will move to the one that best suits them. If that means some IdPs just return success *and* that is what users want, then so be it. The feature is there for all the other users and IdPs that want it. For example, I am a little dismayed that myopenid.com has not timed out my session for quite a while, which means that anyone walking up to my machine can login to any of my OpenID sites. Not an issue now, but if we want serious websites to take OpenID seriously, we need to put the right features in. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] authentication age
On Sun, 2006-10-01 at 13:08 -0700, Recordon, David wrote: > It could be augmented to also contain a response parameter telling the > RP if the IdP acknowledged it, then the RP could make the decision if > it wants to proceed. You will want that response parameter. Otherwise, couldn't I (as the attacker who has the user's IdP cookie) just drop the auth_age parameter from the checkid request? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] authentication age
Agreed, OpenID does not identify a *person*, rather that the user of the current browser session has control over the given URI. This is the same as email, you can't guarantee the email server only allows one person to use each address. I think the issue is that for IdPs doing nothing other than being an IdP, this won't be a concern. Though people making IdPs out of other applications, this could be a problem. Thus making it required seems to actually hurt us since as Mart said they'll just say they did it. :-\ --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Monday, October 02, 2006 9:33 AM To: Martin Atkins Cc: specs@openid.net Subject: Re: [PROPOSAL] authentication age On 2-Oct-06, at 2:48 AM, Martin Atkins wrote: > Recordon, David wrote: >> That was going to be my exact follow-up to my own message, though got >> distracted. What I phrased was how Dick described it. >> >> I like the feature, though agree that many IdPs may be unable to >> implement it due to how they do session handling. It could be >> augmented to also contain a response parameter telling the RP if the >> IdP acknowledged it, then the RP could make the decision if it wants >> to proceed. >> > > But again, IdPs will just send it whether they did it or not, because > it's like a "make it work" flag; people will quickly forget/dismiss > what it really means and set it just to make their IdP work. > > Unless you've got some way to *prove* that you did it (I can't think > of > one) there's no point. > > This also ignores the fact that not all "IdPs" are going to use > sessions and passwords. One could potentially make one that acts on a > presented certificate, for example. Or one which just returns "Yes" to > everything as an anonymising tool. OpenID, like many other protocols, places trust on the IdP that it will operate per the protocol. The user takes responsibility for choosing an IdP that they trust to operate appropriately. eg: There is nothing that stops an IdP from *proving* a particular URL belongs to a particular user. Currently I have blame.ca pointing to dick.hardt.myopenid.com, the myopenid.com server could state any user at myopenid.com owns blame.ca, but I trust myopenid.com to not do that. There is no way to *prove* it is me using the URL. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] authentication age
On 2-Oct-06, at 2:48 AM, Martin Atkins wrote: > Recordon, David wrote: >> That was going to be my exact follow-up to my own message, though got >> distracted. What I phrased was how Dick described it. >> >> I like the feature, though agree that many IdPs may be unable to >> implement it due to how they do session handling. It could be >> augmented >> to also contain a response parameter telling the RP if the IdP >> acknowledged it, then the RP could make the decision if it wants >> to proceed. >> > > But again, IdPs will just send it whether they did it or not, because > it's like a "make it work" flag; people will quickly forget/dismiss > what > it really means and set it just to make their IdP work. > > Unless you've got some way to *prove* that you did it (I can't > think of > one) there's no point. > > This also ignores the fact that not all "IdPs" are going to use > sessions > and passwords. One could potentially make one that acts on a presented > certificate, for example. Or one which just returns "Yes" to > everything > as an anonymising tool. OpenID, like many other protocols, places trust on the IdP that it will operate per the protocol. The user takes responsibility for choosing an IdP that they trust to operate appropriately. eg: There is nothing that stops an IdP from *proving* a particular URL belongs to a particular user. Currently I have blame.ca pointing to dick.hardt.myopenid.com, the myopenid.com server could state any user at myopenid.com owns blame.ca, but I trust myopenid.com to not do that. There is no way to *prove* it is me using the URL. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] authentication age
Also means from a Yadis file is easy for an IdP to advertise the extension or not. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Turner Sent: Monday, October 02, 2006 11:52 AM To: specs@openid.net Subject: Re: [PROPOSAL] authentication age On Sun, 2006-10-01 at 20:07 +0100, Martin Atkins wrote: [...] > then some/most IdPs just won't bother. [...] a completely uncheckable > assumption and is therefore broken by design. > > The best we can do is make it a MAY (that is, max_age is a > *suggestion* from the RP) and hope that most IdPs do the right thing; > we shouldn't write the spec in a way that misleads RP implementers > into thinking they've actually got any real control here. What he said. I'd suggest drafting this feature as an extension. I know that weakens it, but as Martin says, you can't count on it being there in any case, so I think an optional extension is a much more straightforward way of representing when this functionality is actually available. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] authentication age
On Sun, 2006-10-01 at 20:07 +0100, Martin Atkins wrote: [...] > then some/most IdPs just won't bother. [...] > a completely uncheckable assumption and is therefore broken by design. > > The best we can do is make it a MAY (that is, max_age is a *suggestion* > from the RP) and hope that most IdPs do the right thing; we shouldn't > write the spec in a way that misleads RP implementers into thinking > they've actually got any real control here. What he said. I'd suggest drafting this feature as an extension. I know that weakens it, but as Martin says, you can't count on it being there in any case, so I think an optional extension is a much more straightforward way of representing when this functionality is actually available. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] authentication age
Recordon, David wrote: > That was going to be my exact follow-up to my own message, though got > distracted. What I phrased was how Dick described it. > > I like the feature, though agree that many IdPs may be unable to > implement it due to how they do session handling. It could be augmented > to also contain a response parameter telling the RP if the IdP > acknowledged it, then the RP could make the decision if it wants to proceed. > But again, IdPs will just send it whether they did it or not, because it's like a "make it work" flag; people will quickly forget/dismiss what it really means and set it just to make their IdP work. Unless you've got some way to *prove* that you did it (I can't think of one) there's no point. This also ignores the fact that not all "IdPs" are going to use sessions and passwords. One could potentially make one that acts on a presented certificate, for example. Or one which just returns "Yes" to everything as an anonymising tool. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] authentication age
Title: RE: [PROPOSAL] authentication age That was going to be my exact follow-up to my own message, though got distracted. What I phrased was how Dick described it. I like the feature, though agree that many IdPs may be unable to implement it due to how they do session handling. It could be augmented to also contain a response parameter telling the RP if the IdP acknowledged it, then the RP could make the decision if it wants to proceed. --David -Original Message- From: [EMAIL PROTECTED] on behalf of Martin Atkins Sent: Sun 10/1/2006 12:07 PM To: specs@openid.net Subject: Re: [PROPOSAL] authentication age Recordon, David wrote: > No, IdP MUST perform and RP MAY include. > IdP implementations that are embedded into some other app might have trouble implementing this. Take LiveJournal, for example: what should it do in the case where it has to re-authenticate? End the user's LJ session and force them to log in again? Duplicate the login code in the OpenID server code? Aside from that qualm, this is another one of those things where it's pointless to make it a MUST since IdPs that don't implement it aren't going to get punished in any way. If IdPs can get away without doing it, and RPs can't tell that they have, then some/most IdPs just won't bother. Sure, it reduces the usefulness of this feature, but this feature is riding on a completely uncheckable assumption and is therefore broken by design. The best we can do is make it a MAY (that is, max_age is a *suggestion* from the RP) and hope that most IdPs do the right thing; we shouldn't write the spec in a way that misleads RP implementers into thinking they've actually got any real control here. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] authentication age
Recordon, David wrote: > No, IdP MUST perform and RP MAY include. > IdP implementations that are embedded into some other app might have trouble implementing this. Take LiveJournal, for example: what should it do in the case where it has to re-authenticate? End the user's LJ session and force them to log in again? Duplicate the login code in the OpenID server code? Aside from that qualm, this is another one of those things where it's pointless to make it a MUST since IdPs that don't implement it aren't going to get punished in any way. If IdPs can get away without doing it, and RPs can't tell that they have, then some/most IdPs just won't bother. Sure, it reduces the usefulness of this feature, but this feature is riding on a completely uncheckable assumption and is therefore broken by design. The best we can do is make it a MAY (that is, max_age is a *suggestion* from the RP) and hope that most IdPs do the right thing; we shouldn't write the spec in a way that misleads RP implementers into thinking they've actually got any real control here. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] authentication age
Title: RE: [PROPOSAL] authentication age No, IdP MUST perform and RP MAY include. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED]] Sent: Sun 10/1/2006 7:52 AM To: Recordon, David Cc: specs@openid.net Subject: Re: [PROPOSAL] authentication age Better wording, thanks. I was thinking the IdP MUST perform per the parameter. The RP MAY include it, so it is an optional parameter in the request. Are you suggesting the RP MUST include it? -- Dick On 1-Oct-06, at 3:33 AM, Recordon, David wrote: > I like this, though think minutes would be granular enough. Just > to clarify, since it took me reading it a few times... > > Add an optional request parameter openid.auth_age which is a > positive integer. This parameter allows the relying party to > request that if the identity provider has not renewed the session > with the user in the past X minutes, that it do so at this time. > If left out of the request, it is assumed that a session of any age > is acceptable for the transaction. If 0, the RP is requesting > authentication be done on this request no matter the age of the > session. > > Assuming this be added, it would have to be a MUST in the spec to > be useful. > > --David > > > -Original Message- > From: [EMAIL PROTECTED] on behalf of Dick Hardt > Sent: Sat 9/30/2006 5:04 PM > To: specs@openid.net > Subject: [PROPOSAL] authentication age > > Motivating Use Case: > > > Different RPs will require different amounts of certainty about the > user, and at times will have different requirements depending on what > the user is doing. Eg. from existing web applications today. There is > little concern when the user is getting personalized pages and a > relatively old cookie may be adequate but the app will require the > user to provide their password when changing their settings. > > Proposed Implementation > --- > > New, optional parameter in the request, "openid.auth_age" where the > value is the number of seconds (minutes?) since the user last > provided credentials. If the it has been longer since then that the > IdP authenticated the user, then the IdP MUST authenticate the user > again. A value of zero (0) means that the IdP MUST prompt the user > for credentials. > > Issues > > There is no way to force an IdP to authenticate the user, but a > "good" IdP implementation will follow the requests of the RP > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] authentication age
Better wording, thanks. I was thinking the IdP MUST perform per the parameter. The RP MAY include it, so it is an optional parameter in the request. Are you suggesting the RP MUST include it? -- Dick On 1-Oct-06, at 3:33 AM, Recordon, David wrote: > I like this, though think minutes would be granular enough. Just > to clarify, since it took me reading it a few times... > > Add an optional request parameter openid.auth_age which is a > positive integer. This parameter allows the relying party to > request that if the identity provider has not renewed the session > with the user in the past X minutes, that it do so at this time. > If left out of the request, it is assumed that a session of any age > is acceptable for the transaction. If 0, the RP is requesting > authentication be done on this request no matter the age of the > session. > > Assuming this be added, it would have to be a MUST in the spec to > be useful. > > --David > > > -Original Message- > From: [EMAIL PROTECTED] on behalf of Dick Hardt > Sent: Sat 9/30/2006 5:04 PM > To: specs@openid.net > Subject: [PROPOSAL] authentication age > > Motivating Use Case: > > > Different RPs will require different amounts of certainty about the > user, and at times will have different requirements depending on what > the user is doing. Eg. from existing web applications today. There is > little concern when the user is getting personalized pages and a > relatively old cookie may be adequate but the app will require the > user to provide their password when changing their settings. > > Proposed Implementation > --- > > New, optional parameter in the request, "openid.auth_age" where the > value is the number of seconds (minutes?) since the user last > provided credentials. If the it has been longer since then that the > IdP authenticated the user, then the IdP MUST authenticate the user > again. A value of zero (0) means that the IdP MUST prompt the user > for credentials. > > Issues > > There is no way to force an IdP to authenticate the user, but a > "good" IdP implementation will follow the requests of the RP > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] authentication age
Title: RE: [PROPOSAL] authentication age I like this, though think minutes would be granular enough. Just to clarify, since it took me reading it a few times... Add an optional request parameter openid.auth_age which is a positive integer. This parameter allows the relying party to request that if the identity provider has not renewed the session with the user in the past X minutes, that it do so at this time. If left out of the request, it is assumed that a session of any age is acceptable for the transaction. If 0, the RP is requesting authentication be done on this request no matter the age of the session. Assuming this be added, it would have to be a MUST in the spec to be useful. --David -Original Message- From: [EMAIL PROTECTED] on behalf of Dick Hardt Sent: Sat 9/30/2006 5:04 PM To: specs@openid.net Subject: [PROPOSAL] authentication age Motivating Use Case: Different RPs will require different amounts of certainty about the user, and at times will have different requirements depending on what the user is doing. Eg. from existing web applications today. There is little concern when the user is getting personalized pages and a relatively old cookie may be adequate but the app will require the user to provide their password when changing their settings. Proposed Implementation --- New, optional parameter in the request, "openid.auth_age" where the value is the number of seconds (minutes?) since the user last provided credentials. If the it has been longer since then that the IdP authenticated the user, then the IdP MUST authenticate the user again. A value of zero (0) means that the IdP MUST prompt the user for credentials. Issues There is no way to force an IdP to authenticate the user, but a "good" IdP implementation will follow the requests of the RP ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
