RE: DRAFT 11 -> FINAL? openid2

[Manger, James H]

Supporting point 2 (user with a v1 OP and a *separate* v2 OP) seems a bit 
unnecessary. A single OP can support v1 and v2 RPs at the same time. Point 2 is 
the sort of corner-case that can be supported by a yardis file, but needn’t be 
supported by the simple HTML discovery alternative. 
My vote would be to keep openid.server and openid.delegate (instead of 
openid2.provider and openid2.local_id) and add openid.version.

P.S. The spec should talk about , instead of , elements. It 
does this in the §A.4 “HTML Identifier Markup” example, but not in §7.3.3 
“HTML-based discovery”.  Version 1.1 used ; HTML is case-insensitive so 
 is ok; XHTML is case-sensitive so  is not acceptable.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt
Sent: Wednesday, 31 January 2007 12:50 PM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: DRAFT 11 -> FINAL?

On 1/30/07, Recordon, David <[EMAIL PROTECTED]> wrote:
> Yeah, I'm not a big fan of openid2.* though it was the simplest method
> of fixing up HTML discovery to work with multiple protocol versions.  I
> know Josh thought about this more than I did though.

1. Before authentication is initiated, the RP needs to determine what
the protocol is. This could be done via discovery on the OP, but there
has been general rejection of adding yet another discovery step.

2. A user may have one service that provides OpenID 1 and another that
provides OpenID 2. If this is the case, then the version information
needs to be bound to the link tag that contains the information.

Given (1), the information needs to be embedded in the HTML markup.
Given (2), the information needs to be tied to the specific link tag.

For example:

  http://op.example.com/openid1";>
  http://op.example.com/openid2";>

vs.
  http://op.example.com/openid1";>
  http://op.example.com/openid2";>
  http://specs.openid.net/auth/2.0";>

While it is true that since the link relationship names changed, the
"openid2" is technically redundant, I think it is much clearer to
everybody what is going on if the link relationship contains the
version number. If the protocol version were to keep changing, I'd
argue for a different solution.

Josh
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: DRAFT 11 -> FINAL?

[Rowan Kerr]

On 1/31/07, Recordon, David <[EMAIL PROTECTED]> wrote:
> I'm happy changing it from "AJAX".  I think it was originally used since
> AJAX is a bit overloaded already and people normally understand the
> "flashy non-reloading" sort of thing when saying it.

I suppose some people might, but for a developer (the kind of people
most likely to end up implementing the spec), AJAX has a specific definition,
and implies specific techniques that cannot actually be used with OpenID.

Or perhaps I'm being too pedantic but there must be a more general term
that wouldn't have the potential to cause such confusion.

-Rowan
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: DRAFT 11 -> FINAL?

[Recordon, David]

I'm happy changing it from "AJAX".  I think it was originally used since
AJAX is a bit overloaded already and people normally understand the
"flashy non-reloading" sort of thing when saying it.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Rowan Kerr
Sent: Wednesday, January 31, 2007 12:50 PM
To: specs@openid.net
Subject: Re: DRAFT 11 -> FINAL?

On 1/31/07, Martin Atkins <[EMAIL PROTECTED]> wrote:
> I think the spec is misusing the AJAX abbreviation a bit here, since 
> the usual approach to doing this doesn't involve XMLHttpRequest at 
> all, but instead works something like this:

*snip*

Yeah I've implemented a pure javascript demo this way (which works if
the OP does a http redirect back to the RP instead of submitting a
form).


> So no, this isn't really AJAX in the usual sense. As you noted, you 
> can't do OpenID Auth client-side with XMLHttpRequest because of the 
> same-origin restriction. You also can't do OpenID on the server 
> because then the user's session cookie won't end up at the OP during 
> the request. It still achieves the desired effect of doing an OpenID 
> auth request without disturbing the current page, though.

So should wording other than AJAX be used in the spec?
Or do we just point to an explanation on the wiki.

-Rowan
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: DRAFT 11 -> FINAL?

[Rowan Kerr]

On 1/31/07, Martin Atkins <[EMAIL PROTECTED]> wrote:
> I think the spec is misusing the AJAX abbreviation a bit here, since the
> usual approach to doing this doesn't involve XMLHttpRequest at all, but
> instead works something like this:

