RE: Re[2]: Strong Authencation (was [PROPOSAL] authentication age

2006-10-06 Thread Granqvist, Hans
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

2006-10-06 Thread Martin Atkins
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

2006-10-05 Thread Dick Hardt
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

2006-10-04 Thread Chris Drake
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

2006-10-04 Thread Drummond Reed
+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

2006-10-02 Thread Kevin Turner
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


[PROPOSAL] authentication age

2006-09-30 Thread Dick Hardt
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