gmane.comp.web.openid.general

headers Mayukh gon | 26 Jun 18:42

_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general

But note the very bias built into the definition! The fighting has moved on to the wikipedia front, now.

To many folks SSO/CCA is at most an authentication method, not a method of access control. In trusted system
evaulation criteria, one MUST distinguish between authentication and access controls. SSO is a variant
of the kerberos logon service, there! Others believe its time to discard that distinction, and let an
attributed authentication statement act as an access control ticket.

________________________________
From: general-bounces <at> openid.net [general-bounces <at> openid.net] On Behalf Of Mayukh gon [totuis <at> yahoo.com]
Sent: Thursday, June 26, 2008 9:44 AM
To: general <at> openid.net
Subject: [OpenID] OpenID and SSO

The same as what wikipedia describes it:

Single sign-on (SSO) is a method of access control<http://en.wikipedia.org/wiki/Access_control>
that enables a user to log in<http://en.wikipedia.org/wiki/Log_in> once and gain access to the
resources of multiple software systems without being prompted to log in again. Single sign-off is the
reverse process whereby a single action of signing out terminates access to multiple software systems.

As different applications and resources support different authentication mechanisms, single sign-on
has to internally translate to and store different credentials compared to what is used for initial authentication.

Basically, there is a fundamental conflict between ordinary 
SSO and OpenID, I think.

SSO is to be defined an authentication/authorization method 
to treat many sites as one. In SSO world, an end-user does 
not need to care which site it is actually visiting.

In contrast,the purpose of OpenID is to accept the result of 
authentication (assertion) from other sites. OpenID is 
designed to distinguish one site from another.

Technically, SSO requires sites to know which identity 
provider (IdP) the user belongs to without any user 
interaction. Usually this is implemented to configure only 
one IdP in sites, and as the result, the every sites make up 
a closed circle of trust.

In OpenID world, that is an open world, an user can choose 
any IdP (OpenID provider as OpenID term) and RP can accept 
assertions from hundreds of OPs. To realize this, RP should 
process the OP selection before making an authentication 
request. This means usually OpenID require an 
user-interaction as the first step.

It is true that RP can do the first user-interaction 
implicitly with cookies, or skip it always using hard-coded 
OP. But those are not typical SSO nor OpenID use-case.

I agree with your analysis on how OpenID and SSO implementations often  
work today.

Presuming one of our objectives is to simplify the user experience of  
logging into websites. From the users point of view, they  want to  
login once and be done with it. This is the user view of SSO.

OpenID does achieve this in the right  circumstances.