*snip*

Yeah I've implemented a pure javascript demo this way (which works if
the OP does a http redirect back to the RP instead of submitting a
form).


> So no, this isn't really AJAX in the usual sense. As you noted, you
> can't do OpenID Auth client-side with XMLHttpRequest because of the
> same-origin restriction. You also can't do OpenID on the server because
> then the user's session cookie won't end up at the OP during the
> request. It still achieves the desired effect of doing an OpenID auth
> request without disturbing the current page, though.

So should wording other than AJAX be used in the spec?
Or do we just point to an explanation on the wiki.

-Rowan
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: DRAFT 11 -> FINAL?

[Rowan Kerr]

On 1/30/07, Josh Hoyt <[EMAIL PROTECTED]> wrote:
*snip*
> While it is true that since the link relationship names changed, the
> "openid2" is technically redundant, I think it is much clearer to
> everybody what is going on if the link relationship contains the
> version number. If the protocol version were to keep changing, I'd
> argue for a different solution.

Sure, that's good enough reason. Since html discovery is
not really the preferred method anyway, I don't think the
openid2.* links should stand in the way of finalizing the spec :)

-Rowan
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: DRAFT 11 -> FINAL?

[Martin Atkins]

Rowan Kerr wrote:
> 
> Also, the spec mentions AJAX interactions, but I don't see how you can
> actually use AJAX with OpenID, since none of the responses are in XML
> format .. it relies entirely on GET or POST redirection, not to
> mention that you have to make cross-domain requests which
> XmlHttpRequest will not do without extra security privileges.
> 

I think the spec is misusing the AJAX abbreviation a bit here, since the 
usual approach to doing this doesn't involve XMLHttpRequest at all, but 
instead works something like this:

  * Create hidden IFRAME in document and point it at OpenID RP endpoint 
on your site.

  * RP endpoint redirects (in the IFRAME) to the OP with 
mode=checkid_immediate, which instructs the OP to fail immediately if it 
needs to display any UI.

  * If OP needs to display an "are you sure?" page {

  * it redirects back to the RP endpoint (still in the IFRAME) and 
indicates that an immediate request was not possible.

  * the RP endpoint generates some HTML containing script that fires 
a callback in the containing page which causes it to do a normal 
redirect-dance OpenID request. This is often done in a new window to 
avoid disrupting whatever process started the OpenID auth request.

}
  * Else {

  * OP redirects back to the RP endpoint (still in the IFRAME) 
including the signature and all the other fun stuff you get on success.

  * the RP endpoint generates some HTML containing script that fires 
a callback in the containing page which does something like starting a 
session, putting the openid sig in the form to be validated later, or 
some other such action. (or maybe it just says "auth succeeded!" and the 
server validates it once the form is submitted.)

}

So no, this isn't really AJAX in the usual sense. As you noted, you 
can't do OpenID Auth client-side with XMLHttpRequest because of the 
same-origin restriction. You also can't do OpenID on the server because 
then the user's session cookie won't end up at the OP during the 
request. It still achieves the desired effect of doing an OpenID auth 
request without disturbing the current page, though.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: DRAFT 11 -> FINAL?

[Josh Hoyt]

On 1/30/07, Recordon, David <[EMAIL PROTECTED]> wrote:
> Yeah, I'm not a big fan of openid2.* though it was the simplest method
> of fixing up HTML discovery to work with multiple protocol versions.  I
> know Josh thought about this more than I did though.

1. Before authentication is initiated, the RP needs to determine what
the protocol is. This could be done via discovery on the OP, but there
has been general rejection of adding yet another discovery step.

2. A user may have one service that provides OpenID 1 and another that
provides OpenID 2. If this is the case, then the version information
needs to be bound to the link tag that contains the information.

Given (1), the information needs to be embedded in the HTML markup.
Given (2), the information needs to be tied to the specific link tag.

For example:

  http://op.example.com/openid1";>
  http://op.example.com/openid2";>

vs.
  http://op.example.com/openid1";>
  http://op.example.com/openid2";>
  http://specs.openid.net/auth/2.0";>

While it is true that since the link relationship names changed, the
"openid2" is technically redundant, I think it is much clearer to
everybody what is going on if the link relationship contains the
version number. If the protocol version were to keep changing, I'd
argue for a different solution.

