on OpenID: Specs

Comments  on http://www.openid.net/specs.bml 
(07/05/05 16:43:34) as I read it,
lest I forget them before I get a chance to edit them into
a form that the developers are likely to find most helpful...

"Identity
        An identity in OpenID is just a URL. The whole flow of the
        OpenID protocol is about proving that an End User is (owns) a
        URL. "

Stay clear of the "user is URL" pun. Suggest:

	An identity in OpenID is just a page with an http/https URL.
	The whole flow of the OpenID protocol is about proving that
	an End User owns a page.

"User-Agent
        The End User's web browser. No special plug-ins or JavaScript
        required."

What about cookies? What capabilities _are_ required?
http 1.0 and the ability to parse an HTML head are what
I can see so far...

"Consumer
        The website that wants to consume the End User's identity."

I think traditional security parlance is "relying party".

"Server
        Also called "identity server". This is the URL that the End User
        has declared is authorative over their identity. The End User
        puts this declaration in their identity URL's HTML <head>. The
        consumer discovers the identity server from the user's identity
        URL ..."

more use/mention puns. Suggest:

Server
        Also called "identity server". This is the resource that the
        End User has appointed to represent them in openID
        authentication.
        The End User appoints a server by referring to it using an HTML
        <link> element in their identity page. The consumer discovers
        the identity server from the user's identity page ..."

Substantive:

| <link rel="openid.server" href="http://bob.com/openid-server.app">

The link relationship name can and should be grounded in URI space
just like all the other stuff, ala:

	<head profile="http://www.openid.net/vocab">
	  <link rel="server" href="http://bob.com/openid-server.app" />
	</head>

or just leave the rel field as is, though it's redundant...

	<head profile="http://www.openid.net/vocab">
	  <link rel="openid.server"
		 href="http://bob.com/openid-server.app" />
	</head>

Likewise openid.server, openid.delegate .


| The openid.server URL should be absolute. OpenID consumers are
| not required to resolve relative URLs.

bad idea... will make OpenID difficult to standardize.
Plus, I expect implementations will diverge, leading
to security holes (witness different handling of multiple
content-length header fields in HTTP leading to cache
poisoning and cross-site scripting).

(hmm... http://www.w3.org/TR/webarch/#uri-refs should say why
disallowing relative URIs is a bad idea, but
doesn't. perhaps another bit of /DesignIssues/ that should
be scrubbed by the TAG... section "Document sets and relative
addressing" of http://www.w3.org/DesignIssues/Model.html )


section Delegating auth... I'd like to get all the way thru
the protocol at one level before going into refinements
like this.

"The delegate identity URL must be canonical." er... hmm...
strike "canonical" and just leave...

"The delegate identity URL will not be further processed by the
consumer, so be sure it has the "http://" and trailing slash, if there's
no path component."

but then fold in absolutizing.


"Note that the user can leave off "http://" and the trailing "/". A
consumer must canonicalize the URL"

where is it specified how to canonicalize the URL?

redirects... hmm...


"It's also recommend that the form field be named openid_url so browsers
auto-complete user's URLs between different sites, in the same way the
ecommerce world tends to use conventions like "address1" and
"address2"."

Anybody got a spec or some documentation on that sort of auto-complete?
I remember a set of field names recommended for e-commerce use.
(I remember reviewing the spec and suggesting a way to ground them
in URI space...)


"Now the consumer site must fetch the document (perhaps from cache) that
the user entered."

another use/mention pun. The user entered a URL, which is not a document
but a reference to a document. Suggest:

	... that the user referred to.


Since "... the user could be malicious..." change "consumer site must"
to "consumer site should".

"Step 4: [optional] Consumer site establishes a relationship with the
server URL"

another pun. the relationship is with the server, not the server URL.

"The shared secret can be exchanged either in plain-text or encrypted
with a Diffie-Hellman-negotiated secret."

I gather that's one of the standard crypto patterns; but it's not
in my vocabulary. I'll have to study it.

In step 5 "By sending the User-Agent there, the user's cookies and
whatever other login credentials are sent back to their trusted identity
server."

what credentials? [I think I know now, but I'm sure I didn't the
1st time I read this, and I didn't learn it from this spec.]


"The server does its work, appends its response onto your supplied
return_to URL, and sends the user-agent back at you."

Too many pronouns... should be more clear that the consumer
supplies a return_to url when redirecting the user agent
to the identity server.

And the whole nature of the response is completely implicit
(at least in this section of the spec).

Exactly *what credentials* are presented to the consumer/relying party?

"The consumer's public key. Required if using DH-SHA1 session_type."

Hmm... so unless we're happy with cleartext shared "secrets,"
the consumer needs a public key. hmm...

The "Required if using DH-SHA1 session_type" stuff is kinda awkward.
I think it would be more straightforward to have two modes:
	associate_clear()
and
	associate_dh(modulus, gen, consumer_public)


This seems to be at the core of the spec...

[[
The exact question is: "Does the user logged in to your site own this
URL, and do they allow the trust_root (and therefore the return_to URL)
to know that?"
]]

but it's still not clear to me what "the user logged in to your site"
refers to. Perhaps it refers to whatever user is associated
with the user agent involved in this HTTP transaction?

Also... why the "and do they allow the trust_root..." part? What's
the risk of having the server authenticate to every party
that asks? I have a vague feeling of an answer, but I think
it's worth writing down.


re...
"Consumer must use dumb mode (check_authentication mode) if an
assoc_handle isn't provided."

perhaps you mean

  Consumer is using dumb mode (check_authentication mode) if
  an assoc_handle isn't provided.


and I think maybe overloading things like this is more confusing
than it's worth. Complexity too often leads to security holes.


"The return_to URL must descend from the trust_root"

That's a novel notion. Deserves many test cases.


Mode: check_authentication i.e. dumb mode... not sure I
understand the motivation. hmm.



"Identity URL: 255 max bytes"

??? why? Why these limits at all? If they're to prevent DOS
attacks something more like 4K is the norm these days, I think.





-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Tuesday, 5 July 2005 22:38:52 UTC