Should we recommend that return_to url is always HTTPS? What about realm?
John Bradley
jbradley at mac.com
Thu May 14 17:58:28 UTC 2009
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 pseudonymous identifiers of any sort.
So the question is if the user doesn't want there activity
correlated, or a RP for PII legal reasons doesn't want a correlatable
identifier for the user how should the OP produce such an identifier.
Further if that type of identifier is required by the RP how would
they indicate that.
The realm would only be used by the OP to produce the "private
personal identifier".
Doing this raises additional questions about how to normalize the Realm.
Do you want to produce the same PPID for all of these?
http://example.com
http://www.example.com
https://www.example.com
http://www.example.com:80
http://www.example.com:443
https://www.example.com:443
http://www.example.com/
The RP might so to make it at least predictable there should be some
normalization rule.
I am sure Breno will jump in I know this is one of his issues.
So while all openIDs are on some sense pseudonymous, I was referring
to the pairwise ones.
Regards
John B.
On 14-May-09, at 1:17 PM, George Fletcher wrote:
> 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 spec requires the RP to do discovery on the
> pseudonymous identifier to prove that the OP that returned the
> response is authoritative for the pseudonymous identifier. With this
> mechanism, the realm should not need to match the identifier.
>
> Thanks,
> George
>
> John Bradley wrote:
>> 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 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 etc 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 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 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
>>> subdomain. 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 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
>>> <mailto:C62FB26E.BCE7%25lshepard 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
>>> >
>>> >
>>>
>>>
>>>
>>
>> =
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
-------------- 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/1eb4fe4f/attachment-0002.bin>
More information about the specs
mailing list