Josh
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: DRAFT 11 -> FINAL?

[Recordon, David]

Yeah, I'm not a big fan of openid2.* though it was the simplest method
of fixing up HTML discovery to work with multiple protocol versions.  I
know Josh thought about this more than I did though.

>From what I've seen people do, it is AJAX between your server and
application, then OpenID's checkid_immediate between the server and OP,
with an AJAX response from your server to application.

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Rowan Kerr
Sent: Tuesday, January 30, 2007 2:02 PM
To: specs@openid.net
Subject: Re: DRAFT 11 -> FINAL?

The openid2.* links bug me a little.. but due to no openid.ns being
defined in the 1.x protocol, maybe there is no other way to specify by
HTML discovery that your OP is 2.0 capable. Would it be bad to have a
openid.version link instead?

Also, the spec mentions AJAX interactions, but I don't see how you can
actually use AJAX with OpenID, since none of the responses are in XML
format .. it relies entirely on GET or POST redirection, not to mention
that you have to make cross-domain requests which XmlHttpRequest will
not do without extra security privileges.

(Or am I missing something?)

-Rowan
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: DRAFT 11 -> FINAL?

[Rowan Kerr]

The openid2.* links bug me a little.. but due to no openid.ns being
defined in the 1.x protocol, maybe there is no other way to specify by
HTML discovery that your OP is 2.0 capable. Would it be bad to have a
openid.version link instead?

Also, the spec mentions AJAX interactions, but I don't see how you can
actually use AJAX with OpenID, since none of the responses are in XML
format .. it relies entirely on GET or POST redirection, not to
mention that you have to make cross-domain requests which
XmlHttpRequest will not do without extra security privileges.

(Or am I missing something?)

-Rowan
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: DRAFT 11 -> FINAL?

[Recordon, David]

Thanks, fixed the HTML terminology  as a start.
http://openid.net/svn/diff.php?repname=specifications&path=%2Fauthentication%2F2.0%2Ftrunk%2Fopenid-authentication.xml&rev=292&sc=1

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Claus Färber
Sent: Saturday, January 20, 2007 10:15 AM
To: specs@openid.net
Subject: Re: DRAFT 11 -> FINAL?

Dick Hardt <[EMAIL PROTECTED]> schrieb/wrote:
> Are there any more issues with this specification:
>   http://openid.net/specs/openid-authentication-2_0-11.html

> Can we make this final?

Ok, here are the problems I found during a quick review:

-
| 4.1.1.  Key-Value Form Encoding
|
| A message in Key-Value form is a sequence of lines. Each line begins 
| with a key, followed by a colon, and the value associated with the 
| key. The line is terminated by a single newline (UCS codepoint 10, 
| "\n"). A key or value MUST NOT contain a newline and a key also MUST 
| NOT contain a colon.

While it's ok for keys to have a limited alphabet, not allowing them in the 
value may be a problem for future extensions (say, if AX wants to transfer a 
multiline postal address).

I don't think it's a good idea to invent a new format here. What's wrong with 
URI percent-encoding, which has to be implemented by OpenID software anyway?

OpenID could even use application/x-www-form-urlencoded for simple exchanges 
and multipart/form-data (HTML 4.01, section 17.13.4) for some aspects of AX 
(say, e.g. a JPEG photo).

Also, section 5.1.2 says that the response SHOULD be labelled as
"text/plain":

| 5.1.2.  Direct Response
|
| The body of a response to a Direct Request (Direct Request) consists 
| of an HTTP Response body in Key-Value Form (Key-Value Form Encoding).
| The content-type of the response SHOULD be "text/plain".

Together with section 4.1.1, this is incompatible with HTTP, the spec of which 
says (RFC 2616, section 3.7.1):

> When in canonical form, media subtypes of the "text" type use CRLF as 
> the text line break. HTTP relaxes this requirement and allows the 
> transport of text media with plain CR or LF alone representing a line 
> break when it is done consistently for an entire entity-body. HTTP 
> applications MUST accept CRLF, bare CR, and bare LF as being 
> representative of a line break in text media received via HTTP.