*if* the RP remembers the user's OpenID the first time they visit the  
site and the user only uses one OpenID on the site, then when the user  
returns, and if the RP autofills the OpenID in the form, then the user  
just has to click the submit button to login (assuming they have a  
valid session at their OP and their OP is configured to automatically  
login to that RP

Lots of assumptions in this flow, definitely room for improvement.

Question: do people think improving this is important?

On 26-Jun-08, at 6:57 PM, NISHITANI Masaki wrote:

> Basically, there is a fundamental conflict between ordinary
> SSO and OpenID, I think.
>
> SSO is to be defined an authentication/authorization method
> to treat many sites as one. In SSO world, an end-user does
> not need to care which site it is actually visiting.
>
> In contrast,the purpose of OpenID is to accept the result of
> authentication (assertion) from other sites. OpenID is
> designed to distinguish one site from another.
>
> Technically, SSO requires sites to know which identity
> provider (IdP) the user belongs to without any user
> interaction. Usually this is implemented to configure only
> one IdP in sites, and as the result, the every sites make up
> a closed circle of trust.
>
> In OpenID world, that is an open world, an user can choose
> any IdP (OpenID provider as OpenID term) and RP can accept
> assertions from hundreds of OPs. To realize this, RP should
> process the OP selection before making an authentication
> request. This means usually OpenID require an
> user-interaction as the first step.
>
> It is true that RP can do the first user-interaction
> implicitly with cookies, or skip it always using hard-coded
> OP. But those are not typical SSO nor OpenID use-case.
> _______________________________________________
> general mailing list
> general <at> openid.net
> http://openid.net/mailman/listinfo/general

On Jun 27, 2008, at 9:25 AM, Dick Hardt wrote:

> *if* the RP remembers the user's OpenID the first time they visit the
> site and the user only uses one OpenID on the site, then when the user
> returns, and if the RP autofills the OpenID in the form, then the user
> just has to click the submit button to login (assuming they have a
> valid session at their OP and their OP is configured to automatically
> login to that RP
>
> Lots of assumptions in this flow, definitely room for improvement.
>
> Question: do people think improving this is important?

Well, I certainly think that the fewer actions that a user has
to perform, whether they by physical (e.g. clicking) or cognitive
(e.g. remembering), then the more riskier and less safer the login
process is from the point of view of security.  This does assume
that the user has close to an accurate understanding of the action
she is about to perform.  The latter is a lot more difficult to
effect then most with geek training believe.

To reiterate, the main point here is that fewer user actions
imply less safety.

Eric Norman

On 27-Jun-08, at 12:25 PM, Eric Norman wrote:

>
> On Jun 27, 2008, at 9:25 AM, Dick Hardt wrote:
>
>> *if* the RP remembers the user's OpenID the first time they visit the
>> site and the user only uses one OpenID on the site, then when the  
>> user
>> returns, and if the RP autofills the OpenID in the form, then the  
>> user
>> just has to click the submit button to login (assuming they have a
>> valid session at their OP and their OP is configured to automatically
>> login to that RP
>>
>> Lots of assumptions in this flow, definitely room for improvement.
>>
>> Question: do people think improving this is important?
>
> Well, I certainly think that the fewer actions that a user has
> to perform, whether they by physical (e.g. clicking) or cognitive
> (e.g. remembering), then the more riskier and less safer the login
> process is from the point of view of security.  This does assume
> that the user has close to an accurate understanding of the action
> she is about to perform.  The latter is a lot more difficult to
> effect then most with geek training believe.
>
> To reiterate, the main point here is that fewer user actions
> imply less safety.

Interesting logic. Does that mean that more actions is more safety?  
Would the security of each action not be relevant?

Is "asasasasasasasasasasasasasasasasasas" a better password then  
"6 <at> h." because there are more keystrokes?

If you make the user jump through a bunch of hoops each time they  
authenticate, they strive to make their life simpler, not more secure.

Writing the really strong password on the sticky  right beside the   
monitor is a classic example.

-- Dick

On Jun 27, 2008, at 2:30 PM, Dick Hardt wrote:

>
> On 27-Jun-08, at 12:25 PM, Eric Norman wrote:
>
>>
>> On Jun 27, 2008, at 9:25 AM, Dick Hardt wrote:
>>
>>> *if* the RP remembers the user's OpenID the first time they visit the
>>> site and the user only uses one OpenID on the site, then when the 
>>> user
>>> returns, and if the RP autofills the OpenID in the form, then the 
>>> user
>>> just has to click the submit button to login (assuming they have a
>>> valid session at their OP and their OP is configured to automatically
>>> login to that RP
>>>
>>> Lots of assumptions in this flow, definitely room for improvement.
>>>
>>> Question: do people think improving this is important?
>>
>> Well, I certainly think that the fewer actions that a user has
>> to perform, whether they by physical (e.g. clicking) or cognitive
>> (e.g. remembering), then the more riskier and less safer the login
>> process is from the point of view of security.  This does assume
>> that the user has close to an accurate understanding of the action
>> she is about to perform.  The latter is a lot more difficult to
>> effect then most with geek training believe.
>>
>> To reiterate, the main point here is that fewer user actions
>> imply less safety.
>
> Interesting logic. Does that mean that more actions is more safety?

In general, yes. although it does depend on the difficulty that a
user has either comprehending or performing the actions.

Consider the holy triumvirate that folks like to quote about
"something you ...".  Translate each one as "something you have
to do" (an action, e.g. remember something;  pull out and show
something).  Then more actions are really just another way of
having multi-factor; that's the point of view I have.

>  Would the security of each action not be relevant?

I can't answer that unless I have a metric to measure "security".

> Is "asasasasasasasasasasasasasasasasasas" a better password then 
> "6 <at> h." because there are more keystrokes?

Sure it is -- lots better, but not directly because of the keystrokes.
Is there some metric that says otherwise?

> If you make the user jump through a bunch of hoops each time they 
> authenticate, they strive to make their life simpler, not more secure.

Methinks user will strive to make their life easier regardless.
The trick is to find a balance between easy living and security.
And don't assume that I mean to imply automation and transparency
are always the answer.  Sometimes they're appropriate, sometimes
not.  That's part of the balance problem.

Eric Norman

fre, 27 06 2008 kl. 20:20 -0500, skrev Eric Norman:
> 
> > Is "asasasasasasasasasasasasasasasasasas" a better password then 
> > "6 <at> h." because there are more keystrokes?
> 
> Sure it is -- lots better, but not directly because of the keystrokes.
> Is there some metric that says otherwise?

There is, but a better example is:

Is "polyester" a better password than "6 <at> h."?

The user has to perform more than twice as many keystroke actions! Yet a
simple dictionary attack will crack the former while the latter must be
brute-forced character-by-character.

--

-- 
Anders Feder <lists.anders <at> feder.dk>

_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general

Sorry, missed one point.

fre, 27 06 2008 kl. 20:20 -0500, skrev Eric Norman:
> Consider the holy triumvirate that folks like to quote about
> "something you ...".  Translate each one as "something you have
> to do" (an action, e.g. remember something;  pull out and show
> something).  Then more actions are really just another way of
> having multi-factor; that's the point of view I have.

I always thought multi-factor felt a little vacuous, because it depends
of the security of the individual factors (i.e. "chain as strong as
weakest link" has higher precedence), but I don't think that abstraction
is in accordance with multi-factor security at all - its quite the
opposite.

The idea behind multi-factor security is that you use tokens from
different "domains" (knowledge, physical possession, certified
credentials), on the premise that its harder to compromise several
"domains" than just a single one. That's not the same as saying that
multiple tokens from within the _same_ domain are more secure, because
once you're inside you tend to have access to it all.

--

-- 
Anders Feder <lists.anders <at> feder.dk>

>once you're inside you tend to have access to it all.

As a matter of policy, the passwords that have the greatest need to 
be secure ought to be more difficult to remember - they can't be 
written down or frequently used (the latter nullifies this and the 
latter weakens it). As a general principle, any password that 
requires you to sit there for a few minutes just to figure out what 
it was, has greater security.

The same could apply to other areas. Take the physical token you 
carry around with you all the time, versus the one that is locked up 
in the vault at a local bank - someone mugs you for the everyday 
token and doesn't get the ability to make any severe changes.

-Shade

Well, 'policy' and 'practice' are two different things.

fre, 27 06 2008 kl. 20:28 -0700, skrev SitG Admin:
> >once you're inside you tend to have access to it all.
> 
> As a matter of policy, the passwords that have the greatest need to 
> be secure ought to be more difficult to remember - they can't be 
> written down or frequently used (the latter nullifies this and the 
> latter weakens it). As a general principle, any password that 
> requires you to sit there for a few minutes just to figure out what 
> it was, has greater security.
> 
> The same could apply to other areas. Take the physical token you 
> carry around with you all the time, versus the one that is locked up 
> in the vault at a local bank - someone mugs you for the everyday 
> token and doesn't get the ability to make any severe changes.
> 
> -Shade
> 
--

-- 
Anders Feder <lists.anders <at> feder.dk>

>Well, 'policy' and 'practice' are two different things.

True, so there's the "tendency" you spoke of - but it could still be 
more secure if it didn't rely on the user to put policy into 
practice. It's getting there that is the hard part - never 
underestimate the ability of a user to screw up any measures taken to 
protect them ;)

(This, if anything, is a justification for Trusted Computing's "the 
user may not have access to their own key".)

I took the "user actions" Eric Norman spoke of to be *types* of user 
action - such as checking a URL visually (to make sure it's their 
OP), typing in their Identity, and clicking a button (though I don't 
readily see how this would be a security measure). Another question 
is whether actions that Firefox takes on behalf of the user (such as 
filling in a field or notifying the user that this site's certificate 
doesn't match) can be treated as "user actions".

How about requiring the user to authenticate using multiple *literal* 
"domains"? Any one OP normally, but 2 or more in succession (that 
have previously been used) to make changes?

At the far extreme end of the spectrum, the login process is 
initiated for any site the user visits and completed automatically 
with all requested fields.

-Shade

On Jun 27, 2008, at 10:54 PM, SitG Admin wrote:
>

> I took the "user actions" Eric Norman spoke of to be *types* of user
> action - such as checking a URL visually (to make sure it's their
> OP), typing in their Identity, and clicking a button (though I don't
> readily see how this would be a security measure).

Clicking on a button typically represents a decision on the
part of the user.  E.g. do I want this process to continue?
This is one of the cognitive actions being asked of the
user and it's usually related to security.

>  Another question
> is whether actions that Firefox takes on behalf of the user (such as
> filling in a field or notifying the user that this site's certificate
> doesn't match) can be treated as "user actions".

Just because the information received on the other end
appears to have been constructed by the user doesn't mean
that it actually was.  The user actions I'm talking about
require that the user decides to perform some task.

In the case of the certificate warning, the user decision
is whether to continue or not.

> How about requiring the user to authenticate using multiple *literal*
> "domains"? Any one OP normally, but 2 or more in succession (that
> have previously been used) to make changes?

I would like such a feature.  I doubt if any of my sisters
would think of it as anything other than harassment, though.

> At the far extreme end of the spectrum, the login process is
> initiated for any site the user visits and completed automatically
> with all requested fields.

True enough, and I'm arguing that what's described above is
at the low extreme end of the security spectrum.

Eric Norman

>Clicking on a button typically represents a decision on the
>part of the user.  E.g. do I want this process to continue?
>This is one of the cognitive actions being asked of the
>user and it's usually related to security.

By the time you're typing in the URI, you've mentally committed to 
initiating a login action. Doing something else with your hands 
(orienting a pointer on a web-button and clicking the mouse-button) 
doesn't really count as another cognitive action then; good luck 
training users to treat these as separate endeavors which require 
different analysis.

Of course, it *would* become useful if the URI was automatically 
filled in for you, but then you lose the typing action (lose one, 
gain one). I can see where the auto-complete feature would be 
desirable for SSO, but it's not a "convenience" I care for (in fact I 
find it bloody INconvenient, on par with Word's auto-correct of 
spelling and grammar - what appears on screen should be exactly what 
I'm typing).

I think users that know about keyboard shortcuts (aware they can just 
hit "return" after entering the data) will take care of it all from 
the keyboard, instead of interrupting their end of the process to 
move hand to mouse, move pointer on screen, and click.

-Shade

On 28-Jun-08, at 12:31 PM, SitG Admin wrote:
>
> I think users that know about keyboard shortcuts (aware they can just
> hit "return" after entering the data) will take care of it all from
> the keyboard, instead of interrupting their end of the process to
> move hand to mouse, move pointer on screen, and click.

I think the average user on the web is more likely  to have their hand  
on the mouse then on the keyboard.

There is a strong correlation between the web taking off and the  
availability of graphical browsers that let users click on a link in  
one document and get another document.

Remember Amazon's one-click patent? It was not the one-keystrocke- 
patent. :)

I think a solution that lets the users just click on something to  
proceed will be preferable to a keyboard shortcut.

- Dick

Nice discussion, but

Dick Hardt wrote:

> Presuming one of our objectives is to simplify the user experience of  
> logging into websites. From the users point of view, they  want to  
> login once and be done with it. This is the user view of SSO.

Methinks this premise is more likely to be: "a user would like to offer it's 
credentials once and be done with it."
Users do not want to login. Really, they don't.

Therefore you can measure the success of SSO by counting the dissapearing 
login "buttons" or "links" on websites who do offer user centric (profiling) 
services.
"Click to proceed", yes, "Login" no.

Regards, Leon

>Users do not want to login. Really, they don't.
>
>Therefore you can measure the success of SSO by counting the dissapearing
>login "buttons" or "links" on websites who do offer user centric (profiling)
>services.

A vital question here, then, is whether the user values privacy 
enough to forgo this level of convenience. Short of opting to 
automatically grant all RP requests (and never prompt user for 
re-authentication to the OP - it can still expire, just don't bother 
the *user* with renewing it), there is no way to "intelligently" 
practice selective login for the user.

>"Click to proceed", yes,

There shouldn't even be that, though. Just go to the site and see the 
page. No matter how much you abstract the process of authenticating, 
if they have to take steps to have the service recognize them then 
it's a login.

-Shade

I think the contractual and privacy issues will require a click to  
login. EU and Canadian privacy laws require the user to have consented  
to acquiring personal information. Similar to the EULA licenses users  
have to actively  do something with.

Since it is impossible to know how the user truly arrived at a page,  
and users can arrive at a page without having actively chose to, the  
site needs the user to actively do something to acknowledge they want  
to share information and  not be pseudonymous.

On 1-Jul-08, at 1:47 AM, SitG Admin wrote:

>> Users do not want to login. Really, they don't.
>>
>> Therefore you can measure the success of SSO by counting the  
>> dissapearing
>> login "buttons" or "links" on websites who do offer user centric  
>> (profiling)
>> services.
>
> A vital question here, then, is whether the user values privacy
> enough to forgo this level of convenience. Short of opting to
> automatically grant all RP requests (and never prompt user for
> re-authentication to the OP - it can still expire, just don't bother
> the *user* with renewing it), there is no way to "intelligently"
> practice selective login for the user.
>
>> "Click to proceed", yes,
>
> There shouldn't even be that, though. Just go to the site and see the
> page. No matter how much you abstract the process of authenticating,
> if they have to take steps to have the service recognize them then
> it's a login.
>
> -Shade
> _______________________________________________
> general mailing list
> general <at> openid.net
> http://openid.net/mailman/listinfo/general

Think about IP addresses: are they personal information? If so, and 
following the train of thought mentioned by Dick, a user would not be 
able to choose to share information without sharing this information.

So I guess this discussion comes down to the difference between logging 
in (offer credentials) and profiling (offer personal information).  
These two can, but do not have to be, the same: credentials are not 
necessary personal information.

"Click to proceed" would result in "profiling", not "authentication", 
so  SSO can be invisible to the user.

my 2$, --Leon.

Dick Hardt wrote:

> I think the contractual and privacy issues will require a click to 
> login. EU and Canadian privacy laws require the user to have consented 
> to acquiring personal information. Similar to the EULA licenses users 
> have to actively  do something with.
>
> Since it is impossible to know how the user truly arrived at a page, 
> and users can arrive at a page without having actively chose to, the 
> site needs the user to actively do something to acknowledge they want 
> to share information and  not be pseudonymous.
>
> On 1-Jul-08, at 1:47 AM, SitG Admin wrote:
>
>>> Users do not want to login. Really, they don't.
>>>
>>> Therefore you can measure the success of SSO by counting the 
>>> dissapearing
>>> login "buttons" or "links" on websites who do offer user centric 
>>> (profiling)
>>> services.
>>
>> A vital question here, then, is whether the user values privacy
>> enough to forgo this level of convenience. Short of opting to
>> automatically grant all RP requests (and never prompt user for
>> re-authentication to the OP - it can still expire, just don't bother
>> the *user* with renewing it), there is no way to "intelligently"
>> practice selective login for the user.
>>
>>> "Click to proceed", yes,
>>
>> There shouldn't even be that, though. Just go to the site and see the
>> page. No matter how much you abstract the process of authenticating,
>> if they have to take steps to have the service recognize them then
>> it's a login.
>>
>> -Shade
>> _______________________________________________
>> general mailing list
>> general <at> openid.net
>> http://openid.net/mailman/listinfo/general
>
>

Hello all,

I have a quick question that doesn't seem to be covered in the existing 
spec docs.

If a user enters 'yahoo.com' the OpenID discovery phase yields this xrds 
document:

<XRD>
    <Service priority="0">
      <Type>http://specs.openid.net/auth/2.0/server</Type>
      <Type>http://specs.openid.net/extensions/pape/1.0</Type>
      <URI>https://open.login.yahooapis.com/openid/op/auth</URI>
    </Service>
</XRD>

Is a Relying Party to take this as meaning that the Yahoo OpenID server 
supports all PAPE policies?

Thanks,

--
=james.tindall

> James Tindall wrote:
> 
> Hello all,
> 
> I have a quick question that doesn't seem to be covered in the existing
> spec docs.
> 
> If a user enters 'yahoo.com' the OpenID discovery phase yields this xrds
> document:
> 
> <XRD>
>     <Service priority="0">
>       <Type>http://specs.openid.net/auth/2.0/server</Type>
>       <Type>http://specs.openid.net/extensions/pape/1.0</Type>
>       <URI>https://open.login.yahooapis.com/openid/op/auth</URI>
>     </Service>
> </XRD>
> 
> Is a Relying Party to take this as meaning that the Yahoo OpenID server
> supports all PAPE policies?

It depends on what you mean by "supports all PAPE policies"? 

The XRD above simply says that the Yahoo OpenID 2.0 server supports PAPE,
which means the RP can include a PAPE request in their OpenID 2.0
authentication request to the Yahoo OP, and Yahoo will answer the request
saying which policies it did/didn't use for authentication (e.g., was it
phishing-proof or not?)

It doesn't mean that Yahoo has to support all the potential authentication
policies that the PAPE vocabulary includes.

=Drummond 

_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general

Is the yahoo limitation due to the technical nature of openid

Is it due to the open nature of the openid uci model?

Is the advice the same as given to folks who use alternative apis?

Should I tak it as given that a yahoo openid is not appropriate for concluding a $1 credit card transaction?
Even over verisign ssl?

________________________________
From: Allen Tom <atom <at> yahoo-inc.com>
Sent: Wednesday, July 02, 2008 8:24 PM
To: 'James Tindall' <james <at> atomless.com>; general <at> openid.net <general <at> openid.net>
Subject: Re: [OpenID] PAPE yahoo?

Hi James,

Yahoo supports the PAPE extension specifically to mark our assertions with NIST Auth Level 0, to indicate
that Relying Parties should not Yahoo OpenID assertions to authorize transactions of financial value,
or other high value transactions. We have this documented in our FAQ here:

http://developer.yahoo.com/openid/faq.html

Thanks,
Allen

Drummond Reed wrote:

James Tindall wrote:

Hello all,

I have a quick question that doesn't seem to be covered in the existing
spec docs.

If a user enters 'yahoo.com' the OpenID discovery phase yields this xrds
document:

<XRD>
    <Service priority="0">
      <Type>http://specs.openid.net/auth/2.0/server</Type>
      <Type>http://specs.openid.net/extensions/pape/1.0</Type>
      <URI>https://open.login.yahooapis.com/openid/op/auth</URI>
    </Service>
</XRD>

Is a Relying Party to take this as meaning that the Yahoo OpenID server
supports all PAPE policies?

It depends on what you mean by "supports all PAPE policies"?

The XRD above simply says that the Yahoo OpenID 2.0 server supports PAPE,
which means the RP can include a PAPE request in their OpenID 2.0
authentication request to the Yahoo OP, and Yahoo will answer the request
saying which policies it did/didn't use for authentication (e.g., was it
phishing-proof or not?)

It doesn't mean that Yahoo has to support all the potential authentication
policies that the PAPE vocabulary includes.

=Drummond

_______________________________________________
general mailing list
general <at> openid.net<mailto:general <at> openid.net>
http://openid.net/mailman/listinfo/general

Hi Peter,

Yahoo issues persistent browser sessions that are valid for up to 14 
days, and the Yahoo OpenID Provider does not re-prompt for the user's 
password before we send an assertion to the Relying Party. We do not 
re-prompt the user for their password in order to improve the usability 
of the service.

Generally speaking, sites that authorize financial transactions 
re-prompt the user for their password before authorizing the 
transaction, even if the user is already logged in.

We're definitely interested in seeing OpenID being used to authorize 
high value transactions, and hopefully the new PAPE extension will make 
this a reality.

In answer to your question, currently a Yahoo OpenID is not appropriate 
to protect a stored credit card number on an RP that is an online 
merchant or bank.

Allen

Peter Williams wrote:
> Is the yahoo limitation due to the technical nature of openid
>
> Is it due to the open nature of the openid uci model?
>
> Is the advice the same as given to folks who use alternative apis?
>
> Should I tak it as given that a yahoo openid is not appropriate for concluding a $1 credit card transaction?
Even over verisign ssl?
>
> ________________________________
> From: Allen Tom <atom <at> yahoo-inc.com>
> Sent: Wednesday, July 02, 2008 8:24 PM
> To: 'James Tindall' <james <at> atomless.com>; general <at> openid.net <general <at> openid.net>
> Subject: Re: [OpenID] PAPE yahoo?
>
> Hi James,
>
> Yahoo supports the PAPE extension specifically to mark our assertions with NIST Auth Level 0, to indicate
that Relying Parties should not Yahoo OpenID assertions to authorize transactions of financial value,
or other high value transactions. We have this documented in our FAQ here:
>
> http://developer.yahoo.com/openid/faq.html
>
> Thanks,
> Allen
>
>
>
>
> Drummond Reed wrote:
>
> James Tindall wrote:
>
> Hello all,
>
> I have a quick question that doesn't seem to be covered in the existing
> spec docs.
>
> If a user enters 'yahoo.com' the OpenID discovery phase yields this xrds
> document:
>
> <XRD>
>     <Service priority="0">
>       <Type>http://specs.openid.net/auth/2.0/server</Type>
>       <Type>http://specs.openid.net/extensions/pape/1.0</Type>
>       <URI>https://open.login.yahooapis.com/openid/op/auth</URI>
>     </Service>
> </XRD>
>
> Is a Relying Party to take this as meaning that the Yahoo OpenID server
> supports all PAPE policies?
>
>
>
> It depends on what you mean by "supports all PAPE policies"?
>
> The XRD above simply says that the Yahoo OpenID 2.0 server supports PAPE,
> which means the RP can include a PAPE request in their OpenID 2.0
> authentication request to the Yahoo OP, and Yahoo will answer the request
> saying which policies it did/didn't use for authentication (e.g., was it
> phishing-proof or not?)
>
> It doesn't mean that Yahoo has to support all the potential authentication
> policies that the PAPE vocabulary includes.
>
> =Drummond
>
> _______________________________________________
> general mailing list
> general <at> openid.net<mailto:general <at> openid.net>
> http://openid.net/mailman/listinfo/general
>
>
>   

Thanks for clearing that up Allen, much appreciated!

James

Allen Tom wrote:
> Hi Peter,
>
> Yahoo issues persistent browser sessions that are valid for up to 14 
> days, and the Yahoo OpenID Provider does not re-prompt for the user's 
> password before we send an assertion to the Relying Party. We do not 
> re-prompt the user for their password in order to improve the 
> usability of the service.
>
> Generally speaking, sites that authorize financial transactions 
> re-prompt the user for their password before authorizing the 
> transaction, even if the user is already logged in.
>
> We're definitely interested in seeing OpenID being used to authorize 
> high value transactions, and hopefully the new PAPE extension will 
> make this a reality.
>
> In answer to your question, currently a Yahoo OpenID is not 
> appropriate to protect a stored credit card number on an RP that is an 
> online merchant or bank.
>
> Allen
>
>
> Peter Williams wrote:
>> Is the yahoo limitation due to the technical nature of openid
>>
>> Is it due to the open nature of the openid uci model?
>>
>> Is the advice the same as given to folks who use alternative apis?
>>
>> Should I tak it as given that a yahoo openid is not appropriate for 
>> concluding a $1 credit card transaction? Even over verisign ssl?
>>
>> ________________________________
>> From: Allen Tom <atom <at> yahoo-inc.com>
>> Sent: Wednesday, July 02, 2008 8:24 PM
>> To: 'James Tindall' <james <at> atomless.com>; general <at> openid.net 
>> <general <at> openid.net>
>> Subject: Re: [OpenID] PAPE yahoo?
>>
>> Hi James,
>>
>> Yahoo supports the PAPE extension specifically to mark our assertions 
>> with NIST Auth Level 0, to indicate that Relying Parties should not 
>> Yahoo OpenID assertions to authorize transactions of financial value, 
>> or other high value transactions. We have this documented in our FAQ 
>> here:
>>
>> http://developer.yahoo.com/openid/faq.html
>>
>> Thanks,
>> Allen
>>
>>
>>
>>
>> Drummond Reed wrote:
>>
>> James Tindall wrote:
>>
>> Hello all,
>>
>> I have a quick question that doesn't seem to be covered in the existing
>> spec docs.
>>
>> If a user enters 'yahoo.com' the OpenID discovery phase yields this xrds
>> document:
>>
>> <XRD>
>>     <Service priority="0">
>>       <Type>http://specs.openid.net/auth/2.0/server</Type>
>>       <Type>http://specs.openid.net/extensions/pape/1.0</Type>
>>       <URI>https://open.login.yahooapis.com/openid/op/auth</URI>
>>     </Service>
>> </XRD>
>>
>> Is a Relying Party to take this as meaning that the Yahoo OpenID server
>> supports all PAPE policies?
>>
>>
>>
>> It depends on what you mean by "supports all PAPE policies"?
>>
>> The XRD above simply says that the Yahoo OpenID 2.0 server supports 
>> PAPE,
>> which means the RP can include a PAPE request in their OpenID 2.0
>> authentication request to the Yahoo OP, and Yahoo will answer the 
>> request
>> saying which policies it did/didn't use for authentication (e.g., was it
>> phishing-proof or not?)
>>
>> It doesn't mean that Yahoo has to support all the potential 
>> authentication
>> policies that the PAPE vocabulary includes.
>>
>> =Drummond
>>
>> _______________________________________________
>> general mailing list
>> general <at> openid.net<mailto:general <at> openid.net>
>> http://openid.net/mailman/listinfo/general
>>
>>
>>   
>
>

