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

[Peter Williams]

I'll bite: since there seems real ingenuity going on, here.

Let me go through it step by step, plodding (since its all my class of brain can manage).

1. the average person thinks of email having the form: home_pw at msn.com

2. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2 defined the http/s URL required by XRDS discovery, and references host

3. http://www.ietf.org/rfc/rfc1738.txtdefined the "Common Internet Scheme Syntax", and we can also note 3.3

4. IF, and only if, OpenID conformance requires use of the HTTP scheme when performing XRDS Discovery, then http(s)://user at example.com/ is not a legal URL of said scheme.

5. If XRDS discovery uses its own scheme (that happens to look rather like the HTTP URL scheme, and specifies use of the HTTP(S) protocol) one could make a definitional stretch to allow http(s)://user at example.com


Have I just learned something about OpenID design (crafty design)? ....

That XRDS discovery uses HTTP, but resolves "identifiers" (that are not limited to the HTTP URL scheme)?

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.

If an RP can host an input that allows me to just type home_pw at msn.com, and that gets converted into http(s)://home_pw at msn.com intending said identifier to invoke law#4 at some discovery endpoint determined by the RP (with little or no relationship to msn.com), there may be a very interesting idea, indeed. Even more interesting if the users https client cert has emailAddress field with home_pw at msn.com, playing the same role for controlling secure namespaces that cn=domain-name plays for SSL server certs in the HTTP(S) URL scheme.


-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Johnny Bufu
Sent: Tuesday, October 21, 2008 1:59 AM
To: Martin Atkins
Cc: OpenID List
Subject: [LIKELY_SPAM]Re: [OpenID] Combining Google & Yahoo user experience research


On 14/10/08 03:14 PM, Martin Atkins wrote:
> I think the "resolve an email address to an XRDS document" step is the
> hard part.
[...]
>   * Do XRDS discovery at a URL formed by taking the email address domain
> and adding "http://" to the start and "/" to the end. This requires that
> whatever's declared in the XRDS file be able to map the username part
> onto a URL

Why is this part required at all, given the (mandatory support for)
OP-Identifiers in v2?


RPs can, using no more than OpenID 2.0, perform OpenID discovery on
http(s)://user at example.com/ and obtain an OP-Identifier, e.g.
https://example.com/op/. (RPs really don't need a user-specific
identifier at request time.)

It is then trivial for the OP to figure out the username / identifier
*post* authentication.

In effect:
a) RPs don't need to care about email-to-URL translation
b) OPs can translate emails to URLs as each of them sees fit
c) email-to-URL translation doesn't even need to be specified or
standardized (not for OpenID, anyhow)
d) users can have their browser fill in their OP credentials and
complete authentication

> which has not yet been handled. It also requires all email
> domains to have HTTP servers associated with them and hard-codes the
> root path.

Yes, but why is this a (big) issue? If they are email providers for the
main domain, it should be fairly easy to configure discovery at the
domain root. And HTTP/XRDS seem to be the overall preferred choices for
discovery.

> It also does not allow for the use of HTTPS.

There's no stopping users from entering https://user@example.com/; not
very friendly, but not any less friendly than with any other HTTP(s)
identifier either. (The OP-Endpoint and claimed identifier can be HTTPS,
of course.)


Johnny
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general