RE: Re[2]: Strong Authencation (was [PROPOSAL] authentication age
I think the 2.0 spec extension mechanism could handle signed credentials. For example, credentials=s where s is of a (string) format that contains a type + signature, say credentials=OATHVIP:WW91IGhhZCB0byBjaGVjaywgZGlkbid0IHlvdT8gOyk= The format could also further specify mechanism types, signer identity, and algorithm(s) used if those are not part of the definition of 'credentials'. Hans -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drummond Reed Sent: Thursday, October 05, 2006 2:26 PM To: 'Chris Drake' Cc: specs@openid.net Subject: RE: Re[2]: Strong Authencation (was [PROPOSAL] authentication age Chris, Great examples. Signed credentials makes lots of sense. OpenID AuthN 2.0 doesn't handle them yet but I can completely understand them in the roadmap. =Drummond -Original Message- From: Chris Drake [mailto:[EMAIL PROTECTED] Sent: Thursday, October 05, 2006 10:51 AM To: Drummond Reed Cc: specs@openid.net Subject: Re[2]: Strong Authencation (was [PROPOSAL] authentication age Hi Drummond, Example1: RSA would provide a signed response indicating that the user correctly entered the SecurID token code. Example2: The RP would have the public key of the company that supplies the fingerprint scanning hardware (although some extra thought as to how a fingerprint ultimately matches to an Identity is required, which will need an entirely different information flow to Example1). Is Dick a vendor himself? he no doubt knows other ways. Kind Regards, Chris Drake, =1id.com Friday, October 6, 2006, 3:19:44 AM, you wrote: DR Dick, DR You say, The strong authentication will be supplied by a vendor DR that has DR been certified to provide standardized levels of authentication. The DR IdP will often NOT be the strong auth vendor. DR Can you explain how this might work, i.e., how can the RP have a DR relationship directly with the strong auth vendor and not the IdP? DR Would the DR IdP be outsourcing authentication to the strong auth vendor? In DR which case, DR isn't the strong auth vendor the IdP? DR =Drummond DR -Original Message- DR From: [EMAIL PROTECTED] DR [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt DR Sent: Thursday, October 05, 2006 9:36 AM DR To: Gabe Wachob DR Cc: specs@openid.net DR Subject: Strong Authencation (was [PROPOSAL] authentication age DR The vision I have is that strong authentication to your IdP will be DR common in the future. DR The strong authentication will be supplied by a vendor that has been DR certified to provide standardized levels of authentication. The IdP DR will often NOT be the strong auth vendor. DR The RP will have a trust relationship with the vendor, likely DR through a vendor consortium that delegates to vendors that their DR product is certified, ie. the RP will not need to trust each vendor, DR just the certification body. DR I would hope that OpenID can be extended over time to be able to DR move around these types of strong auth assertions. DR -- Dick DR On 4-Oct-06, at 8:41 PM, Gabe Wachob wrote: Chris- As someone who has recently come from working in the financial sector (Visa), its clear that OpenID is NOT intended for authentication where the *relying party* cares about how the authentication is performed. At places like Visa and for home banking, this means that OpenID, without something more, is clearly a non-starter. These relying parties want to know exactly how their users are being authenticated because their business is all about risk management and creating business opportunities around very good knowledge of the risk profile of each transaction type. That all being said, I believe it should be possible to layer on OpenID a form of IDP control such that a relying party can require a certain class or group of IDPs be used when presenting authentication assertions to them. The actual *policy* for how these IDPs are approved is probably orthogonal to the protocol spec, but secure identification of those IDPs (relative to some trust root, etc) could probably be made into an extension usable for those parties who want it. My guess is that culturally, most people involved in OpenID have *not* been interested in addressing these concerns. However, expectations need to be better managed around these sort of relying-party cares scenarios, because its not obvious without actually reading the specs themselves... -Gabe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Drake Sent: Wednesday, October 04, 2006 8:26 PM To: Kevin Turner Cc: specs@openid.net Subject: Re[2]: [PROPOSAL] authentication age Hi Kevin, Sounds like you're leaning towards a root authority for IdPs who can
Re: Strong Authencation (was [PROPOSAL] authentication age
Chris Drake wrote: Hi All, 1. Amazon asks the IdP Please assert this user is not a Robot How can it trust this occurred? 2. Amazon asks the IdP Please re-authenticate this user, via two-factor, two-way strong authentication How can it trust *this* occurred? The IdP can *say* it did, but would RPs prefer a stronger role to encourage adoption? (eg: #1 - the RP provides the captcha, and the hash of the solution, while the IdP returns the solution, or #2 - the RP provides a nonce and later looks for this nonce in the IdP's also-signed-by-the-authentication-vendor-technology response) i.e.: It might get ugly to try and add this stuff in later if we've not catered up-front for these kinds of interchanges. These use-cases seem like a good one, in that it's something that's actually *verifiable*, rather than relying on a trust relationship that probably doesn't exist between RP and IdP. I still don't think this should be in the core spec — core OpenID Auth should be simple — but we should make sure that it's possible to add it via extension and if it isn't adjust the way extensions work to make it possible. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
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[4]: [PROPOSAL] authentication age
Hi Gabe, Beautifully worded, and (IMHO) an extremely valuable real-world opinion. I too believe OpenID is currently a non-starter. I have dual vested interests: I want OpenID to succeed, *especially* for RPs like Visa, since my IdP makes money from supporting OpenID only when OpenID ends up getting used. I also believe that an IdP (and mine in particular) is well suited for deploying secure technology (eg: two factor tokens). If, aside from making OpenID actually *work* for the likes of Visa, we can build in the ability to provide a tangible *benefit* to Visa from using it (that is: allow visa to REQUIRE that a user has authenticate via two-factor means, to an accredited - i.e: explicitly trusted by Visa - IdP) then we've not only cemented the future of OpenID, we've gone an improved a pile of security problems along the way. Kind Regards, Chris Drake 1id.com Thursday, October 5, 2006, 1:41:34 PM, you wrote: GW Chris- GW As someone who has recently come from working in the financial GW sector (Visa), its clear that OpenID is NOT intended for authentication GW where the *relying party* cares about how the authentication is performed. GW At places like Visa and for home banking, this means that OpenID, GW without something more, is clearly a . These relying parties want GW to know exactly how their users are being authenticated because their GW business is all about risk management and creating business opportunities GW around very good knowledge of the risk profile of each transaction type. GW That all being said, I believe it should be possible to layer on GW OpenID a form of IDP control such that a relying party can require a certain GW class or group of IDPs be used when presenting authentication assertions to GW them. The actual *policy* for how these IDPs are approved is probably GW orthogonal to the protocol spec, but secure identification of those IDPs GW (relative to some trust root, etc) could probably be made into an extension GW usable for those parties who want it. GW My guess is that culturally, most people involved in OpenID have GW *not* been interested in addressing these concerns. However, expectations GW need to be better managed around these sort of relying-party cares GW scenarios, because its not obvious without actually reading the specs GW themselves... GW -Gabe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Drake Sent: Wednesday, October 04, 2006 8:26 PM To: Kevin Turner Cc: specs@openid.net Subject: Re[2]: [PROPOSAL] authentication age Hi Kevin, Sounds like you're leaning towards a root authority for IdPs who can audit procedures and verify protection in order to sign the IdP's keys? Joe blogger doesn't care much about identity assertions from an IdP, but it's a reasonable bet to expect that a Bank might care... Kind Regards, Chris Drake ___ 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: Re[4]: [PROPOSAL] authentication age
+1 to one key takeaway from this whole thread: that the marketing/evangelism/messaging around OpenID MUST be very careful to clearly communicate, in Gabe's words, what it can and cannot do right now. Especially when it comes to hard problems like authentication context and circles of trust that SAML and Liberty Alliance have been cranking for 5+ years at. As long as we communicated clearly so expectations aren't raised and then not met then we should give OpenID the runway it needs to grow into those problems, just like 802.11 started thin and grew to become nearly ubiquitous. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gabe Wachob Sent: Wednesday, October 04, 2006 9:09 PM To: 'Chris Drake' Cc: specs@openid.net Subject: RE: Re[4]: [PROPOSAL] authentication age Chris- I don't mean to be pessimistic about OpenID *AT ALL* - I truly do believe that OpenID *WILL* get to the point where its valuable for the Visas of the world. I don't want to stall it for the other use cases that are motivating the people who are currently involved - I think OpenID can quickly evolve when needed. OpenID should be as lightweight as needed for the use case - and I so I think OpenID is great where it is. Its just that we have to be clear what its trying to do today and what it is NOT trying to do. I think we'll surprise some people (like you) - but in the long run, the credibility will be there - I *KNOW* the folks who are involved with OpenID are smart and know what it can and cannot do right now. We just have to make sure that its being communicated clearly so expectations aren't raised and then not met... -Gabe -Original Message- From: Chris Drake [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 04, 2006 9:00 PM To: Gabe Wachob Cc: 'Kevin Turner'; specs@openid.net Subject: Re[4]: [PROPOSAL] authentication age Hi Gabe, Beautifully worded, and (IMHO) an extremely valuable real-world opinion. I too believe OpenID is currently a non-starter. I have dual vested interests: I want OpenID to succeed, *especially* for RPs like Visa, since my IdP makes money from supporting OpenID only when OpenID ends up getting used. I also believe that an IdP (and mine in particular) is well suited for deploying secure technology (eg: two factor tokens). If, aside from making OpenID actually *work* for the likes of Visa, we can build in the ability to provide a tangible *benefit* to Visa from using it (that is: allow visa to REQUIRE that a user has authenticate via two-factor means, to an accredited - i.e: explicitly trusted by Visa - IdP) then we've not only cemented the future of OpenID, we've gone an improved a pile of security problems along the way. Kind Regards, Chris Drake 1id.com Thursday, October 5, 2006, 1:41:34 PM, you wrote: GW Chris- GW As someone who has recently come from working in the financial GW sector (Visa), its clear that OpenID is NOT intended for authentication GW where the *relying party* cares about how the authentication is performed. GW At places like Visa and for home banking, this means that OpenID, GW without something more, is clearly a . These relying parties want GW to know exactly how their users are being authenticated because their GW business is all about risk management and creating business opportunities GW around very good knowledge of the risk profile of each transaction type. GW That all being said, I believe it should be possible to layer on GW OpenID a form of IDP control such that a relying party can require a certain GW class or group of IDPs be used when presenting authentication assertions to GW them. The actual *policy* for how these IDPs are approved is probably GW orthogonal to the protocol spec, but secure identification of those IDPs GW (relative to some trust root, etc) could probably be made into an extension GW usable for those parties who want it. GW My guess is that culturally, most people involved in OpenID have GW *not* been interested in addressing these concerns. However, expectations GW need to be better managed around these sort of relying-party cares GW scenarios, because its not obvious without actually reading the specs GW themselves... GW -Gabe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Drake Sent: Wednesday, October 04, 2006 8:26 PM To: Kevin Turner Cc: specs@openid.net Subject: Re[2]: [PROPOSAL] authentication age Hi Kevin, Sounds like you're leaning towards a root authority for IdPs who can audit procedures and verify protection in order to sign the IdP's keys? Joe blogger doesn't care much about identity assertions from an IdP, but it's a reasonable bet to expect that a Bank might care... Kind Regards, Chris Drake ___ specs mailing list 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