There are two options: Don't use a "text/*" subtype or bring the OpenID spec in 
line with HTTP (i.e. treat CRLF, CR and LF the same). If the later is chosen, 
"text/plain" must also be changed to "text/plain with a charset of UTF-8" as 
the default for HTTP is "ISO-8859-1" (RFC 2616, section 3.7.1).

-

| 5.1.2.1.  Successful Responses
|
| A server receiving a valid request MUST send a response with an HTTP 
| status code of 200.

That may be incompatible with some HTTP caching/conditional response features. 
There is a slight chance that, for example, a 206 code might also be 
appropriate in some situations

-

| 5.1.2.2.  Error Responses
|
| If a request is malformed or contains invalid arguments, the server 
| MUST send a response with a status code of 400.

This is incompatible with RFC 2616, which would also allow different error 
codes depending on the situation.

What about "... MUST send a response with an appropriate HTTP status code such 
as 400 (Bad Request)".

| The response body MUST be a Key-Value Form (Key-Value Form Encoding) 
| message with the following fields:
...
| *error
| Value: A human-readable message indicating the cause of the error.

What about different languages?

This is actually tricky. The Accept-Language header from the user is not 
available to the OP if it is contacted by the RP directly, so the OP can't 
choose an appropriate language.

Note that RFC 2277 (= BCP 18) says:

> 4.2.  Requirement for language tagging
>
> Protocols that transfer text MUST provide for carrying information 
> about the language of that text.

While this technically isn't binding for a non-IETF spec, it's still an 
extremly good idea.

Same problem in 5.2.3 and 8.2.4.

-

| 7.3.3.  HTML-Based Discovery
|
| HTML-Based discovery MUST be supported by Relying Parties. HTML-Based 
| discovery is only usable for discovery of Claimed Identifiers. OP 
| Identifiers must be XRIs or URLs that support XRDS discovery.
|
| To use HTML-Based discovery, an HTML document MUST be available at the 
| URL of the Claimed Identifier. In the HEAD section of the document:

It seems that it has been unclear to some implementers what "HEAD section" 
means. This is not surprising as the correct term is "HEAD element" (HTML 4.01, 
section 3.2.1).

|A  tag MUST be included with attributes "rel" set to
|"openid2.provider" and "href" set to an O

HTML parsing in HTML-based discovery (was: DRAFT 11 -> FINAL?)

[Claus Färber]

Martin Atkins schrieb:
> Since your list is long, I'm only going to address things I have an 
>> | 7.3.3.  HTML-Based Discovery
> In practice, few implementations actually use an HTML parser to find 
> these elements. These extra restrictions are present to facilitate 
> regex-based parsing.

Yes, and this is the problem. Implementors may *think* that they can get 
away with regexp parsing when in fact they can't. HTML/XHTML requires a 
context-free parser, which is one level above regular expressions in the 
Chomsky hierarchy.

Even if they start mixing regexps and other code, it is likely that they 
won't handle all the corner-cases of HTML correctly.
The effect is that an OpenID login may work on 80% of all sites ... and 
not on the other 20% that use a different parser. And the user will not 
even know _why_ his login fails. After all, validators and other HTML 
checking tools will tell him that his site is valid HTML.
It's even possible that some parsers fail on things other parsers require.

> The regex-based parsers employed by existing implementations require 
> explicit  start and end tags. I agree that this is not ideal, but 
> it's hardly an onerous requirement on document authors.

Currently, the spec does not require explicit start and end tags for the 
HEAD element. It talks about a "HEAD section", which is always there 
even if it is not marked (see 
)
This is already an imcompatibility caused by unclear wording.

In order to facilitate regexp parsing, just requiring the start and end 
tags is not enough. Additional restrictions may also be necessary to 
avoid cases where too simple regexp-based parsers might fail:

-  start with attributes.
- order of attributes within the  tag.
- single quotes vs. double quotes vs. no quotes.
- unescaped "<"/">" within attributes.*
- numeric character references.*
- line feeds within tags.*
- additional XML namespaces that allow attributes like foo:href.*
-  tags within .*
- [to be continued]

(* = inspired by a real-world implementation failing to handle these 
cases correctly)

If you want to handle all of these correctly, you already need a true 
HTML parser.

The less of these restrictions are added, the less likely will it be 
that regexp-based parsers interoperate.