--

-- 

-----------------------------------------

James Tindall

http://www.atomless.com/

T : +44(0)1305 250 377
M : +44(0)7971 012 032
F : +44(0)1305 250 377

-----------------------------------------

Allen Tom <atom <at> yahoo-inc.com> writes:

> Hi Peter,
>
> Yahoo issues persistent browser sessions that are valid for up to 14 
> days, and the Yahoo OpenID Provider does not re-prompt for the user's 
> password before we send an assertion to the Relying Party. We do not 
> re-prompt the user for their password in order to improve the usability 
> of the service.
>
> Generally speaking, sites that authorize financial transactions 
> re-prompt the user for their password before authorizing the 
> transaction, even if the user is already logged in.
>
> We're definitely interested in seeing OpenID being used to authorize 
> high value transactions, and hopefully the new PAPE extension will make 
> this a reality.

Do you see a need for the RP to request from the OP to re-prompt the
user for the password?  How could you achieve that with PAPE?

This seems similar to my discussions on specs@ about a similar feature
for one-time-passwords.  If there is a way, with PAPE, for a RP to
request authentication re-prompt from the OP for passwords, it could
probably be used to re-prompt one-time-passwords too.

Thanks,
Simon

I'm unclear now on where this thread is going ... :)

fwiw: my point was that providing the user  something to click rather  
then type is more desirable -- and propose that for OpenID, letting  
the user cick something to login is a desirable end goal

