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 solves the specific problem I described below:
RULE:
If the realm is http, then the return_to can be either http or https.
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
So, the receiver should be allowed to INCREASE its security level
from the realm, but not decrease.
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 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" <[email protected]> wrote:
I agree that RP delegation should be possible and even desirable.
To do that safely the OP needs to do RP discovery over SSL or
discover a XRD with detached sig for the RP.
Otherwise you open up Man in the Middle attacks.
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 match where the assertion is sent.
I agree that this is something that should be addressed in openID
2.1 ether for XRD with dsig or via XRDS with TLS.
John B.
On 14-May-09, at 12:24 AM, Dirk Balfanz wrote:
I don't see why a realm shouldn't be able to delegate to a
return_to URL the same way that a user id can delegate to an
OP endpoint. This includes 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., by
signing the XRD that does the delegation:
http://wiki.oasis-open.org/xri/XrdOne/XmlDsigProfile
Dirk.
On Wed, May 13, 2009 at 7:43 PM, John Bradley
<[email protected]> 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.
> I am not certain what the problem is with it being https: if
the return_to
> is https:.
> 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, [email protected] wrote:
>
> Date: Tue, 12 May 2009 23:10:38 -0700
> From: Luke Shepard <[email protected]>
> Subject: Should we recommend that return_to url is always
HTTPS? What
> about realm?
> To: OpenID Specs Mailing List <[email protected]>
> Message-ID: <c62fb26e.bce7%[email protected]
<mailto:c62fb26e.bce7%[email protected]> >
> 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=
> lways be HTTPS. Therefore, then, the realm will always need
to be HTTPS as =
> well.
>
> 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]
>
> To preserve the user experience and avoid that popup,
relying parties would=
> want to make sure their receiver is HTTPS.
>
> Alternative
>
> What do you think about loosening the realm/return_to
protocol/domain match=
> requirements?
>
> 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 al=
> low an HTTPS return_to if the realm was HTTP? It seems that
the HTTP versio=
> 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
> [email protected]
> http://openid.net/mailman/listinfo/specs
>
>