> This is mostly an ideological argument founded on whether we're allowed 
> to impose additional restrictions on HTML documents that are making use 
> of OpenID discovery. There is certainly no *practical* reason why this 
> shouldn't be done, assuming that the restrictions are sufficient to 
> prevent the above attack.

There are practical problems:

* Users can't use existing HTML tools to check for the additional
   restrictions. A validator will say "valid HTML" but the OpenID
   login fails due to a "parsing error" (e.g. the PHP implementation used
   on OpenID Enabled). And different RP will choke on different things.

* Users can't use existing HTML tools that do not honor the additional
   restrictions. A HTML pretty-printer may simply re-format the code in
   a way unparsable by ad-hoc parsers; a hypothetical htmlcrush program
   might may remove the optional quotes, entity references and tags in
   good faith.

* Other specs might also impose restrictions, which can be incompatible
   with OpenID's restrictions.

The more restrictions are added, the more likely will it be that these 
practical problems arise.

Claus

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: DRAFT 11 -> FINAL?

[Martin Atkins]

Since your list is long, I'm only going to address things I have an 
answer to. I'll leave the rest to other people. :)

Claus Färber wrote:
> -
> | 4.1.1.  Key-Value Form Encoding
> |
> | A message in Key-Value form is a sequence of lines. Each line begins
> | with a key, followed by a colon, and the value associated with the
> | key. The line is terminated by a single newline (UCS codepoint 10,
> | "\n"). A key or value MUST NOT contain a newline and a key also MUST
> | NOT contain a colon.
> 
> While it's ok for keys to have a limited alphabet, not allowing them in
> the value may be a problem for future extensions (say, if AX wants to
> transfer a multiline postal address).
> 
> I don't think it's a good idea to invent a new format here. What's wrong
> with URI percent-encoding, which has to be implemented by OpenID
> software anyway?
> 

As far as I'm aware the protocol does not allow for extensions to add to 
the messages sent in this encoding. Extensions are only allowed to take 
part in the messages passed by redirecting the UA, in urlencoded format. 
The OpenID protocol itself has no need for newlines or other fancy 
characters here.

I agree with you that inventing a new format here was an odd choice, but 
unfortunately it's already in use by deployed OpenID 1.1 implementations 
and so OpenID 2 implementations will have to support it anyway.

> 
> | The response body MUST be a Key-Value Form (Key-Value Form Encoding)
> | message with the following fields:
> ...
> | *error
> | Value: A human-readable message indicating the cause of the error.
> 
> What about different languages?
> 
> This is actually tricky. The Accept-Language header from the user is not  
> available to the OP if it is contacted by the RP directly, so the OP  
> can't choose an appropriate language.

This "human-readable message" is really addressed at the developer of 
the non-compliant implementation, not the end-user. Therefore support 
for multiple languages was thought not to be that important. All current 
implementations use straightforward English messages.

The end-user should never see such a message since these error responses 
only arise when there is a bug in someone's implementation. (In theory, 
at least!)

> 
> | 7.3.3.  HTML-Based Discovery
> |
> | HTML-Based discovery MUST be supported by Relying Parties. HTML-Based
> | discovery is only usable for discovery of Claimed Identifiers. OP
> | Identifiers must be XRIs or URLs that support XRDS discovery.
> |
> | To use HTML-Based discovery, an HTML document MUST be available at the
> | URL of the Claimed Identifier. In the HEAD section of the document:
> 
> It seems that it has been unclear to some implementers what "HEAD
> section" means. This is not surprising as the correct term is "HEAD
> element" (HTML 4.01, section 3.2.1).

Agreed. This is just a simple language change.

> |A  tag MUST be included with attributes "rel" set to
> |"openid2.provider" and "href" set to an OP Endpoint URL
> |A  tag MAY be included with attributes "rel" set to
> |   "openid2.local_id" and "href" set to the end user's OP-Local
> |   Identifier
> 
> These should read "LINK element", not " tag".

While you're correct, I don't think it's that erroneous to say " 
tag" here. Still, it can't hurt to correct it.

