RE: Re[2]: Strong Authencation (was [PROPOSAL] authentication age
Thanks, Hans, I'm getting better educated on 2.0 every day. =Drummond -Original Message- From: Granqvist, Hans [mailto:[EMAIL PROTECTED] Sent: Friday, October 06, 2006 9:21 AM To: Drummond Reed; Chris Drake Cc: specs@openid.net Subject: RE: Re[2]: Strong Authencation (was [PROPOSAL] authentication age I think the 2.0 spec extension mechanism could handle signed credentials. For example, "credentials=" where 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
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: Re[2]: Strong Authencation (was [PROPOSAL] authentication age
I think the 2.0 spec extension mechanism could handle signed credentials. For example, "credentials=" where 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&
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 that has DR> been certified to provide standardized levels of authentication. The IdP DR> 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? Would the DR> IdP be outsourcing authentication to the strong auth vendor? In 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 DR> 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 through DR> a vendor consortium that delegates to vendors that their product is DR> certified, ie. the RP will not need to trust each vendor, just the DR> certification body. DR> I would hope that OpenID can be extended over time to be able to move DR> 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 >>> 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
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 that has DR> been certified to provide standardized levels of authentication. The IdP DR> 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? Would the DR> IdP be outsourcing authentication to the strong auth vendor? In 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 DR> 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 through DR> a vendor consortium that delegates to vendors that their product is DR> certified, ie. the RP will not need to trust each vendor, just the DR> certification body. DR> I would hope that OpenID can be extended over time to be able to move DR> 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 >>> 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 >> >> DR> ___ DR> specs mailing list DR> specs@openid.net DR> http://openid.net/mailman/listinfo/specs DR> ___ DR> specs mailing list DR> specs@openid.net DR> http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Strong Authencation (was [PROPOSAL] authentication age
I don't think it will get ugly because I think there are many ways to layer on the functionality we are talking about. For example, Visa has something called 3-D Secure which is similar in many ways to OpenID using INames. Instead of keying authentication off of INames, they use Credit Card numbers. 3-D Secure is implemented in one of several programs - Visa has "Verified by Visa", Mastercard has "Securecode". Each of these programs varies the protocol slightly, but by in large, the authentication mechanisms are enforced by *policy* (ie you MUST use auth at least as strong as this) and that policy is enforced (among several methods) by 1) the fact that communication with the (credit card) directory requires clients to authenticate *to the directory* and 2) the back channel communication is mediated through the directory. That is one mechanism (which I really don't recommend) that OpenID could take. Dick suggested a method where there is some vendor providing strong authentication which is verifiable by anyone (or at least anyone who is part of the club and cares). That authentication proof could ride along as an extension element in OpenID. I suggested another approach where IDP's themselves were "part of a club" (and there could be any number of clubs) and that proof that the *IDP* was part of the club could come along as an extension to the OpenID data. And if you are worried about how the RP knows ahead of time that an IDP can provide the requisite extensions, we have a mechanism in the XRDS to advertise these facts. So I think all these pieces are there -- it's just a matter of figuring out how to put them together for the specific scenarios we have. I think in fact that there will not be *one* answer, but several -- each based on the ecosystem involved. If electronic payments systems ever use OpenID, there will be certain controls that everyone who is participating will have to agree to, and those controls may have to be enforceable and auditable by multiple parties. In other scenarios, only certain parties may care (ie RP's) and it may be untenable to impose as many extension pieces. But I think we're getting ahead of ourselves. As long as you believe the extensibility is in there and there is a reasonable path forward, then we should get the basic infrastructure gelled and rolled out soon, or else we'll never get the experience and mindshare with OpenID that we want. The quicker we get today done, the quicker we can get to tomorrow. -Gabe > -Original Message- > From: Chris Drake [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 05, 2006 10:22 AM > To: Dick Hardt > Cc: Gabe Wachob; 'Kevin Turner'; specs@openid.net > Subject: Re: Strong Authencation (was [PROPOSAL] authentication age > > 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. > > Kind Regards, > Chris Drake ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Strong Authencation (was [PROPOSAL] authentication age
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. Kind Regards, Chris Drake ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Strong Authencation (was [PROPOSAL] authentication age
Dick, You say, " The strong authentication will be supplied by a vendor that has been certified to provide standardized levels of authentication. The IdP will often NOT be the strong auth vendor." Can you explain how this might work, i.e., how can the RP have a relationship directly with the strong auth vendor and not the IdP? Would the IdP be outsourcing authentication to the strong auth vendor? In which case, isn't the strong auth vendor the IdP? =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Thursday, October 05, 2006 9:36 AM To: Gabe Wachob Cc: specs@openid.net Subject: Strong Authencation (was [PROPOSAL] authentication age The vision I have is that strong authentication to your IdP will be common in the future. The strong authentication will be supplied by a vendor that has been certified to provide standardized levels of authentication. The IdP will often NOT be the strong auth vendor. The RP will have a trust relationship with the vendor, likely through a vendor consortium that delegates to vendors that their product is certified, ie. the RP will not need to trust each vendor, just the certification body. I would hope that OpenID can be extended over time to be able to move around these types of strong auth assertions. -- Dick 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 >> 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 > > ___ 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: Strong Authencation (was [PROPOSAL] authentication age
Hi Gabe Agreed that things like strong auth would be extensions. I still think auth_age is something that RPs expect to be able to influence (primarily being able to ask for the auth ceremony to be performed) and should be in the current spec. -- Dick On 5-Oct-06, at 9:47 AM, Gabe Wachob wrote: > Dick > That's sounds like a reasonable approach (if I understand what you > are saying), and frankly one I hadn't considered. > More importantly, it sounds like we agree that we expect this to lie > in the domain of OpenID extensions and that we don't need to > consider these > scenarios/requirements now for the 2.0 specs? > > -Gabe > >> -Original Message- >> From: Dick Hardt [mailto:[EMAIL PROTECTED] >> Sent: Thursday, October 05, 2006 9:36 AM >> To: Gabe Wachob >> Cc: 'Chris Drake'; 'Kevin Turner'; specs@openid.net >> Subject: Strong Authencation (was [PROPOSAL] authentication age >> >> The vision I have is that strong authentication to your IdP will be >> common in the future. >> >> The strong authentication will be supplied by a vendor that has been >> certified to provide standardized levels of authentication. The IdP >> will often NOT be the strong auth vendor. >> >> The RP will have a trust relationship with the vendor, likely through >> a vendor consortium that delegates to vendors that their product is >> certified, ie. the RP will not need to trust each vendor, just the >> certification body. >> >> I would hope that OpenID can be extended over time to be able to move >> around these types of strong auth assertions. >> >> -- Dick >> >> >> 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 >>>> 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 >>> >>> > > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Strong Authencation (was [PROPOSAL] authentication age
Dick That's sounds like a reasonable approach (if I understand what you are saying), and frankly one I hadn't considered. More importantly, it sounds like we agree that we expect this to lie in the domain of OpenID extensions and that we don't need to consider these scenarios/requirements now for the 2.0 specs? -Gabe > -Original Message- > From: Dick Hardt [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 05, 2006 9:36 AM > To: Gabe Wachob > Cc: 'Chris Drake'; 'Kevin Turner'; specs@openid.net > Subject: Strong Authencation (was [PROPOSAL] authentication age > > The vision I have is that strong authentication to your IdP will be > common in the future. > > The strong authentication will be supplied by a vendor that has been > certified to provide standardized levels of authentication. The IdP > will often NOT be the strong auth vendor. > > The RP will have a trust relationship with the vendor, likely through > a vendor consortium that delegates to vendors that their product is > certified, ie. the RP will not need to trust each vendor, just the > certification body. > > I would hope that OpenID can be extended over time to be able to move > around these types of strong auth assertions. > > -- Dick > > > 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 > >> 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 > > > > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Strong Authencation (was [PROPOSAL] authentication age
The vision I have is that strong authentication to your IdP will be common in the future. The strong authentication will be supplied by a vendor that has been certified to provide standardized levels of authentication. The IdP will often NOT be the strong auth vendor. The RP will have a trust relationship with the vendor, likely through a vendor consortium that delegates to vendors that their product is certified, ie. the RP will not need to trust each vendor, just the certification body. I would hope that OpenID can be extended over time to be able to move around these types of strong auth assertions. -- Dick 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 >> 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 > > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
