Should we recommend that return_to url is always HTTPS? What about realm?
jbradley at mac.com
Thu May 14 17:35:50 UTC 2009
I agree completely RP discovery over https: or with dsig is the best
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.
Until then we have to live with a number of "bone-headed" things in
On 14-May-09, at 1:18 PM, Breno de Medeiros wrote:
> 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
> 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 <jbradley at mac.com>
>> From a URI point of view the two URI are different and it can't
>> be considered steeping up security.
>> I understand that is what would normally happen but it violates
>> some basic
>> It also compromises RP discovery.
>> A wijldcard in the realm may be the better solution. Though you
>> may not
>> want to include matching all protocols.
>> In the other thread we are discussing PPID like identifiers. If
>> they are
>> based on the realm as people are discussing, introducing wildcards
>> introduces the question of realm normalization on that side.
>> John Bradley
>> On 14-May-09, at 11:25 AM, Luke Shepard wrote:
>> 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
>> solves the specific problem I described below:
>> If the realm is http, then the return_to can be either http or
>> 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
>> 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" <jbradley at mac.com> 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
>> 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:
>> On Wed, May 13, 2009 at 7:43 PM, John Bradley <jbradley at mac.com>
>>> Realm was called trust_root in 1.1, and is a bit like audience
>> > in SAML.
>>> It is the display version of the return_to, and also used for RP
>>> by the OP.
>>> I am not certain what the problem is with it being https: if the
>>> 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
>> > 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
>>> 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?
>> > about realm?
>>> To: OpenID Specs Mailing List <specs at openid.net>
>>> Message-ID: <C62FB26E.BCE7%lshepard at facebook.com
>>> <mailto:C62FB26E.BCE7%25lshepard at facebook.com> >
>> > Content-Type: multipart/related;
>>> Content-Type: multipart/alternative;
>> > boundary="_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
>>> 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
>>> 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
>>> 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
>>> want to make sure their receiver is HTTPS.
>>> What do you think about loosening the realm/return_to protocol/
>> > 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
>>> low an HTTPS return_to if the realm was HTTP? It seems that the HTTP
>> > n of the realm would be better, and should be able to mean
>> "accept either
>>> rotocol". Or better yet, you should be able to specify a realm
>>> without a
>>> otocol at all.
>>> specs mailing list
>>> specs at openid.net
>> specs mailing list
>> specs at openid.net
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1722 bytes
Desc: not available
More information about the specs