> | The protocol version when HTML discovery is performed is "http://
> | specs.openid.net/auth/2.0/signon".
> |
> | The host of the HTML document MAY be different from the end user's
> | OP's host.
> |
> | The "openid2.provider" and "openid2.local_id" URLs MUST NOT include
> | entities other than "&", "<", ">", and """. Other
> | characters that would not be valid in the HTML document or that cannot
> | be represented in the document's character encoding MUST be escaped
> | using the percent-encoding (%xx) mechanism described in [RFC3986]
> | (Berners-Lee, T., "Uniform Resource Identifiers (URI): Generic
> | Syntax," .).
> 
> This is incompatible with HTML parsing rules.
> 
[snip]
> 
> I think the whole section is flawed and should be replaced with a small
> note as a warning:
> 
>   Note: If the "openid2.provider" and "openid2.local_id" contain an
>   ampersand (&), this character MUST be escaped as "&" according to
>   HTML rules.

In practice, few implementations actually use an HTML parser to find 
these elements. These extra restrictions are present to facilitate 
regex-based parsing.

Since there is no regression if an implementation should choose to use a 
*real* HTML parser, I don't see the harm here. It's imposing extra 
restrictions only on people who want to use OpenID HTML discovery; the 
rest of the document uses the normal HTML rules, though there is one 
exception which I'll describe below.

> 
> BTW, good HTML parsers are mandatory to protect against HTML injection
> attacks. An ad-hoc parser might simply fall for something like that:
> 
>   
>   
>   Nice test
>   
>   Send me your comment:
>   
>   
>   
> 
> Yes, this is valid HT

Re: DRAFT 11 -> FINAL?

[Claus Färber]

Dick Hardt <[EMAIL PROTECTED]> schrieb/wrote:
> Are there any more issues with this specification:
>   http://openid.net/specs/openid-authentication-2_0-11.html

> Can we make this final?

Ok, here are the problems I found during a quick review:

-
| 4.1.1.  Key-Value Form Encoding
|
| A message in Key-Value form is a sequence of lines. Each line begins
| with a key, followed by a colon, and the value associated with the
| key. The line is terminated by a single newline (UCS codepoint 10,
| "\n"). A key or value MUST NOT contain a newline and a key also MUST
| NOT contain a colon.

While it's ok for keys to have a limited alphabet, not allowing them in
the value may be a problem for future extensions (say, if AX wants to
transfer a multiline postal address).

I don't think it's a good idea to invent a new format here. What's wrong
with URI percent-encoding, which has to be implemented by OpenID
software anyway?

OpenID could even use application/x-www-form-urlencoded for simple
exchanges and multipart/form-data (HTML 4.01, section 17.13.4) for some
aspects of AX (say, e.g. a JPEG photo).

Also, section 5.1.2 says that the response SHOULD be labelled as
"text/plain":

| 5.1.2.  Direct Response
|
| The body of a response to a Direct Request (Direct Request) consists
| of an HTTP Response body in Key-Value Form (Key-Value Form Encoding).
| The content-type of the response SHOULD be "text/plain".

Together with section 4.1.1, this is incompatible with HTTP, the spec of
which says (RFC 2616, section 3.7.1):

> When in canonical form, media subtypes of the "text" type use CRLF as
> the text line break. HTTP relaxes this requirement and allows the
> transport of text media with plain CR or LF alone representing a line
> break when it is done consistently for an entire entity-body. HTTP
> applications MUST accept CRLF, bare CR, and bare LF as being
> representative of a line break in text media received via HTTP.

There are two options: Don't use a "text/*" subtype or bring the OpenID
spec in line with HTTP (i.e. treat CRLF, CR and LF the same). If the
later is chosen, "text/plain" must also be changed to "text/plain with a
charset of UTF-8" as the default for HTTP is "ISO-8859-1" (RFC 2616,
section 3.7.1).

-

| 5.1.2.1.  Successful Responses
|
| A server receiving a valid request MUST send a response with an HTTP
| status code of 200.

That may be incompatible with some HTTP caching/conditional response  
features. There is a slight chance that, for example, a 206 code might  
also be appropriate in some situations

-

| 5.1.2.2.  Error Responses
|
| If a request is malformed or contains invalid arguments, the server
| MUST send a response with a status code of 400.

This is incompatible with RFC 2616, which would also allow different
error codes depending on the situation.

What about "... MUST send a response with an appropriate HTTP status
code such as 400 (Bad Request)".

| The response body MUST be a Key-Value Form (Key-Value Form Encoding)
| message with the following fields:
...
| *error
| Value: A human-readable message indicating the cause of the error.

What about different languages?

This is actually tricky. The Accept-Language header from the user is not  
available to the OP if it is contacted by the RP directly, so the OP  
can't choose an appropriate language.

Note that RFC 2277 (= BCP 18) says:

> 4.2.  Requirement for language tagging
>
> Protocols that transfer text MUST provide for carrying information
> about the language of that text.

While this technically isn't binding for a non-IETF spec, it's still an
extremly good idea.

Same problem in 5.2.3 and 8.2.4.

-

| 7.3.3.  HTML-Based Discovery
|
| HTML-Based discovery MUST be supported by Relying Parties. HTML-Based
| discovery is only usable for discovery of Claimed Identifiers. OP
| Identifiers must be XRIs or URLs that support XRDS discovery.
|
| To use HTML-Based discovery, an HTML document MUST be available at the
| URL of the Claimed Identifier. In the HEAD section of the document:

It seems that it has been unclear to some implementers what "HEAD
section" means. This is not surprising as the correct term is "HEAD
element" (HTML 4.01, section 3.2.1).

|A  tag MUST be included with attributes "rel" set to
|"openid2.provider" and "href" set to an OP Endpoint URL
|A  tag MAY be included with attributes "rel" set to
|   "openid2.local_id" and "href" set to the end user's OP-Local
|   Identifier

These should read "LINK element", not " tag".

| The protocol version when HTML discovery is performed is "http://
| specs.openid.net/auth/2.0/signon".
|
| The host of the HTML document MAY be different from the end user's
| OP's host.
|
| The "openid2.provider" and "openid2.local_id" URLs MUST NOT include
| entities other than "&", "<", ">", and """. Other
| characters that would not be valid in the HTML document or that cannot
| be represented in the document's character encoding MUST be escaped
|

