Re: Should we recommend that return_to url is always HTTPS? What about realm?

[George Fletcher]

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 a set of RPs share the same realm... but it's the best that 
can be done right now with the current spec.


While realm normalization isn't required for PPIDs to work and be 
unique, practically we'll have to do something so that users have a 
least a chance of a consistent experience. Note that this will pretty 
much require an RP to never change their realm because if they do, all 
the PPIDs will regenerate and the user's data will be lost.


Thanks,
George


John Bradley wrote:

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"  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

Re: Should we recommend that return_to url is always HTTPS? What about realm?

[John Bradley]

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"  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
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 i

Re: Should we recommend that return_to url is always HTTPS? What about realm?

[John Bradley]

Breno,

I agree completely RP discovery over https:  or with dsig is the best  
option.

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  
2.0.


John B.
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
discovery.

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   
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"  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   
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 
Subject: Should we recommend that return_to url is always HTTPS?  
What

 > about realm?

To: OpenID Specs Mailing List 
Message-ID: mailto:c62fb26e.bce7%25lshep...@facebook.com> >

 > Content-Type: multipart/related;

boundary="_004_C62FB26EBCE7ls

Re: Should we recommend that return_to url is always HTTPS? What about realm?

[Breno de Medeiros]

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
discovery.

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  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"  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  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 
>> Subject: Should we recommend that return_to url is always HTTPS? What
>  > about realm?
>> To: OpenID Specs Mailing List 
>> Message-ID: >  >
>  > Content-Type: multipart/related;
>> boundary="_004_C62FB26EBCE7lshepardfacebookcom_";
>> type="multipart/alternative"
>>
>> --_004_C62FB26EBCE7lshepardfacebookcom_
>> Content-Type: multipart/alternative;
>  > boundary="_000_C62FB26EBCE7lshepardfacebookcom_"
>>
>> --_000_C62FB26EBCE7lshepardfacebookcom_

Re: Should we recommend that return_to url is always HTTPS? What about realm?

[George Fletcher]

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"  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
 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 
> Subject: Should we recommend that return_to url is always
HTTPS? What
 > about realm?
> To: OpenID Specs Mailing List 
> Message-ID: mailto:c62fb26e.bce7%25lshep...@facebook.com> >
 > Content-Type: multipart/related;
> boundary="_004_C62FB26EBCE7lshepardfacebookcom_";
> type="multipart/alternative"
>
> --_004_C62FB26EBCE7lshepardfacebookcom_

Re: Should we recommend that return_to url is always HTTPS? What about realm?

[Luke Shepard]

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 and how 
those are actually applied in the real world. Frankly, this rule of protocol 
matching has been a royal pain when coding my OpenID relying party, making it 
more difficult than it needs to be.

For Facebook apps, we configure apps based on their domain, and don't care 
about the protocol. Similarly, I'd like to enable RPs that just don't care to 
be able to say "I just don't care - either protocol is fine".

What are the attack vectors that you worry would be exposed with this rule 
change, that aren't allowed in the current spec?

> It also compromises RP discovery.

How come? The OP can still perform discovery against the realm, the return_to 
doesn't really matter.

> A wildcard in the realm may be the better solution.  Though you may not want 
> to include matching all protocols.

Maybe the spec could declare that a wildcard only applies to HTTP and HTTPS. 
Are there others we care about?

> PPID like identifiers.

I'm not familiar with PPID, do you mind explaining how this affects the 
proposal?



On 5/14/09 9:29 AM, "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"  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  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: Lu

Re: Should we recommend that return_to url is always HTTPS? What about realm?

[John Bradley]

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"  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   
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 
> Subject: Should we recommend that return_to url is always HTTPS?  
What

 > about realm?
> To: OpenID Specs Mailing List 
> Message-ID: mailto: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:33

Re: Should we recommend that return_to url is always HTTPS? What about realm?

[Luke Shepard]

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"  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  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 
> Subject: Should we recommend that return_to url is always HTTPS? What
 > about realm?
> To: OpenID Specs Mailing List 
> Message-ID:   >
 > 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?
 >
> 

Re: Should we recommend that return_to url is always HTTPS? What about realm?

[John Bradley]

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   
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 
> Subject: Should we recommend that return_to url is always HTTPS?  
What

> about realm?
> To: OpenID Specs Mailing List 
> Message-ID: 
> 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
>
>





smime.p7s
Description: S/MIME cryptographic signature
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[John Bradley]

+1

Exactly group membership is an attribute and you may need to assert  
multiple ones at the same time.


I believe the SAML solution to the this is to use a sort of ephemeral  
for the subject of the assertion.


For openID the equivalent is not using a identifier at all.   The same  
effect can also be acived with managed  info-cards.


I think overloading the identifier with group meaning is a bad  
direction.


You could do it now,  by allowing multiple people to assert the same  
openID but that would cause all sorts of problems for RP's not  
understanding the difference.


Keeping it identity-less also allows the assertion to come from a 3rd  
party.


The group may be the only one that can say I belong to it.  They may  
have the openID's of there members and make membership assertions on  
there behalf without being a full IDP.  That could be done with AX or  
oAuth for transferring the attributes.


John Bradley
On 14-May-09, at 12:17 AM, Andrew Arnott wrote:

If an RP only needs group membership and no individual identity,  
then why assert an identifier at all?  Use OAuth or identity-less  
OpenID.  I think it would seriously cloud OpenID's Identifiers if an  
AX attribute that may or may not be noticed or included  
significantly changes what the identifier's significant meaning is.


--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the  
death your right to say it." - S. G. Tallentyre



On Wed, May 13, 2009 at 8:36 PM, SitG Admin > wrote:

Attributes like group membership belong in AX, not in the identifier.

I suspect the idea is to have a pseudonymous identifier that  
discloses nothing about the person using it other than the fact that  
they can assert the same ID each time they return to prevent  
correlation.


To further prevent correlation, the OP may wish to support users in  
authenticating as members of a group - *in such a way* that  
individual users cannot be distinguished from one another. If not  
for that, RP's could correlate information over time, establishing  
theoretical profiles of the users.


I think one compromise could be to use a traditional identifier, and  
then use AX to signal to the RP that the OP might vouch for more  
than one individual having that URI.


-Shade

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs





smime.p7s
Description: S/MIME cryptographic signature
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[Paul Madsen]

I dont think this fits either PAPE or AX.

I cant see how the privacy characteristics of an identifier are part of 
'authentication policy'. How the user authenticates to the OP is 
(mostly) orthogonal to the nature of the identifier the OP asserts.


Nor does it fit the AX description of attribute as "a unit of personal 
identity information".


regards

paul

Andrew Arnott wrote:
This scenario doesn't fit what I've always felt AX was for.  I don't 
expect a fetch request to change anything about the underlying openid 
transport other than prompting the user for information disclosure at 
the OP. 

PAPE fits better in my mind.  But again, if PAPE is the only way to 
get a psuedo-anonymous identifier, then unsolicited assertions can't 
get it right.  But if we allow PAPE requests to ask for one, and for 
it to also be discoverable via the RP return_to service in its XRDS, 
then both unsolicited assertion and RP-behind-firewall scenarios work.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the 
death your right to say it." - S. G. Tallentyre



On Wed, May 13, 2009 at 4:58 PM, David Recordon > wrote:


Does it make more sense to use a PAPE policy requesting a
pseudonymous identifier or an AX attribute requesting one?  Any of
these approaches would work, I just don't think we've mapped out
the pros/cons of each.

--David


On May 13, 2009, at 8:44 AM, George Fletcher wrote:

I don't think OpenID should specify how pseudonymous
identifiers are generated. That should be up to the OP. But I
like the idea of using a fixed URI as the claimed_id value to
specify the behavior desired by the RP. If, however, we need
to grow this to cover anonymous based identifiers (i.e. the
claims based models from earlier in this thread) then it might
make sense to look at a PAPE extension that covers the type of
identifier requested.

Thanks,
George

Nat Sakimura wrote:

Sorry for a slow response. This week is especially busy
for me...

I borrowed the notion from Austrian Citizen ID system.
In there, the services are divided into "sectors."
A sector may span several agencies.
They call ID as PIN (Personal Identification Number).

There is a secret PIN (sPIN) which is not used anywhere
but in their SmartCard.
Then, sector sepcific PIN (ssPIN) is calculated in the
manner of :

SHA1(sPIN + SectorID)

(Note, there is a bit more details but...)

I have thrown OP secret into it.
To avoid the analytic attack, I agree that it is better to use
individual secret, as some of you
points out.

Regards,

=nat

On Tue, May 12, 2009 at 5:55 PM, Dick Hardt
mailto:dick.ha...@gmail.com>> wrote:

On 12-May-09, at 1:36 AM, Nat Sakimura wrote:

Reason for using RP's Subject in XRD instead of
simply using realm is
to allow for something like group identifier.

would you elaborate on the group identifier concept?


This is just one idea. Downside of this approach
is that we need to set up a WG.

I am sure there are more ideas. It might be
possible to utilize AX
so that it will only be a profile that does not
require a WG.

So shall we start discussing which direction we
want to go forward?

sure!






___
specs mailing list
specs@openid.net 
http://openid.net/mailman/listinfo/specs


___
specs mailing list
specs@openid.net 
http://openid.net/mailman/listinfo/specs




___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
  
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs