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 <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. > 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-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<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= > 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@openid.net > http://openid.net/mailman/listinfo/specs > >
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