wrt. below, implicit in a "Click to proceed" is telling the site that  
you are a specific entity -- so you effectively have signed on.

-- Dick

On 2-Jul-08, at 12:58 AM, Leon Kuunders wrote:

> Think about IP addresses: are they personal information? If so, and
> following the train of thought mentioned by Dick, a user would not be
> able to choose to share information without sharing this information.
>
>
> So I guess this discussion comes down to the difference between  
> logging
> in (offer credentials) and profiling (offer personal information).
> These two can, but do not have to be, the same: credentials are not
> necessary personal information.
>
>
> "Click to proceed" would result in "profiling", not "authentication",
> so  SSO can be invisible to the user.
>
>
> my 2$, --Leon.
>
>
>
> Dick Hardt wrote:
>
>> I think the contractual and privacy issues will require a click to
>> login. EU and Canadian privacy laws require the user to have  
>> consented
>> to acquiring personal information. Similar to the EULA licenses users
>> have to actively  do something with.
>>
>> Since it is impossible to know how the user truly arrived at a page,
>> and users can arrive at a page without having actively chose to, the
>> site needs the user to actively do something to acknowledge they want
>> to share information and  not be pseudonymous.
>>
>> On 1-Jul-08, at 1:47 AM, SitG Admin wrote:
>>
>>>> Users do not want to login. Really, they don't.
>>>>
>>>> Therefore you can measure the success of SSO by counting the
>>>> dissapearing
>>>> login "buttons" or "links" on websites who do offer user centric
>>>> (profiling)
>>>> services.
>>>
>>> A vital question here, then, is whether the user values privacy
>>> enough to forgo this level of convenience. Short of opting to
>>> automatically grant all RP requests (and never prompt user for
>>> re-authentication to the OP - it can still expire, just don't bother
>>> the *user* with renewing it), there is no way to "intelligently"
>>> practice selective login for the user.
>>>
>>>> "Click to proceed", yes,
>>>
>>> There shouldn't even be that, though. Just go to the site and see  
>>> the
>>> page. No matter how much you abstract the process of authenticating,
>>> if they have to take steps to have the service recognize them then
>>> it's a login.
>>>
>>> -Shade
>>> _______________________________________________
>>> general mailing list
>>> general <at> openid.net
>>> http://openid.net/mailman/listinfo/general
>>
>>
> _______________________________________________
> general mailing list
> general <at> openid.net
> http://openid.net/mailman/listinfo/general

