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
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
Luke,
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 principals.
It also compromises RP discovery.
A wijldcard in the realm may be the better solution. Though
Thanks for your feedback John.
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
principals.
I'd like to see if we can find a compromise between the core principals
John,
By PPID do you mean the InfoCard unique User:RP identifier? Or are you
referring to the use of pseudonymous identifiers within OpenID?
If the latter, I didn't see the thread that was suggesting that the
pseudonymous identifiers match the realm. I would be against that
suggestion. The
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
George,
By PPID I am referring to a pairwise pseudonymous identifier like PPID
in info-card or the IDs Google uses.
The 2.0 spec talks about OP identifiers being used to allow the user
to select an identity at the OP. (badly and in a confusing way)
No place in 2.0 talks about
OK, thanks. I think I understand how you are relating realm to PPID. I
agree that we probably have to generate the PPIDs on the user:realm pair
(note, it would be very nice if realm were included in the association
request; but that's a different discussion). Even this causes some
problems if
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
