[OpenID] [LIKELY_SPAM]Re: [LIKELY_SPAM]Re: Combining Google & Yahoo user experience research

Andrew Arnott andrewarnott at gmail.com
Tue Oct 21 15:58:54 UTC 2008


Why do we have to have http(s)://username at mailhost.com at all?  It's a funky
and unnecessary syntax.  Why can't an OpenID 3.x RP simply transport
username at mailhost.com into https://mailhost.com and do discovery on that to
find the provider endpoint, then use the username in the email as the
local_id parameter, or alternatively just use directed identity.  Since this
email would be a new support, I'd mandate https.

On Tue, Oct 21, 2008 at 7:35 AM, Peter Williams <pwilliams at rapattoni.com>wrote:

>  I've decided to follow up why I feel duped, to see if it's legit. A much
> simpler explanation is that I'm still (!) just not thinking right about
> OpenID2, yet, fundamentally (probably because I'm just too stupid, or
> perhaps fixated in older paradigms).
>
>
>
>
>
> I like the innovation. But I'd feed highly duped by the writing, as a
> security engineer, if the above holds. Folks from  the bottom of the class
> (like me) just would not make the correct interpretation of the standard, by
> themselves.
>
>
>
>
>
> In appendix A.1 (following up section 7.1) of
> http://openid.net/specs/openid-authentication-2_0.html#XRDS_Sample, we see
> evidence that an 'Identifier' is not limited to the HTTP URL scheme, in the
> line:-
>
>
>
> http://example.com/user       http://example.com/user       URL   No
> trailing slash is added to non-empty path components
>
>
>
> And, we may recall the long debate that concluded that the YADIS protocol
> (handling claimed identifiers) need NOT be conforming to the HTTP protocol
> (the whole 301 semantics issue) given the actual writeup, the intent of XRDS
> discovery (an Identifier is an "OpenID", distinct from  current webland
> ideas about URLs that are HTTP URL Scheme complying, and the Internet
> principle that (reasonable) protocol profiling of such as HTTP is always
> legitimate, anyways.
>
>
>
>
>
> Thinking now anally like a security evaluator,
> http://yadis.org/papers/yadis-v1.0.pdf reduces HTTPS to a definition that
> specifically omits the role of HTTPS and PKI ciphersuites to properly manage
> secure namespaces (which enforce the HTTP URL scheme). It basically
> references TLS (vs the SSLv3 implemented in Navigator-compatible browsers
> (Mozilla and IE)) – a dumb layer 4 security transform set that is not
> involved in URL resolution, and does not enforce navigator's "secure URLs"
> feature.
>
>
>
> At the same time, we have to note that OpenID recommends the use of https,
> during discovery. As the https run is being initiated by a server thread, vs
> a browser, given the nature of XRDS discovery, we really cannot assume that
> navigators secure URL controls are being mandated  (where "control over a
> domain-name" is asserted and validated using certification and X.509 cert
> path processing). XRDS discovery seems to simply want the server auth (and
> anti-replay) functional areas, to address the traditional crypto-level MITM
> against the DH process. OpenID2 Auth itself now replaces the secure naming
> role that certs play/ed in SSLv3-era secure URL resolution.
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081021/49d1867c/attachment-0002.htm>


More information about the general mailing list