Negotiating a backup OP from the current OP

[SitG Admin]

I was reading this:
http://self-issued.info/?p=75
(Posted to the board@... list by Mike Jones.)

I was disturbed to see, in the first paragraph, that OpenID would be
accepted from "two" Providers; this is exactly the kind of lock-in
that will effectively *lock-OUT* the small, independent Providers.

Listing multiple OP's on the claimed Identity page may be one way to
get around that; just let the RP discard options until it runs out of
OP's or finds one it likes. But why should each user have to handle
their own complexities this way?

Couldn't an OP offer that sort of thing as a feature? Couldn't a RP
trust an OP designated by the user to at least report which *other*
OP's the user had approved for use if the RP didn't trust that OP to
authenticate the user?

I don't know what the flow would look like here, but I'm thinking
vaguely of something like the RP sending the user to the listed OP
with some arguments like "openid.untrusted", and possibly an
additional value for the preferred OP, or maybe the OP would respond
with an affirmative if it wanted to open negotiations with the RP
about what OP would be trusted. At some point the user would then be
sent to their OP, get prompted (or at least notified) about accepting
the other OP (or given a list of their options, whatever the RP would
accept), and proceed on to the new OP using the arguments that the RP
sent to their OP.

-Shade
_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Dick Hardt]

On 27-Jun-08, at 4:00 PM, SitG Admin wrote:

> I was reading this:
> http://self-issued.info/?p=75
> (Posted to the board@... list by Mike Jones.)
>
> I was disturbed to see, in the first paragraph, that OpenID would be
> accepted from "two" Providers; this is exactly the kind of lock-in
> that will effectively *lock-OUT* the small, independent Providers.

I agree.

If we want to have an open web, then we need to put the choice of OP  
into the hands of the user, not the RPs.

To do that, we need to evolve the protocol so that RPs don't feel they  
need to distinguish between OPs.

-- Dick

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Andrew Arnott]

Where does PAPE fall short of offering that?

--
Andrew Arnott

On Fri, Jun 27, 2008 at 4:50 PM, Dick Hardt <dick@...> wrote:

On 27-Jun-08, at 4:00 PM, SitG Admin wrote:

> I was reading this:
> http://self-issued.info/?p=75
> (Posted to the board@... list by Mike Jones.)
>
> I was disturbed to see, in the first paragraph, that OpenID would be
> accepted from "two" Providers; this is exactly the kind of lock-in
> that will effectively *lock-OUT* the small, independent Providers.

I agree.

If we want to have an open web, then we need to put the choice of OP
into the hands of the user, not the RPs.

To do that, we need to evolve the protocol so that RPs don't feel they
need to distinguish between OPs.

-- Dick

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[SitG Admin]

>To do that, we need to evolve the protocol so that RPs don't feel
>they need to distinguish between OPs.

Quick thought - I agree that doing this in OpenID is a good thing,
since it lifts some of the burden from RP's, but more delineation in
security for just about *any* website these days is a good thing -
most of them have a great deal of room for improvement :(

I just started to expand this quick thought and then realized it's
way too much for the time I have now. Let me say, then, that RP's
could restrict access to some operations by OP, saying "You can use
any old OP for your daily stuff, but when you want to change account
info you must use Verisign's secure authentication."

-Shade
_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Anders Feder]

Just gleaning over the draft specification, PAPE falls short when there
is no trust from the RP to the OP (which would be the majority of
cases).

fre, 27 06 2008 kl. 16:57 -0700, skrev Andrew Arnott:

> Where does PAPE fall short of offering that?
>
> --
> Andrew Arnott
>
> On Fri, Jun 27, 2008 at 4:50 PM, Dick Hardt <dick@...> wrote:
>         On 27-Jun-08, at 4:00 PM, SitG Admin wrote:
>        
>         > I was reading this:
>         > http://self-issued.info/?p=75
>         > (Posted to the board@... list by Mike Jones.)
>         >
>         > I was disturbed to see, in the first paragraph, that OpenID
>         would be
>         > accepted from "two" Providers; this is exactly the kind of
>         lock-in
>         > that will effectively *lock-OUT* the small, independent
>         Providers.
>        
>        
>         I agree.
>        
>         If we want to have an open web, then we need to put the choice
>         of OP
>         into the hands of the user, not the RPs.
>        
>         To do that, we need to evolve the protocol so that RPs don't
>         feel they
>         need to distinguish between OPs.
>        
>         -- Dick
>        
>        
>         _______________________________________________
>         general mailing list
>         general@...
>         http://openid.net/mailman/listinfo/general
>        
>
> _______________________________________________
> general mailing list
> general@...
> http://openid.net/mailman/listinfo/general

