Re: web+ and registerProtocolHandler

Hey Adam,

Thanks for that.

I suspect that at least part of the confusion / issue here is about whether encouraging more URI schemes in general is a good idea (for some value of "good").

I.e., this is taking information that's usually expressed in the context of the link (in your example, "this is an openID endpoint") and shoving it into the link itself, via the scheme.

If I were trying to solve this problem, I'd be allowing people to register handlers for link *relations*, not schemes; has that come up at all? After all, OpenID is already coordinated through relations…

If you did that, you may or may not need to have a mechanism like web+.

Cheers,


On 17/09/2012, at 12:50 AM, Adam Barth <w3c@adambarth.com> wrote:

> On Sun, Sep 16, 2012 at 4:21 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> On 17/09/2012, at 6:55 AM, Adam Barth <w3c@adambarth.com> wrote:
>>>> I don't really know enough to be against it myself but
>>>> it does sound like a bad security idea from the mails I've
>>>> seen pass by so count me amongst those concerned about
>>>> this.
>>> 
>>> I'd caution you about forming an opinion after having heard only one
>>> side of the issue.
>> 
>> So, let's hear the other side; we're listening.
>> 
>> As Chris said a few days ago, it'd be helpful to see an end-to-end use case, to give some context.
> 
> I don't particularly have a dog in this fight.  I can try to summarize
> my understanding of the use case and contraints, but if you want to
> have a more detailed discussion, you're probably better off having it
> with folks who are more specifically interested in this topic.
> 
> Here's what the Web Applications spec says:
> 
> ---8<---
> The registerProtocolHandler() method allows Web sites to register
> themselves as possible handlers for particular schemes. For example,
> an online telephone messaging service could register itself as a
> handler of the sms: scheme, so that if the user clicks on such a link,
> he is given the opportunity to use that Web site.
> --->8---
> 
> The spec then goes on to list a number of whitelisted schemes for
> which web applications can register handlers.  My understanding is
> that the forgoing isn't controversial.
> 
> What is controversial, I believe, is that the spec also whitelists
> schemes that begin with "web+".  For example, the hypothetical
> web+openid scheme is allowed as well.
> 
> Suppose, for example, the the OpenID folks wanted to make it possible
> for a web site to easily discover the user's identity provider.
> Today, the user either needs to select from a NASCAR of IDPs or needs
> to enter something complicated, like a URL or an email address, in
> order to tell the web site about his or her IDP.  Using this
> mechanism, the OpenID folks could have IDPs register a protocol
> handler for web+openid.  Web sites could then direct the user to some
> URI in the web+openid scheme in order to ask them to authenticate.
> 
> Without an open-ended list of allowed URI scheme, using new URI
> schemes with registerProtocolHandler would require updating browsers,
> which can take a while.  With an open-ended list, folks can use these
> new URI schemes immediately.
> 
> Once we decide that we want an open-ended list of URI schemes, we can
> ask the question of how best to construct such a list.  The question
> that started this thread was why don't we just allow all URI schemes
> with the exception of a finite list of known-dangerous schemes.  As I
> explained, there's no feasible way to construct such as list as there
> are a large number of dangerous URI schemes that we need to prevent
> web sites from registering protocol handlers for.
> 
> Instead, the authors of the spec have selected an open-ended list that
> (1) doesn't contain any known dangerous URI schemes and (2) seems
> unlikely to include any currently unknown dangerous URI schemes.
> 
> This is probably going to be my last message to this thread because I
> don't view this discussion as being overly productive as it does not
> include the relevant stakeholders.  If you view the above design as
> problematic, I would encourage you to think about how to address the
> above use case in the presence of the above constraints.  If you're
> able to find a better solution, I suspect you'll have success
> convincing implementors to change direction.  If you're unable to find
> a better solution, it seems unlikely that you'll have much effect on
> what gets implemented.
> 
> Adam

--
Mark Nottingham
http://www.mnot.net/

Received on Tuesday, 18 September 2012 20:40:05 UTC