No subject
Fri Apr 24 22:39:51 UTC 2009
ed steeping up security.<BR>
<BR>
I understand that is what would normally happen but it violates some basic =
principals.<BR>
<BR>
It also compromises RP discovery. <BR>
<BR>
A wijldcard in the realm may be the better solution. Though you may n=
ot want to include matching all protocols.<BR>
<BR>
In the other thread we are discussing PPID like identifiers. If=
they are based on the realm as people are discussing, introducing wi=
ldcards etc introduces the question of realm normalization on that side.<BR=
>
<BR>
John Bradley<BR>
<BR>
<BR>
On 14-May-09, at 11:25 AM, Luke Shepard wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'> So, RP delegation sounds like a very gener=
al solution to the problem, and seems okay to push for. But I think there&#=
8217;s a much simpler solution that solves the specific problem I described=
below:<BR>
<BR>
RULE:<BR>
If the realm is http, then the return_to can be either ht=
tp or https.<BR>
<BR>
So this would be legal:<BR>
<BR>
realm: <B>http</B>://open.lukeshepard.com/<BR>
return_to: <B>https</B>://open.lukeshepard.com/openid/receiver.php<BR=
>
<BR>
This would NOT be legal – you can’t go the other way.<BR>
<BR>
realm: <B>https</B>://open.lukeshepard.com/<BR>
return_to: <B>http</B>://open.lukeshepard.com/openid/receiver.php<BR>
<BR>
So, the receiver should be allowed to INCREASE its security level fro=
m the realm, but not decrease.<BR>
<BR>
This is analogous to wildcards for the protocol instead of just subdo=
main. Another alternative would be to have explicit wildcards for the proto=
col, or to allow realms with relative protocols, like:<BR>
<BR>
explicit wildcard: *://open.lukeshepard.com<BR>
relative protocol: //open.lukeshepard.com<BR>
<BR>
<BR>
<BR>
On 5/14/09 7:19 AM, "John Bradley" <<a href=3D"jbradley@=
mac.com">jbradley at mac.com</a>> wrote:<BR>
<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'>I agree that RP delegation should be possib=
le and even desirable.<BR>
<BR>
To do that safely the OP needs to do RP discovery over SSL or discove=
r a XRD with detached sig for the RP.<BR>
<BR>
Otherwise you open up Man in the Middle attacks. <BR>
<BR>
My point was that in the existing spec to prevent interception of tok=
ens and attributes, the Realm that is displayed by the OP to the user=
needs to match where the assertion is sent.<BR>
<BR>
I agree that this is something that should be addressed in openID 2.1=
ether for XRD with dsig or via XRDS with TLS.<BR>
<BR>
John B.<BR>
<BR>
On 14-May-09, at 12:24 AM, Dirk Balfanz wrote:<BR>
<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'>I don't see why a realm shouldn't be able t=
o delegate to a return_to URL the same way that a user id can delegate to a=
n OP endpoint. This includes delegating from http to https, or even to a di=
fferent 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: <a =
href=3D"http://wiki.oasis-open.org/xri/XrdOne/XmlDsigProfile">http://wiki.o=
asis-open.org/xri/XrdOne/XmlDsigProfile</a><BR>
<BR>
Dirk.<BR>
<BR>
On Wed, May 13, 2009 at 7:43 PM, John Bradley <<a href=3D"jbradley=
@mac.com">jbradley at mac.com</a>> wrote:<BR>
> Luke,<BR>
> Realm was called trust_root in 1.1, and is a bit like audience r=
estriction<BR>
> in SAML. <BR>
> It is the display version of the return_to, and also used for RP=
discovery<BR>
> by the OP.<BR>
> I am not certain what the problem is with it being https: if the=
return_to<BR>
> is https:.<BR>
> There is explicitly no connection to be inferred by DNS au=
thority between<BR>
> URI differing in scheme. <BR>
> Differentiating TLS by its own scheme is a decision we have to l=
ive with.<BR>
> The user should consent to authentication for the site they are =
logging<BR>
> into. <BR>
> <a href=3D"http://open.lukesheppard.com">http://open.lukesheppar=
d.com</a> and <a href=3D"https://open.lukesheppard.com">https://open.lukesh=
eppard.com</a> could<BR>
> be different sites.<BR>
> If the RP has both HTTP and HTTPS the best practice would be to =
always use<BR>
> the https: version for realm so that RP discovery cant be =
spoofed via DNS.<BR>
> Regards<BR>
> John B.<BR>
> On 13-May-09, at 2:10 AM, <a href=3D"specs-request at openid.net">s=
pecs-request at openid.net</a> wrote:<BR>
><BR>
> Date: Tue, 12 May 2009 23:10:38 -0700<BR>
> From: Luke Shepard <<a href=3D"lshepard at facebook.com">lshepar=
d at facebook.com</a>><BR>
> Subject: Should we recommend that return_to url is always HTTPS?=
What<BR>
> about realm?<BR>
> To: OpenID Specs Mailing List <<a href=3D"specs at openid.net">s=
pecs at openid.net</a>><BR>
> Message-ID: <<a href=3D"C62FB26E.BCE7%lshepard at facebook.com">=
C62FB26E.BCE7%lshepard at facebook.com</a> <<a href=3D"mailto:C62FB26E.BCE7=
%25lshepard at facebook.com">mailto:C62FB26E.BCE7%25lshepard at facebook.com</a>&=
gt; ><BR>
> Content-Type: multipart/related;<BR>
> boundary=3D"_004_C62FB26EBCE7lshepardfacebookcom_";<BR=
>
> type=3D"multipart/alternative"<BR>
><BR>
> --_004_C62FB26EBCE7lshepardfacebookcom_<BR>
> Content-Type: multipart/alternative;<BR>
> boundary=3D"_000_C62FB26EBCE7lshepardfacebookcom_&quo=
t;<BR>
><BR>
> --_000_C62FB26EBCE7lshepardfacebookcom_<BR>
> Content-Type: text/plain; charset=3D"iso-8859-1"<BR>
> Content-Transfer-Encoding: quoted-printable<BR>
><BR>
> In testing my relying party, it seems clear that the return_to u=
rl SHOULD a=3D<BR>
> lways be HTTPS. Therefore, then, the realm will always need to b=
e HTTPS as =3D<BR>
> well.<BR>
><BR>
> If the return_to is HTTP, then if the response comes in the form=
of a POST =3D<BR>
> from a provider that supports SSL, then the user will see =
a browser warning=3D<BR>
> for posting to an insecure form.<BR>
><BR>
> Here's an example:<BR>
><BR>
> - realm: <a href=3D"http://open.lukeshepard.com/">http://open.lu=
keshepard.com/</a><BR>
> - return_to: <a href=3D"http://open.lukeshepard.com/openid=
/receiver.php">http://open.lukeshepard.com/openid/receiver.php</a><BR>
> - provider endpoint: <a href=3D"https://www.google.com/accounts/=
o8/ud">https://www.google.com/accounts/o8/ud</a><BR>
><BR>
> Let's suppose that the response is too long for a GET redirect, =
so the prov=3D<BR>
> ider chooses to POST (as Google and others sometimes do).<BR>
><BR>
> The user would see a warning like this:<BR>
><BR>
> [cid:3325014638_6495490]<BR>
><BR>
> To preserve the user experience and avoid that popup, relying pa=
rties would=3D<BR>
> want to make sure their receiver is HTTPS.<BR>
><BR>
> Alternative<BR>
><BR>
> What do you think about loosening the realm/return_to protocol/d=
omain match=3D<BR>
> requirements?<BR>
><BR>
> This kinda sucks though, since it means the REALM also must be H=
TTPS, even =3D<BR>
> though the HTTP version would seem to be "canonical". =
I wonder, would we al=3D<BR>
> low an HTTPS return_to if the realm was HTTP? It seems that the =
HTTP versio=3D<BR>
> n of the realm would be better, and should be able to mean=
"accept either p=3D<BR>
> rotocol". Or better yet, you should be able to specify a re=
alm without a pr=3D<BR>
> otocol at all.<BR>
><BR>
> Thoughts?<BR>
><BR>
> _______________________________________________<BR>
> specs mailing list<BR>
> <a href=3D"specs at openid.net">specs at openid.net</a><BR>
> <a href=3D"http://openid.net/mailman/listinfo/specs">http://open=
id.net/mailman/listinfo/specs</a><BR>
><BR>
><BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'> <BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>
--_000_C6319712BECClshepardfacebookcom_--
More information about the specs
mailing list