--
Anders Feder <lists.anders@...>

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Dick Hardt]

On 27-Jun-08, at 4:59 PM, SitG Admin wrote:

>> To do that, we need to evolve the protocol so that RPs don't feel  
>> they need to distinguish between OPs.
>
> Quick thought - I agree that doing this in OpenID is a good thing,  
> since it lifts some of the burden from RP's, but more delineation in  
> security for just about *any* website these days is a good thing -  
> most of them have a great deal of room for improvement :(
>
> I just started to expand this quick thought and then realized it's  
> way too much for the time I have now. Let me say, then, that RP's  
> could restrict access to some operations by OP, saying "You can use  
> any old OP for your daily stuff, but when you want to change account  
> info you must use Verisign's secure authentication."

I would agree except I would use a generic strong authentication  
instead of a vendor specific mechanism.

Similar to mechanisms today. Amazon lets you do somethings on your  
account if you have a cookie from a previous session, but requires you  
to authenticate when you want to make a purchase.

(I also don't have enough time to go deeper -- but also like to have  
small, snack size posts that are easy to digest!)

-- Dick

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Snorri]

+1... but not easy (in the future)
Do you think it's possible to establish an "OpenID Provider/Relaying Party
Policy"?
-Snorri

-----Message d'origine-----
De : general-bounces@... [mailto:general-bounces@...] De la
part de Dick Hardt
Envoyé : samedi 28 juin 2008 01:51
À : SitG Admin
Cc : general@...
Objet : Re: [OpenID] Negotiating a backup OP from the current OP

On 27-Jun-08, at 4:00 PM, SitG Admin wrote:

> I was reading this:
> http://self-issued.info/?p=75
> (Posted to the board@... list by Mike Jones.)
>
> I was disturbed to see, in the first paragraph, that OpenID would be
> accepted from "two" Providers; this is exactly the kind of lock-in
> that will effectively *lock-OUT* the small, independent Providers.

I agree.

If we want to have an open web, then we need to put the choice of OP  
into the hands of the user, not the RPs.

To do that, we need to evolve the protocol so that RPs don't feel they  
need to distinguish between OPs.

-- Dick

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general


_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Anders Feder]

fre, 27 06 2008 kl. 16:50 -0700, skrev Dick Hardt:
> If we want to have an open web, then we need to put the choice of OP  
> into the hands of the user, not the RPs.

Authentication will always be a two-party process and both parties have
to trust it, so I sincerely doubt that it could ever be up to the user
alone.

--
Anders Feder <lists.anders@...>

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Anders Feder]

I think what you are suggesting can almost be done with PAPE already. It
would just be a matter of producing the necessary policies (and get them
recognized).

For instance, VeriSign could produce a policy called "OP certified by
VeriSign" and upon seeing this request from the RP, your 'default OP'
would be able to redirect sign in to an OP it know supports the "OP
certified by VeriSign" policy.

fre, 27 06 2008 kl. 16:00 -0700, skrev SitG Admin:

> I was reading this:
> http://self-issued.info/?p=75
> (Posted to the board@... list by Mike Jones.)
>
> I was disturbed to see, in the first paragraph, that OpenID would be
> accepted from "two" Providers; this is exactly the kind of lock-in
> that will effectively *lock-OUT* the small, independent Providers.
>
> Listing multiple OP's on the claimed Identity page may be one way to
> get around that; just let the RP discard options until it runs out of
> OP's or finds one it likes. But why should each user have to handle
> their own complexities this way?
>
> Couldn't an OP offer that sort of thing as a feature? Couldn't a RP
> trust an OP designated by the user to at least report which *other*
> OP's the user had approved for use if the RP didn't trust that OP to
> authenticate the user?
>
> I don't know what the flow would look like here, but I'm thinking
> vaguely of something like the RP sending the user to the listed OP
> with some arguments like "openid.untrusted", and possibly an
> additional value for the preferred OP, or maybe the OP would respond
> with an affirmative if it wanted to open negotiations with the RP
> about what OP would be trusted. At some point the user would then be
> sent to their OP, get prompted (or at least notified) about accepting
> the other OP (or given a list of their options, whatever the RP would
> accept), and proceed on to the new OP using the arguments that the RP
> sent to their OP.
>
> -Shade
> _______________________________________________
> general mailing list
> general@...
> http://openid.net/mailman/listinfo/general
>

