Simplifying OpenId
S. Alexander Jacobson
alex at alexjacobson.com
Mon Jan 9 20:04:34 UTC 2006
> if (3), then why not just document <link rel= ...> tags and each protocol can
> work on solving all the issues in their own way?
On reflection, I don't get the use of <link rel...> tags and homepage
URLs. Email addresses already the de-facto Internet standard for user
identity. We should be enhancing use of this namespace rather than
creating new ones. Here is the obvious protocol for authenticating
email addresses:
1. User supplies email address to consumer site.
2. Consumer site looks up UserId DNS record for email address domain name.
(Note: I don't think UserId records need to have priorities like MX
records)
3. If UserId record is absent/broken, send email with a validation URL.
If UserID DNS record is present, consumer site posts to UserID_URL:
POST UserID_URL
content-type: application/x-www-form-urlencoded
email=user at domain&is_email=is_email_url
201 CREATED
Location: redirectURL
4. Consumer redirects user to redirectURL and grants authentication
if it receives a GET is_email_url
Advocacy:
* All internet users have email addresses. Users without email
addresses can safely be ignored.
* Email addresses designed to be easy to type (much less
punctuation!). URLs are really verbose for manually entered data.
(If you don't require http:// or https:// in URLs then you open up
substantial ambiguity!)
* Email addresses imply both identity and authentication. Homepages
imply nothing. Expecting most users to understand the difference
between homepages with appropriate link tags and homepages that
don't seems lik a tall order.
* Most users do NOT currently have homepages. Users without homepages
need to be supported. Absent URI or email addresses, there is no
global namespace. Per site identity namespace fragmentation limits
interoperability.
* DNS is designed for exactly this sort of directory lookup. Multiple
link tags in ill-formed HTML create interesting opportunities for
ambiguity. Moreover, requiring that homepages be HTML is just poor
design. We should not prohibit flash homepages or pages with
some other XML content-type styled by XSLT to generate HTML.
-Alex-
______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
On Mon, 9 Jan 2006, Dick Hardt wrote:
> You may be successful in communicating the answer, but we may still disagree
> on the approach. :-)
>
> Right now, I don't understand enough about how YADIS does what you hint at to
> even comment on the approach. I see three possible reasons on why I don't
> understand:
>
> 1) I am daft and just don't get how YADIS provides a "clean foundation" by
> reading the documentation
>
> 2) the conversation happened, everyone on the list is aware, it is just not
> well documented
>
> 3) YADIS is a method of discovering the most appropriate protocol to use, per
> the web page http://yadis.org/wiki/Main_Page
>
> "YADIS is a service discovery system allowing relying parties (aka identity
> consumers or membersites) to determine automatically, without end-user
> intervention, the most appropriate protocol to use."
>
>
> If (1), then perhaps someone can make it less abstract and real for me.
>
> if (2), then perhaps someone can document it, useful for all
>
> if (3), then why not just document <link rel= ...> tags and each protocol can
> work on solving all the issues in their own way?
>
> -- Dick
>
>
> On 9-Jan-06, at 10:34 AM, Johannes Ernst wrote:
>
>> So I take it, once we successfully communicated the answer to this question
>> to you, you'll be joining YADIS and help make it a success?
>>
>> On Jan 8, 2006, at 11:35, Dick Hardt wrote:
>>
>>> I don't see the path for how YADIS provides a "clean foundation" for
>>> building user-controlled identity. Would you elaborate on that Johannes?
>>>
>>> I get the protocol discovery, but still think that <link rel= > works fine
>>> for that.
>>>
>>> btw: if the value of rel was a URI, then the name space issue of what the
>>> <link> tag is all about is dealt with.
>>>
>>> On 6-Jan-06, at 4:49 PM, Johannes Ernst wrote:
>>>
>>>> Exactly, why do something cleanly if a hack is just half as good? ;-)
>>>>
>>>> But for those on this list who are still puzzled by this question:
>>>> because YADIS provides a clean foundation to build on top of.
>>>> Authentication against a website -- like OpenID does today and LID and
>>>> friends -- is probably somewhere in the area of 1% of what the identity
>>>> visionaries (Google "identity gang") are envisioning that user-controlled
>>>> identity will turn into:
>>>>
>>>> Disintermediating eBay would be closer to the 100% than the 0%, and
>>>> that's only one of the examples.
>>>>
>>>> And one can't hope to build the 100% if one starts kludging after 1% of
>>>> the work is done. So that's why we all agree that YADIS is needed.
>>>>
>>>> (Sorry if you think that I'm continually stating and restating the very
>>>> very obvious, I'm an earthling after all, dear Ford Prefect)
>>>>
>>>> On Jan 6, 2006, at 16:37, Martin Atkins wrote:
>>>>
>>>>> Johannes Ernst wrote:
>>>>>>
>>>>>> Let's define yourself a new YADIS capability ... and you are instantly
>>>>>> able to participate in the same framework. That doesn't mean that your
>>>>>> new SSO can instantly be used to log into LiveJournal -- but it means
>>>>>> it opens up a defined path for Relying Parties to recognize "your"
>>>>>> URLs
>>>>>> and do something smart with it...
>>>>>>
>>>>>
>>>>> Of course, the same could be said for adding an element to the HTML
>>>>> HEAD:
>>>>> <link rel="alexid.server" href="http://www.not-an-openid-server.com/">
>>>>>
>>>>> Why do we need YADIS, again? :)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> (I'm just joking, by the way!)
>>>>
>>>> Johannes Ernst
>>>> NetMesh Inc.
>>>>
>>>> <lid.gif>
>>>> http://netmesh.info/jernst
>>>>
>>>>
>>>>
>>>>
>>
>> Johannes Ernst
>> NetMesh Inc.
>>
>> <lid.gif>
>> http://netmesh.info/jernst
>>
>>
>>
>>
>
> ** CRM114 Whitelisted by: dick at sxip.com **
>
More information about the yadis
mailing list