On Tue, Jul 1, 2008 at 7:56 AM, Dick Hardt <dick <at> sxip.com> wrote:
> I think the contractual and privacy issues will require a click to
> login. EU and Canadian privacy laws require the user to have consented
> to acquiring personal information. Similar to the EULA licenses users
> have to actively  do something with.
>
> Since it is impossible to know how the user truly arrived at a page,
> and users can arrive at a page without having actively chose to, the
> site needs the user to actively do something to acknowledge they want
> to share information and  not be pseudonymous.

Good points. I had not considered those.

Does anyone have links or further info related to the potential
legislation Dick mentions?

Hans

[OpenID] OpenID and SSO

Re: [OpenID] OpenID and SSO

Re: [OpenID] OpenID and SSO

Re: [OpenID] OpenID and SSO

Re: [OpenID] OpenID and SSO

Re: [OpenID] OpenID and SSO

Re: [OpenID] OpenID and SSO

Re: [OpenID] OpenID and SSO

Re: [OpenID] OpenID and SSO

Re: [OpenID] OpenID and SSO

Re: [OpenID] OpenID and SSO

Re: [OpenID] OpenID and SSO

Re: [OpenID] OpenID and SSO

Re: [OpenID] OpenID and SSO

Re: [OpenID] OpenID and SSO

Re: [OpenID] OpenID and SSO

Re: [OpenID] OpenID and SSO

Re: [OpenID] OpenID and SSO

Re: [OpenID] OpenID and SSO

[OpenID] PAPE yahoo?

Re: [OpenID] PAPE yahoo?

Re: [OpenID] PAPE yahoo?

Re: [OpenID] PAPE yahoo?

Re: [OpenID] PAPE yahoo?

Re: [OpenID] PAPE yahoo?

Re: [OpenID] PAPE yahoo?

Re: [OpenID] OpenID and SSO

Re: [OpenID] OpenID and SSO