21 thoughts on “Making the Case for a New ‘acct’ URI Scheme

  1. Hey Eran,
    I’m glad to see innovation in this space, and I agree that we need to experiment and try it out. However, I believe in general that your arguments against using HTTP addresses are still pretty weak.
    1) inefficient/unpredictable. – I agree that it’s inefficient for a site to have to do a lookup on every address just to determine that it is an identifier. However, you said “we can use discovery to define such a template for each domain, which is what we are proposing for WebFinger”. I like that a lot more. And with smart caching of results, the extra HTTP hit is not required for the vast majority of lookups (which will cluster among the top providers).
    2) grandmas – really? I don’t think the average internet user has any concept of what “http” means other than “that junk in front of my website”. If we introduce “acct” it will just be ignored by most people. I’m hard-pressed to say that “acct://luke.shepard@facebook.com” is any easier than “facebook.com/luke.shepard”. I don’t think the readability can get much easier here.
    3) context sensitive – I agree with your point, but I don’t see how it’s relevant. If you want the link to say the meaning, couldn’t you just add an attribute – like or some such? isn’t inferring semantic information from web addresses sort of bad – it seems like it violates some other principles of the way the web works.
    Anyway, I’m really interested in your answers, this is an interesting discussion.

  2. The main focus here is on identifiers that look like email addresses and in many/most cases will be email addresses. We need to give web users (i.e. grandmas) something they can use. But we also need that something to identify ownership and such of web resources.
    In many ways this is the same never-ending debate on how to make OpenID usable as a global identifier, not just as an internal interop protocol to save developers time. We don’t have answers but we do have some ideas about what might work better. This is an attempt to be able to start the user discovery process with something other than a button or an HTTP URI.
    As for your specific comments:
    1. Inefficient / Unpredictable – it is not really practical to expect clients to grab a template and try to match a URI they find against it to find out if it is a URI. It is one thing to take parameters and apply them to a template. It is a completely different story to do it the other way.
    2. Yeah, really! Users should never have to type in acct:… they should type in something that makes sense to them, like their email address. But in case they end up seeing that acct:, it should look like an email address and not an HTTP URI because that is a much better pattern for people. If we end up using this by asking people to manually type acct:something, we failed.
    3. Inferring information from URIs is a bad thing, but that is limited to the authority specific part. URIs have clear structure such as the scheme and authority which you have to parse in order to access them. Having to extend basic facilities like links is not any better.
    Note that I have expressed my dissatisfaction with the rational we have for minting this new URI scheme. We know we need a URI, and we know we don’t like HTTP URIs. We also know we need a better story to make all this useful.

  3. Hmm, I don’t understand the advantage of using mailto: (or implied mailto:) and http depending on the kind of the account. The big mistake people make when they want to add a new URI scheme is that they want to represent a new way of using a relation, not a new relation. Apple’s feed:// disaster is the prime example. Should we be using image:// to link to images on HTTP servers? Obviously not.
    It should be trivial to define a way to express in DNS how to map email addresses to HTTP servers supporting OpenID. We already describe in DNS (via MX records) how to map email addresses to SMTP servers and we already use SRV records to describe how email addresses (or email-address-like identifiers) map to XMPP accounts.
    Frankly, I’m not sure why this hasn’t been completed and standardized.

  4. > This doesn’t work for humans. Why? Because as pattern seeking creatures, we can immediately identify the syntax and it makes intuitive sense to us.
    I’m really sceptical to this and I’m sure my non-geeky friends will not understand acct://3392830912@example.com syntax too. You identify this syntax because you’re a geek, my mom doesn’t make the distinction between a URL and an email adress… “merging” both is just more confusing to her.

  5. I have updates the post to remove the // from the new URI scheme syntax based on the following feedback:
    1. There is no relative path, the URI is always absolute.
    2. There is no hierarchy, therefore no need for a top level authority.
    3. mailto: and others have established a pattern that is more appropriate here.
    4. Removing the // does not change the meaning of the identifier in any way.
    5. The authority component is harder to internationalize than the path.
    6. Using // seems to only benefit the spec writer in having to write less text.

  6. The main question is, should we solve the two parts of this problem using a single identifier or two.
    The first part is coming up with an identifier people will be comfortable using as an identifier for themselves. So far people are happy to use a username, screenname, handle, or email address. Not so happy to use an HTTP URI.
    The second part is finding an identifier machines can use to associate a user account with web resources just like any other resource, link to it, describe it, etc.
    While the second part is purely technical where the challenge is scalability and efficiency, and HTTP is a valid choice, the first part is very much up in the air.
    This proposal reflects the current thinking of addressing both parts with a single identifier. Is that the best approach? I am not sure, but putting it in front of people is the only way to find out.

  7. Agree with David – I think the prevalance of phishing attacks demonstrates the general user confusion over web addresses. Many people just see “htt…….gobbledygookthatmakesitwork”. I think there’s a strong chance that something different – ANY different – from what they are used to will, if anything, make people confused. Obviously they can get used to it but still, it’s certainly not clear that this is a usability win.
    It’s definitely worth structuring some user tests over.

  8. I don’t understand why a new scheme is needed. mailto: could just as easily be used as an account identifier – e.g. mailto:bob@accounts.example.com. It needn’t be the cause of additional spam problems, because servers needn’t actually accept e-mail to these addresses.

  9. Interesting idea. I like the approach of applying finger and like the approach of using known-to-humans patterns like email addresses, which BTW are also, if I’m not mistaken by the Session Initiation Protocol (SIP) to identify (federated) users.

  10. When will OpenID & OAuth comprehend that we have SOLVED yes SOLVED this problem?

    Users LIKE our URLs and server DO get it!

    We are still waiting whilst you ignore the ONLY solution but more and more people are already listing to us and all agree.

      • While probably not as deep into this from the developer perspective as most of you, I don’t see the value in providing a scheme that allows spammers, et al, free hints at my email address.

        Currently I am unknown to many 3rd parties out there because I use an arbitrary account name rather than an email addresss as my identifier. If users are forced into using something like the acct:name@domain.com format doesn’t this give those 3rd parties a shortcut to being abe to harass me?

        Of course, if the industry would step up and provide a proper spam prevention approach (validation of sender etc) then I as an end user would be more open to using some form of one of my email address (I’m assuming I would be able to use one of my various addresses depending on the need).
        And pease don’t lump me into the “Facebook has shown us that using an email address is ok” crowd… since when did “mob rule” rule? The mob isn’t known for thinking clearly and certainly doesn’t have the ability to define technology standards for the rest of us.

  11. I am currently using XMPP JIDs in an application that is not necessarily constrained to merely XMPP. I want to expose these user ids as a URI, and I feel “acct:” could be more appropriate than “xmpp:” in my case, even though the ids are only accessible via XMPP and we have no immediate plans to support WebFinger.

    Is this acceptable usage of acct? It sounds like one part of the discussion is whether to tie it to a specific protocol or to leave it generic. I’d prefer generic, as I don’t think there is any other good URI scheme option for this otherwise.

    BTW is this blog post the canonical documentation for the acct URI scheme? Any plans for a more formal spec?


Comments are closed.