Re: Should we recommend that return_to url is always HTTPS? What about realm?

[John Bradley]

Breno,


I have been pushing people to take RP discovery seriously for some time.

Some day we should stop talking about 2.1 and start work.



John B.
On 14-May-09, at 1:18 PM, Breno de Medeiros wrote:

I agree completely RP discovery over https: or with dsig is the best option. Until then we have to live with a number of "bone-headed" things in 2.0.

The realm and return_to URL matching is the most bone-headed part of
the whole 2.0 spec.

If discovery on the realm were to produce an XRDS document that
contains a return_to URL and the return_to URL discovered matches the
one present in the authentication request, than this should be
considered a match. Prefix matching should be optional in general
(MAY) and only mandatory (MUST)  _if_ the realm does not support XRDS
discovery.

We can then separate algorithmic considerations of correctness from
security considerations. The current approach in OpenID discovery is
not particularly secure and very inflexible. Opening up this issue for
discussion by making the above-suggested minimal change can only be a
good thing.

On Thu, May 14, 2009 at 9:29 AM, John Bradley <jbrad...@mac.com> wrote:

Luke,
From a URI point of view the two URI are different and it can't
be considered steeping up security.

principals.
It also compromises RP discovery.

want to include matching all protocols.

introduces the question of realm normalization on that side.
John Bradley

On 14-May-09, at 11:25 AM, Luke Shepard wrote:


solves the specific problem I described below:

RULE:


So this would be legal:

realm: http://open.lukeshepard.com/
return_to: https://open.lukeshepard.com/openid/receiver.php

This would NOT be legal – you can’t go the other way.

realm: https://open.lukeshepard.com/
return_to: http://open.lukeshepard.com/openid/receiver.php


realm, but not decrease.


to allow realms with relative protocols, like:

explicit wildcard: *://open.lukeshepard.com
relative protocol: //open.lukeshepard.com



On 5/14/09 7:19 AM, "John Bradley" <jbrad...@mac.com> wrote:

I agree that RP delegation should be possible and even desirable.


with detached sig for the RP.

Otherwise you open up Man in the Middle attacks.


match where the assertion is sent.


for XRD with dsig or via XRDS with TLS.

John B.

On 14-May-09, at 12:24 AM, Dirk Balfanz wrote:


same way that a user id can delegate to an OP endpoint. This includes

by signing the XRD that does the delegation:
http://wiki.oasis-open.org/xri/XrdOne/XmlDsigProfile

Dirk.

I understand that is what would normally happen but it violates some basic A wijldcard in the realm may be the better solution. Though you may not In the other thread we are discussing PPID like identifiers. If they are based on the realm as people are discussing, introducing wildcards etc So, RP delegation sounds like a very general solution to the problem, and seems okay to push for. But I think there’s a much simpler solution that If the realm is http, then the return_to can be either http or https. So, the receiver should be allowed to INCREASE its security level from the This is analogous to wildcards for the protocol instead of just subdomain. Another alternative would be to have explicit wildcards for the protocol, or To do that safely the OP needs to do RP discovery over SSL or discover a XRD My point was that in the existing spec to prevent interception of tokens and attributes, the Realm that is displayed by the OP to the user needs to I agree that this is something that should be addressed in openID 2.1 ether I don't see why a realm shouldn't be able to delegate to a return_to URL the delegating from http to https, or even to a different domain altogether. Over on the XRI TC we've been talking about how to do this securely, e.g., On Wed, May 13, 2009 at 7:43 PM, John Bradley <jbrad...@mac.com> wrote:

Luke,

Realm was called trust_root in 1.1, and is a bit like audience restriction

 > in SAML.

It is the display version of the return_to, and also used for RP discovery

by the OP.

is https:.

I am not certain what the problem is with it being https: if the return_to

> There is explicitly no connection to be inferred by DNS authority between

URI differing in scheme.

Differentiating TLS by its own scheme is a decision we have to live with. The user should consent to authentication for the site they are logging

 > into.

http://open.lukesheppard.com and https://open.lukesheppard.com could
be different sites.

If the RP has both HTTP and HTTPS the best practice would be to always use

> the https: version for realm so that RP discovery cant be spoofed via

DNS.

Regards
John B.
On 13-May-09, at 2:10 AM, specs-requ...@openid.net wrote:

 >

Date: Tue, 12 May 2009 23:10:38 -0700
From: Luke Shepard <lshep...@facebook.com>

Subject: Should we recommend that return_to url is always HTTPS? What

 > about realm?

To: OpenID Specs Mailing List <specs@openid.net>
Message-ID: <c62fb26e.bce7%lshep...@facebook.com
<mailto:c62fb26e.bce7%25lshep...@facebook.com> >

 > Content-Type: multipart/related;

boundary="_004_C62FB26EBCE7lshepardfacebookcom_";
type="multipart/alternative"

--_004_C62FB26EBCE7lshepardfacebookcom_
Content-Type: multipart/alternative;

 > boundary="_000_C62FB26EBCE7lshepardfacebookcom_"

--_000_C62FB26EBCE7lshepardfacebookcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

 >

In testing my relying party, it seems clear that the return_to url SHOULD

a=

=
well.


=

lways be HTTPS. Therefore, then, the realm will always need to be HTTPS as If the return_to is HTTP, then if the response comes in the form of a POST

> from a provider that supports SSL, then the user will see a browser

warning=

for posting to an insecure form.

Here's an example:

- realm: http://open.lukeshepard.com/

 > - return_to: http://open.lukeshepard.com/openid/receiver.php

- provider endpoint: https://www.google.com/accounts/o8/ud

 >

Let's suppose that the response is too long for a GET redirect, so the

prov=
ider chooses to POST (as Google and others sometimes do).

The user would see a warning like this:

 > [cid:3325014638_6495490]

would=
want to make sure their receiver is HTTPS.

Alternative


match=

To preserve the user experience and avoid that popup, relying parties What do you think about loosening the realm/return_to protocol/ domain

 > requirements?

=

al=
low an HTTPS return_to if the realm was HTTP? It seems that the HTTP
versio=

This kinda sucks though, since it means the REALM also must be HTTPS, even though the HTTP version would seem to be "canonical". I wonder, would we

> n of the realm would be better, and should be able to mean "accept either

p=

rotocol". Or better yet, you should be able to specify a realm without a

pr=
otocol at all.

Thoughts?

 >

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

 >

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

--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

smime.p7s
Description: S/MIME cryptographic signature

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