--
Anders Feder <lists.anders@...>

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Andrew Arnott]

Is there a way for RPs to verify an OP's claim made via PAPE?  I mean, I can write an OP that uses PAPE to say I'm Verisign authorized.  But how can an RP verify that claim?

--
Andrew Arnott

On Fri, Jun 27, 2008 at 5:43 PM, Anders Feder <lists.anders@...> wrote:

I think what you are suggesting can almost be done with PAPE already. It
would just be a matter of producing the necessary policies (and get them
recognized).

For instance, VeriSign could produce a policy called "OP certified by
VeriSign" and upon seeing this request from the RP, your 'default OP'
would be able to redirect sign in to an OP it know supports the "OP
certified by VeriSign" policy.

fre, 27 06 2008 kl. 16:00 -0700, skrev SitG Admin:

> I was reading this:
> http://self-issued.info/?p=75
> (Posted to the board@... list by Mike Jones.)
>
> I was disturbed to see, in the first paragraph, that OpenID would be
> accepted from "two" Providers; this is exactly the kind of lock-in
> that will effectively *lock-OUT* the small, independent Providers.
>
> Listing multiple OP's on the claimed Identity page may be one way to
> get around that; just let the RP discard options until it runs out of
> OP's or finds one it likes. But why should each user have to handle
> their own complexities this way?
>
> Couldn't an OP offer that sort of thing as a feature? Couldn't a RP
> trust an OP designated by the user to at least report which *other*
> OP's the user had approved for use if the RP didn't trust that OP to
> authenticate the user?
>
> I don't know what the flow would look like here, but I'm thinking
> vaguely of something like the RP sending the user to the listed OP
> with some arguments like "openid.untrusted", and possibly an
> additional value for the preferred OP, or maybe the OP would respond
> with an affirmative if it wanted to open negotiations with the RP
> about what OP would be trusted. At some point the user would then be
> sent to their OP, get prompted (or at least notified) about accepting
> the other OP (or given a list of their options, whatever the RP would
> accept), and proceed on to the new OP using the arguments that the RP
> sent to their OP.
>
> -Shade
> _______________________________________________
> general mailing list
> general@...
> http://openid.net/mailman/listinfo/general
>

--
Anders Feder <lists.anders@...>

_______________________________________________

general mailing list
general@...
http://openid.net/mailman/listinfo/general

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[SitG Admin]

Some parts of this message have been removed. Learn more about Nabble's security policy.

>Is there a way for RPs to verify an OP's claim made via PAPE?  I mean, I can write an OP that uses PAPE to say I'm Verisign authorized.  But how can an RP verify that claim?

By using Verisign's public key to decrypt the assertion?

(This assumes that Verisign can keep its private key secure.)

-Shade

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Anders Feder]

fre, 27 06 2008 kl. 18:49 -0700, skrev SitG Admin:
> By using Verisign's public key to decrypt the assertion?

Exactly. It would be a matter of defining the procedure in the policy.

--
Anders Feder <lists.anders@...>

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Drummond Reed]

This thread assumes a backup OP must be recommended from the current OP. But
OpenID users and RPs already have a mechanism for "negotiating" selection of
an OP:

a) The user lists all the OPs they use in their XRDS document (together with
any special extensions/policies each OP supports, like PAPE)

b) The RP chooses the one that best satisfies it's own policies.

=Drummond

> -----Original Message-----
> From: general-bounces@... [mailto:general-bounces@...] On
> Behalf Of SitG Admin
> Sent: Friday, June 27, 2008 4:01 PM
> To: general@...
> Subject: [OpenID] Negotiating a backup OP from the current OP
>
> I was reading this:
> http://self-issued.info/?p=75
> (Posted to the board@... list by Mike Jones.)
>
> I was disturbed to see, in the first paragraph, that OpenID would be
> accepted from "two" Providers; this is exactly the kind of lock-in
> that will effectively *lock-OUT* the small, independent Providers.
>
> Listing multiple OP's on the claimed Identity page may be one way to
> get around that; just let the RP discard options until it runs out of
> OP's or finds one it likes. But why should each user have to handle
> their own complexities this way?
>
> Couldn't an OP offer that sort of thing as a feature? Couldn't a RP
> trust an OP designated by the user to at least report which *other*
> OP's the user had approved for use if the RP didn't trust that OP to
> authenticate the user?
>
> I don't know what the flow would look like here, but I'm thinking
> vaguely of something like the RP sending the user to the listed OP
> with some arguments like "openid.untrusted", and possibly an
> additional value for the preferred OP, or maybe the OP would respond
> with an affirmative if it wanted to open negotiations with the RP
> about what OP would be trusted. At some point the user would then be
> sent to their OP, get prompted (or at least notified) about accepting
> the other OP (or given a list of their options, whatever the RP would
> accept), and proceed on to the new OP using the arguments that the RP
> sent to their OP.
>
> -Shade
> _______________________________________________
> general mailing list
> general@...
> http://openid.net/mailman/listinfo/general

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[SitG Admin]

>This thread assumes a backup OP must be recommended from the current OP. But

Must be? Not correct! I specifically acknowledged that the user COULD
simply list multiple OP's at their site, the challenge is why every
user has to be responsible for this? (Consider the low technical
knowledge of most users.)

Also consider the open nature of an XRDS document versus an OP's
ability to dole out information one piece at a time; this may enhance
privacy. If the RP says "we need an OP with these security features",
why would the RP need to know what secondary OP's the user supports
that are *not* secure enough to be used? Also, if the OP finds 4
different secondary OP's on its list that meet the requirements, why
should the *RP* be free to look among those and dictate to the user
its own favorite, when the *user* could select their own preference?

>OpenID users and RPs already have a mechanism for "negotiating" selection of

But the OpenID users do not have the ability to authorize another
party (one better at bartering) to make deals in its place. It is a
very one-sided "negotiation".

The situation you describe seems like it would very naturally give
rise to unofficial "partnerships" where only the most (commercially)
powerful OP's would consistently be in use; if the RP can select any
one out of a group of "meeting the minimum requirements" OP's, it
would logically prefer the *most* secure, yes? Or, in the case of a
tie, whichever it was allied with. But if the RP really wants that
user, shouldn't there be pressure upon the *RP* to accept the *user*?
If the RP says "We need to do it this way." and the OP says "I have
this independent OP which meets your needs.", can the RP afford to
change its mind? Revealing that it had hidden requirement (or was
blackinglisting a particular OP), without even knowing if the user
had another OP to authenticate with?

-Shade
_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Martin Atkins-2]

Drummond Reed wrote:
> This thread assumes a backup OP must be recommended from the current OP. But
> OpenID users and RPs already have a mechanism for "negotiating" selection of
> an OP:
>
> a) The user lists all the OPs they use in their XRDS document (together with
> any special extensions/policies each OP supports, like PAPE)
>
> b) The RP chooses the one that best satisfies it's own policies.
>

In practice though, most people have their XRDS document hosted by their
primary OP, so they can only publish what their OP will publish for them.

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general

[Anders Feder]

man, 30 06 2008 kl. 00:35 -0700, skrev SitG Admin:
> If the RP says "We need to do it this way." and the OP says "I have
> this independent OP which meets your needs.", can the RP afford to
> change its mind?

+1. This is a good point. I think this protocol makes for a very
balanced and transparent negotiation.

Let's say the user has an OP that will expose any phishing attempts. The
user attempt to log in to a phishers website. Now if the user is to say
"here, I have this OP, does it meet your requirements?", the phisher
will obviously just respond "no, I don't think its secure enough",
cancel the login and its phishing activities go by undetected.

But if the user can say "here, I have this phishing-resistant OP and I
know it meets your specified minimum requirements, lets go" the RP is
forced to either cancel the login, which will look odd and possibly ring
the alarm bells, or use the secure OP which will expose the phishing
attempt.

--
Anders Feder <lists.anders@...>

_______________________________________________
general mailing list
general@...
http://openid.net/mailman/listinfo/general