[OpenID] Reconsidering http://openid different from https://openid

[Peter Williams]

> "Identifiers distinguished only by the 'http' vs. 'https' in the

> protocol part of the URL (e.g. 'https://foo.bar.com/' vs 'http://

> foo.bar.com/") refer to the same identity. Conforming implementations

> must ensure that attackers cannot use an identifier distinguished only

> by the protocol to impersonate a victim."

 

I can type in any of the following in the openid field, and some but not
all are the same "identity" in the current concept (unless your change
is adopted). Your suggestion would address the http/https URI
overloading. It doesn't address that difference in the HXRI-resolver
form and XRI-resolver form of the same naming authority record.

 

http://xri.net/=Drummond

https://xri.net/=Drummond

=Drummond

XRI.net/=Drummond

 

This is not knew. Support for what Im re-saying is at

 

"and the Authentication i-service would somehow have to make sure that
=Drummond and http://xri.net/=Drummond are actually treated as the same
identity, not separate ones. Maybe this can be done with OpenID
delegation.

 

I am not sure if this really works, it's just an idea. 

 

Markus" [http://www.oasis-open.org/archives/xri/200704/msg00050.html]

 

----------------------

 

The issue now goes the other way around, post Auth#10, too. 

 

MyOpenID can be noting that I authorized release of attributes to
return_to=https://peter. In Auth #10+, the return_to is subject to
mandatory discovery, of course. If http://peter (not https...)
subsequently asks for those attributes, it should be treated as a
different supplicant. And Peter (the paranoid pleb) would also argue
that if the server cert of https://peter has changed since the last time
this return_to was cited as a trusted realm endpoint then once again
it's a different supplicant. Depending on the level of paranoia (and
which assurance level of a PKI-based trust network is in effect),
different cert chains supporting the same server cert can identify a
different supplicant too. 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070914/b5d3cf55/attachment-0001.htm>