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

John Bradley jbradley at mac.com
Thu May 14 14:19:23 UTC 2009


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 <jbradley at 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.
> > 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, specs-request at openid.net wrote:
> >
> > Date: Tue, 12 May 2009 23:10:38 -0700
> > From: Luke Shepard <lshepard at facebook.com>
> > Subject: Should we recommend that return_to url is always HTTPS?  
> What
> > about realm?
> > To: OpenID Specs Mailing List <specs at openid.net>
> > Message-ID: <C62FB26E.BCE7%lshepard at 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=
> > 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
> > specs at openid.net
> > http://openid.net/mailman/listinfo/specs
> >
> >
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090514/4e870aff/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1722 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090514/4e870aff/attachment-0002.bin>


More information about the specs mailing list