Re: DRAFT 11 -> FINAL?

[Dick Hardt]

OK -- would it be possible to keep the list apprised of the progress  
and post the issue and resolution once you are done this afternoon?

-- Dick

On 18-Jan-07, at 3:55 PM, Recordon, David wrote:

> Considering draft 11 hasn't been published yet, I don't see how we can
> make it final at this point.  In addition, the file you link to is  
> a few
> patches old.  While I appreciate your enthusiasm, Josh, Johnny, and  
> I do
> have a process to this madness.
>
> I know you know that we're really close, there is one remaining issue
> Josh, Drummond, and I are tackling this afternoon, and then we'll
> publish draft 11.
>
> Thanks,
> --David
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Dick Hardt
> Sent: Thursday, January 18, 2007 3:45 PM
> To: specs@openid.net
> Subject: DRAFT 11 -> FINAL?
>
> Hey List
>
> To deal with the recent security concern postings about OpenID,  
> language
> was added to clarify a secure channel is needed between the OP and the
> end-user's machine.
>
> Are there any more issues with this specification:
>
>   http://openid.net/specs/openid-authentication-2_0-11.html
>
> Can we make this final?
>
> -- Dick
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: DRAFT 11 -> FINAL?

[Recordon, David]

Considering draft 11 hasn't been published yet, I don't see how we can
make it final at this point.  In addition, the file you link to is a few
patches old.  While I appreciate your enthusiasm, Josh, Johnny, and I do
have a process to this madness.

I know you know that we're really close, there is one remaining issue
Josh, Drummond, and I are tackling this afternoon, and then we'll
publish draft 11.

Thanks,
--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dick Hardt
Sent: Thursday, January 18, 2007 3:45 PM
To: specs@openid.net
Subject: DRAFT 11 -> FINAL?

Hey List

To deal with the recent security concern postings about OpenID, language
was added to clarify a secure channel is needed between the OP and the
end-user's machine.

Are there any more issues with this specification:

http://openid.net/specs/openid-authentication-2_0-11.html

Can we make this final?

-- Dick
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

DRAFT 11 -> FINAL?

[Dick Hardt]

Hey List

To deal with the recent security concern postings about OpenID,  
language was added to clarify a secure channel is needed between the  
OP and the end-user's machine.

Are there any more issues with this specification:

http://openid.net/specs/openid-authentication-2_0-11.html

Can we make this final?

-- Dick
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs