Notes From Draft 10

[Recordon, David]

While I've already incorporated many of the things I found in draft 9
into 10, there were a few things which I didn't either have the right
answer to or feel that I could make the change on my own.  I tried
reading through the draft as if I was reading it for the first time.

4.2 Integer Representations
	It seems that this section should have some sort of normative
reference, though I'm unsure what document should be referenced.

5.1 Direct Communication
	A new term "IdP endpoint URL" is introduced, is this something
that needs to be defined?

5.1.2 Direct Response
	"The content-type of the response SHOULD be "text/plain".  Is
there a case when the response is valid and it isn't text/plain?

5.1.2.1
	"A server receiving a properly formed request MUST send a
response with an HTTP status code of 200."  I trust server is referring
to an IdP given the setup in 5.1, it seems this will become clearer
along with a definition to "IdP endpoint URL".  Do we need to say
anything more than "a properly formed request"?  Seems like a forward
reference may make sense here.

6.1 Signed List Algorithm
	"1. Iterate through the list of keys to be signed in the order
they appear."  I spoke with the guys up at JanRain about this Friday in
terms of if we'd like to be more explicit in the ordering of the
arguments being signed.  Right now the algorithm works as in 1.1, where
the data is signed per the order in the openid.signed argument.  I'm
worried that this works more out of convention rather than a conscious
decision that this is the right way to do it.  While it would change
signature generation from 1.1, I'm thinking it would make sense to
change this algorithm to first alphabetically sort the arguments to make
it very clear in terms of ordering.

7.1 Procedure
	I added forward references in draft 10, though am wondering if
we should expand on each bullet in this overview.

9.1 Initiation
	Do we wish to recommend a value for the "id" attribute on the
form tag that the RP presents to the EU?  We already recommend the field
be named "openid_identifier", though I'm thinking adding the same sort
of recommendation to the form itself will better enable browser
extensions.

9.3.2 XRDS-Based Discovery
	It seems we have no normative, or even non-normative, references
to describe the XRDS document.  What is the correct OASIS spec to
reference?

3.2 Unsuccessful Response Parameters
	"If no association is established, the Relying Party MAY
continue the authentication process in stateless mode."  It doesn't seem
we ever define stateless mode or have a good place in the document to
reference here.

11.1 Request Parameters
	"Note: If this is set to the special value
"http://openid.net/identifier_select/2.0", the IdP MAY choose an
identifier that belongs to the End User."  Seems like this could be
reworded.

12 Responding to Authentication Requests
	"If the association is missing or expired, the IdP SHOULD send
the "openid.invalidate_handle" parameter of the response to the requests
"openid.assoc_handle", and SHOULD proceed as if no association handle
was specified."  Seems like this should be reworded.

13.2.2.2 Response Parameters
	"An IdP MUST NOT verify signatures for associations that have
shared MAC keys."  Seems like the definition of a "shared MAC key"
should be given at this point.

14 OpenID Authentication 1.1 Compatibility
	Should this section be combined with A.C Changes from Previous
OpenID Authentication Specification.  I think keeping them separate is
good, 14 speaks to things that affect implementers while A.C speaks to
motivations and general changes.  Just seems like a forward reference
may be useful.  Thoughts?

16 Discovering OpenID Authentication Relying Parties
	I think this section was meant to have been removed in a prior
draft.?.  In any case, I think removing it now makes sense given the
recent discussion of having the RP advertise the location of their XRDS
document as a request parameter.

Thoughts?

--David