Re: Comments on Auth 2.0 - Pre-Draft 11
On 12/11/06, Johannes Ernst [EMAIL PROTECTED] wrote: Section 4.1.1 - Key-Value Form Encoding If in the key-value form, I wish to transmit a value that includes a '\n', what am I supposed to do? Encode it such that it doesn't have a '\n' in it, e.g using base64. If '\n' was allowed, the protocol would permit the kind of attack described in this thread: http://openid.net/pipermail/specs/2006-November/000901.html I understand that is one possible fix. What about we define one of the possible fixes as the canonical fix for text data, otherwise different implementors will implement different fixes (base64, C- style \n, URL-style %0D%0a, ... ) and interop will suffer. I'm uncomfortable defining an escaping mechanism when there are different possibilities that are appropriate for different contexts. I think that extension authors will define an appropriate scheme for the problem that they are solving (e.g. if it's binary data, use base64), and everyone who is using that extension will use that same encoding, so there will not be interoperability issues. If there were multiple extensions defining escaping mechanisms today, and they agreed, then I might agree to specify one, but there are not, so I'd rather leave it open. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
On 12/11/06, Johannes Ernst [EMAIL PROTECTED] wrote: 10 Responding to Authentication Requests First sentence: When an authentication request comes from the User-Agent via indirect communication (Indirect Communication), the OP SHOULD identify the User-Agent, and determine whether the end user wishes to complete the authentication. I have no idea what the term identify means here. Do you mean: When an authentication request comes from the User-Agent via indirect communication (Indirect Communication), the OP SHOULD determine the validity of the current session of the User-Agent with the OP, and -- with or without direct interaction with the user, this is left to implementors -- determine whether the end user wishes to complete the authentication with this particular RP. Re-worded in http://openid.net/svn/listing.php?repname=specificationspath=%2Frev=235sc=1 New text: When an authentication request comes from the User-Agent via indirect communication (Indirect Communication), the OP SHOULD determine that an authorized end user wishes to complete the authentication. If an authorized end user wishes to complete the authentication, the OP SHOULD send a positive assertion (Positive Assertions) to the Relying Party. Methods of identifying authorized end users and obtaining approval to return an OpenID Authentication assertion are beyond the scope of this specification. I think that's all the issues that were in my court. Did I miss anything? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
On 12-Dec-06, at 9:10 AM, Johannes Ernst wrote: 11.2.2.2 Response Parameters Not clear which values MUST be present and which not. Also: the language in this section is confusing. I don't quite understand it. Not sure I can make a suggestion how to explain it better, because so far I don' tunderstand it. I'll try to rephrase the three paragraphs in there. In the meantime, it would help if you could point what you found the most confusing. I'm just raising the General Confusion Fault ;-) That might just be me, however. This is what I've come with for the Verifying Directly with the OpenID Provider section; does it (start to) make sense? http://openid.net/svn/listing.php?repname=specificationspath=% 2Frev=236sc=1 Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
I think so. There seem to be enough changes I need to review a bigger chunk than I have time for right now. On Dec 15, 2006, at 17:58, Johnny Bufu wrote: On 12-Dec-06, at 9:10 AM, Johannes Ernst wrote: 11.2.2.2 Response Parameters Not clear which values MUST be present and which not. Also: the language in this section is confusing. I don't quite understand it. Not sure I can make a suggestion how to explain it better, because so far I don' tunderstand it. I'll try to rephrase the three paragraphs in there. In the meantime, it would help if you could point what you found the most confusing. I'm just raising the General Confusion Fault ;-) That might just be me, however. This is what I've come with for the Verifying Directly with the OpenID Provider section; does it (start to) make sense? http://openid.net/svn/listing.php?repname=specificationspath=% 2Frev=236sc=1 Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
Well, I would think it depends on the underlying data type. For example, for plain-text strings, there's really no need to define more than one escaping mechanism. If somebody wants to encode a GIF picture, this may be different, and I agree we can't hope to enumerate all possibilities. But that might not be needed. I just would hate it if we all had to guess whether somebody's abc \ndef was supposed to be rendered as that, or in two lines. On Dec 15, 2006, at 16:08, Josh Hoyt wrote: On 12/11/06, Johannes Ernst [EMAIL PROTECTED] wrote: Section 4.1.1 - Key-Value Form Encoding If in the key-value form, I wish to transmit a value that includes a '\n', what am I supposed to do? Encode it such that it doesn't have a '\n' in it, e.g using base64. If '\n' was allowed, the protocol would permit the kind of attack described in this thread: http://openid.net/pipermail/specs/2006-November/000901.html I understand that is one possible fix. What about we define one of the possible fixes as the canonical fix for text data, otherwise different implementors will implement different fixes (base64, C- style \n, URL-style %0D%0a, ... ) and interop will suffer. I'm uncomfortable defining an escaping mechanism when there are different possibilities that are appropriate for different contexts. I think that extension authors will define an appropriate scheme for the problem that they are solving (e.g. if it's binary data, use base64), and everyone who is using that extension will use that same encoding, so there will not be interoperability issues. If there were multiple extensions defining escaping mechanisms today, and they agreed, then I might agree to specify one, but there are not, so I'd rather leave it open. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
On 12/14/06, Johannes Ernst [EMAIL PROTECTED] wrote: So you believe that it is tight enough that if you and I implement the spec, and somebody types the exact same character string into both of our implementations, it will produce the exact same result, regardless what the character string was? Yes, that's what I think. :) Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
I have changed that text from needs to to MUST, although I think that the sentence before that (The end user's input MUST be normalized into an Identifier) is pretty unambiguous. I feel this is an excellent change. This style should be followed throughout. The problem with 'needs to' and 'MUST' in the same document is that it leaves the reader this little puzzle to puzzle over: What is the normative difference between 'needs to' and 'MUST'? Why is 'needs to' used here and 'MUST' there? Is 'needs to' weaker than 'MUST'? Is 'needs to' stronger than 'SHOULD'? Cordially, Joaquin ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Off-topic: Re: Comments on Auth 2.0 - Pre-Draft 11
On 12/14/06, Joaquin Miller [EMAIL PROTECTED] wrote: I have changed that text from needs to to MUST, although I think that the sentence before that (The end user's input MUST be normalized into an Identifier) is pretty unambiguous. I feel this is an excellent change. This style should be followed throughout. The problem with 'needs to' and 'MUST' in the same document is that it leaves the reader this little puzzle to puzzle over: What is the normative difference between 'needs to' and 'MUST'? Why is 'needs to' used here and 'MUST' there? Is 'needs to' weaker than 'MUST'? Is 'needs to' stronger than 'SHOULD'? I doubt that the needs to wording would have ever caused any problems with implementation. The sentence before states that you MUST normalize the input. The needs to was describing a condition that is necessary to check in order to perform the normalization. Anyone who was attempting to implement the normalization algorithm would see that it is necessary to determine the type of the input before continuing. I think that words like MUST and SHOULD are not necessary when describing how to do something whose importance has already been made clear (by a MUST, etc.). I have a hard time reading prose that uses those words excessively, because if they are over-used, they become noise (you already said I MUST normalize). Anyway, I think the OpenID 2.0 Authentication specification is pretty consistent about using the appropriately strong wording when it's not already clear whether something is required, so I think this discussion is mostly academic. Feel free to make requests if there are specific parts whose compliance is not obvious. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
On 12/11/06, Johannes Ernst [EMAIL PROTECTED] wrote: 7.1 Initiation Given recent discussions on logo and User Experience, this needs to be different. Instead of: To initiate OpenID Authentication, the Relying Party SHOULD present the end user with a form that has a field for entering an Identifier. It is RECOMMENDED that a Relying Party place the OpenID logo at the beginning of the form field where the end user enters their Identifier. This aides in end user recognition that they can use an OpenID enabled Identifier at the Relying Party. Better: This document does not define a user experience. It is RECOMMENDED that implementors follow the OpenID user experience if and when such an OpenID user experience has been defined in a separate document. Proposed resolution? I've taken out the logo recommendation and left it with an input field in a form with the appropriate name attribute. The user-experience document won't contradict *that* much, and it's a technical necessity (for e.g. smart software agents to detect the login field). See http://openid.net/svn/listing.php?repname=specificationspath=%2Frev=212sc=1 Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
Oops, forgot to copy the list... On 12/14/06, Josh Hoyt [EMAIL PROTECTED] wrote: On 12/11/06, Johannes Ernst [EMAIL PROTECTED] wrote: 9.1. Request Parameters ... Note: If an OP-SPecific Identifier is not supplied, the Claimed Identifier is considered to have the same as the OP- Specific Identifier. If neither value is present, the assertion is not about an identifier, and will contain other information in its payload, using extensions (Extensions). This doesn't seem right; I read your text like this: If an OP-Specific Identifier is not supplied and therefore openid.identity = http://openid.net/ identifier_select/2.0 the Claimed Identifier is considered to have the same as the OP- Specific Identifier. openid.claimed_id = http://openid.net/identifier_select/2.0; Which is fine, but doesn't cover the remaining cases, i.e. when Claimed Identifiers / OP-Specific Identifiers *are* supplied. The original / current wording does cover these cases, albeit I admit it is not very easy to read. So I modify my request to modify the wording in a way that it is easier to read. Attempted. See http://openid.net/svn/listing.php?repname=specificationspath=%2Frev=201sc=1 and http://openid.net/svn/listing.php?repname=specificationspath=%2Frev=209sc=1 Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Off-topic: Re: Comments on Auth 2.0 - Pre-Draft 11
Joaquin / Josh, I clearly see the position you both have here. Overusing verbs can certainly lessen their importance within any document. And by the very nature of the work the community is doing and the people it involved, and the people likely to use the specification - it is pretty safe to say that anyone reading the document is going to have a level of reading comprehension that should make it irrelevant which we way go. - I personally haven't wondered whether something was a MUST have of not - I thought it was always clear enough. But you never know who will end up reading the document and for what purpose; and with that in mind, I'm going to have to +1, inline with Joaquin's perspective on this one. As the new guy - it leaves no doubt in my mind at all as to what MUST happen. And if I can get all the MUST HAVES implemented - then surely I SHOULD have a working implementation of the specification. Gavin Baumanis RMIT University, Melbourne, Australia. On Friday, December 15, 2006 at 08:55, in message [EMAIL PROTECTED], Josh Hoyt [EMAIL PROTECTED] wrote: On 12/14/06, Joaquin Miller [EMAIL PROTECTED] wrote: I have changed that text from needs to to MUST, although I think that the sentence before that (The end user's input MUST be normalized into an Identifier) is pretty unambiguous. I feel this is an excellent change. This style should be followed throughout. The problem with 'needs to' and 'MUST' in the same document is that it leaves the reader this little puzzle to puzzle over: What is the normative difference between 'needs to' and 'MUST'? Why is 'needs to' used here and 'MUST' there? Is 'needs to' weaker than 'MUST'? Is 'needs to' stronger than 'SHOULD'? I doubt that the needs to wording would have ever caused any problems with implementation. The sentence before states that you MUST normalize the input. The needs to was describing a condition that is necessary to check in order to perform the normalization. Anyone who was attempting to implement the normalization algorithm would see that it is necessary to determine the type of the input before continuing. I think that words like MUST and SHOULD are not necessary when describing how to do something whose importance has already been made clear (by a MUST, etc.). I have a hard time reading prose that uses those words excessively, because if they are over-used, they become noise (you already said I MUST normalize). Anyway, I think the OpenID 2.0 Authentication specification is pretty consistent about using the appropriately strong wording when it's not already clear whether something is required, so I think this discussion is mostly academic. Feel free to make requests if there are specific parts whose compliance is not obvious. 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: Off-topic: Re: Comments on Auth 2.0 - Pre-Draft 11
As a general point and FWIW, capitalized (RFC 2119) uses of MUST, SHOULD, etc. are meant to make it easy to form testable assertions for compliance-checking. It's best to avoid redundant normative spec content, though sometimes repetition or restatement in the right places can reinforce a correct interpretation for better interop. And it's best to use non-RFC 2119 ways of conveying expectations and best practices precisely in the set of cases where something isn't testable (e.g., it's an internal operation of a system entity and thus isn't amenable to standardization, or it involves some kind of subjective judgment). If you really mean something normative, using capitals is safest even if it seems ugly... Readers will just want it to be consistent, so a final editing pass ideally will include a review of this. If there's some doubt what lowercase versions of the words mean, you could add notation wording like what SAML V1.x used: = The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in IETF RFC 2119 [RFC 2119]: …they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)… These keywords are thus capitalized when used to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense. = But this was removed in SAML2, since it was assumed readers know the drill. Richard Mitchell noted thirty years ago that discursive prose is a technology.[1] Technical specs are even more so! (If you're not familiar with the Underground Grammarian, I strongly RECOMMEND his Less Than Words Can Say[2]...) Eve [1] http://www.sourcetext.com/grammarian/less-than-words-can-say/03.htm [2] http://www.sourcetext.com/grammarian/index.html Josh Hoyt wrote: On 12/14/06, Joaquin Miller [EMAIL PROTECTED] wrote: I have changed that text from needs to to MUST, although I think that the sentence before that (The end user's input MUST be normalized into an Identifier) is pretty unambiguous. I feel this is an excellent change. This style should be followed throughout. The problem with 'needs to' and 'MUST' in the same document is that it leaves the reader this little puzzle to puzzle over: What is the normative difference between 'needs to' and 'MUST'? Why is 'needs to' used here and 'MUST' there? Is 'needs to' weaker than 'MUST'? Is 'needs to' stronger than 'SHOULD'? I doubt that the needs to wording would have ever caused any problems with implementation. The sentence before states that you MUST normalize the input. The needs to was describing a condition that is necessary to check in order to perform the normalization. Anyone who was attempting to implement the normalization algorithm would see that it is necessary to determine the type of the input before continuing. I think that words like MUST and SHOULD are not necessary when describing how to do something whose importance has already been made clear (by a MUST, etc.). I have a hard time reading prose that uses those words excessively, because if they are over-used, they become noise (you already said I MUST normalize). Anyway, I think the OpenID 2.0 Authentication specification is pretty consistent about using the appropriately strong wording when it's not already clear whether something is required, so I think this discussion is mostly academic. Feel free to make requests if there are specific parts whose compliance is not obvious. Josh -- Eve Maler +1 425 947 4522 Technology Director eve.maler @ sun.com CTO Business Alliances groupSun Microsystems, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
So you believe that it is tight enough that if you and I implement the spec, and somebody types the exact same character string into both of our implementations, it will produce the exact same result, regardless what the character string was? That's all I want to accomplish ... On Dec 14, 2006, at 12:05, Josh Hoyt wrote: (I will be addressing the remaining issues that you brought up one at a time) On 12/11/06, Johannes Ernst [EMAIL PROTECTED] wrote: 7.2 Normalization I'm not sure that this -- all of which is OPTIONAL -- should be in this document. I would suggest to either make it MANDATORY -- or to take it out of this document and refer to a User Experience document instead. The problem is that if the user can type in something incomplete at site A, and then types in the same incomplete thing at site B, it may work at A but differently at B, which is no good. So either make these rules MANDATORY, or delegate them into the user experience. Normalization is not optional at all - not sure why you understood it was. Maybe that section needs to be clarified, if you can point it to us. I am referring to par 1 sentence 2, where is says needs to instead of MUST ... according to the following algorithm. Then to the entire paragraph 2, which says SHOULD. I'd like an algorithm that produces the same normalized identifier from the same entered text string, regardless of site. I have changed that text from needs to to MUST, although I think that the sentence before that (The end user's input MUST be normalized into an Identifier) is pretty unambiguous. Paragraph two about normalizing XRIs I think was David's text, so I guess I'll wait for his response about that. I think he's on vacation. Other than the SHOULD for recognizing XRI global context symbols and adding the xri:// prefix, I think that the normalization section is pretty tight and will not lead to inconsistencies in implementation. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
And I had responded: In which case, I will attempt to be satisfied ;-) On Dec 14, 2006, at 16:35, Josh Hoyt wrote: Oops, forgot to copy the list... On 12/14/06, Josh Hoyt [EMAIL PROTECTED] wrote: On 12/11/06, Johannes Ernst [EMAIL PROTECTED] wrote: 9.1. Request Parameters ... Note: If an OP-SPecific Identifier is not supplied, the Claimed Identifier is considered to have the same as the OP- Specific Identifier. If neither value is present, the assertion is not about an identifier, and will contain other information in its payload, using extensions (Extensions). This doesn't seem right; I read your text like this: If an OP-Specific Identifier is not supplied and therefore openid.identity = http://openid.net/ identifier_select/2.0 the Claimed Identifier is considered to have the same as the OP- Specific Identifier. openid.claimed_id = http://openid.net/identifier_select/2.0; Which is fine, but doesn't cover the remaining cases, i.e. when Claimed Identifiers / OP-Specific Identifiers *are* supplied. The original / current wording does cover these cases, albeit I admit it is not very easy to read. So I modify my request to modify the wording in a way that it is easier to read. Attempted. See http://openid.net/svn/listing.php?repname=specificationspath=% 2Frev=201sc=1 and http://openid.net/svn/listing.php?repname=specificationspath=% 2Frev=209sc=1 Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
Sounds good. On Dec 14, 2006, at 16:28, Josh Hoyt wrote: On 12/11/06, Johannes Ernst [EMAIL PROTECTED] wrote: 7.1 Initiation Given recent discussions on logo and User Experience, this needs to be different. Instead of: To initiate OpenID Authentication, the Relying Party SHOULD present the end user with a form that has a field for entering an Identifier. It is RECOMMENDED that a Relying Party place the OpenID logo at the beginning of the form field where the end user enters their Identifier. This aides in end user recognition that they can use an OpenID enabled Identifier at the Relying Party. Better: This document does not define a user experience. It is RECOMMENDED that implementors follow the OpenID user experience if and when such an OpenID user experience has been defined in a separate document. Proposed resolution? I've taken out the logo recommendation and left it with an input field in a form with the appropriate name attribute. The user-experience document won't contradict *that* much, and it's a technical necessity (for e.g. smart software agents to detect the login field). See http://openid.net/svn/listing.php?repname=specificationspath=% 2Frev=212sc=1 Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
On 12/12/06, Joaquin Miller [EMAIL PROTECTED] wrote: How about one of these: When a message is sent as a POST, OpenID parameters MUST be sent only in the POST body and the parameters processed MUST be only those from the POST body. When a message is sent as a POST, OpenID parameters MUST be sent only in and processed only from the POST body. Instead of: When a message is sent as a POST, OpenID parameters MUST only be sent in and processed from the POST body. (I feel the first of the two alternative above captures the intention much better. We are aiming to make each clause of this document clear for folks who don't already know what we have in mind, right?) I think Johnny's wording is fine, but if it were to be changed, I would prefer the second of the two alternatives that you proposed. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
On Dec 11, 2006, at 16:41, Johnny Bufu wrote: Hi Johannes, Josh and I went through the remaining issues, so I have addressed and/or commented on some of them below. For easier tracking I've inserted [josh] after the ones that Josh agreed to handle. Looking forward to Josh's input. Some comments on the closed and non-Josh issues. When a message is sent as a POST, OpenID parameters MUST only be sent in and processed from the POST body. That works, good idea. 5.1.2.2 Error Responses, and also 5.2.3 Indirect Error Responses Please clarify which language is supposed to be used for the error field, and what a party should do that receives such an error string, such as: # error Value: Unstructured text error message that SHOULD use the English language. This error message is intended to be used by technically-savvy personnel to debug problems. It is not intended to be shown to the end user. My opinion is that specifying a language is out of scope for the spec; it's up to the RP/OP to choose it. Being unstructured text, I assume it's intended to be passed (eventually) to a human behind the party receiving it. My point is that you assume and I assume and it would be good if we all assumed the same. Which is why I'm proposing to at least put a SHOULD in there for that assuming. Josh and I agreed that the language should not be specified, and be left to RPs / OPs to choose the one that is most useful for their users. We have edited it and it now reads: A human-readable message indicating the cause of the error. I think this is better, but it opens it up to the argument from the i18n community that this won't work -- and justly so. Which is why I said that the target audience is only developers, not end users. 9.2. Realm Remove last sentence in first paragraph, because it is unclear what this is needed for. (Or, alternatively, explain why an OP needs to uniquely identify RPs). Rephrased a bit, so that the intent is clearer; it now reads: The realm SHOULD be used by OPs to uniquely identify Relying Parties. For example, OPs MAY use the realm to allow the end user to automate approval of authentication requests. Also, this is the place where to say that OPs cannot prevent RPs from doing something else than the realm they give. Resolution? Not sure what exactly you meant by doing something else than the realm they give. We had a discussion somewhere some time about whether or not what's now called realm has any security properties. We came to the conclusion that there was no way for anybody to enforce realm and thus it was only to be used as an informational message to the end user. For example, the specified realm could be example.com/foo/bar but what the RP does is *.example.com. My comment was meant to suggest this could be added here. 11.2.2.2 Response Parameters Not clear which values MUST be present and which not. Also: the language in this section is confusing. I don't quite understand it. Not sure I can make a suggestion how to explain it better, because so far I don' tunderstand it. Resolution? I'll try to rephrase the three paragraphs in there. In the meantime, it would help if you could point what you found the most confusing. I'm just raising the General Confusion Fault ;-) That might just be me, however. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
When a message is sent as a POST, OpenID parameters MUST only be sent in and processed from the POST body. Does that mean the same as this: When a message is sent as a POST, OpenID parameters MUST be sent only in the POST body; the parameters processed MUST be only those from the POST body. If so, is the latter better? Cordially, Joaquin ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
On 12-Dec-06, at 11:31 AM, Joaquin Miller wrote: When a message is sent as a POST, OpenID parameters MUST only be sent in and processed from the POST body. Does that mean the same as this: When a message is sent as a POST, OpenID parameters MUST be sent only in the POST body; the parameters processed MUST be only those from the POST body. The second part of your text should say OpenID parameters to be equivalent. Also, one could argue that it's not clear if the first part (when a message is sent as a POST) also applies to the second statement, the one after the ;. If so, is the latter better? Given the above, I favor the text I came up with yesterday. Thanks, Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
Thanks, Johnny. Good points. How about one of these: When a message is sent as a POST, OpenID parameters MUST be sent only in the POST body and the parameters processed MUST be only those from the POST body. When a message is sent as a POST, OpenID parameters MUST be sent only in and processed only from the POST body. Instead of: When a message is sent as a POST, OpenID parameters MUST only be sent in and processed from the POST body. (I feel the first of the two alternative above captures the intention much better. We are aiming to make each clause of this document clear for folks who don't already know what we have in mind, right?) Cordially, Joaquin ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
Hi Johannes, Josh and I went through the remaining issues, so I have addressed and/ or commented on some of them below. For easier tracking I've inserted [josh] after the ones that Josh agreed to handle. Thanks again for the feedback! The spec looks definitely better now than a few days ago. Johnny On 11-Dec-06, at 9:41 AM, Johannes Ernst wrote: Commenting just on the remaining items ... The terminology section (between User-supplied Identifier and Public Identifier) implies that I MUST NOT ever enter a Private Identifier at a Relying Party. While I understand that this might not be the usual case, I don't think it should be prohibited at all. Better: User-supplied Identifier An Identifier that was presented by the end user to the Relying Party. During the initiation phase of the protocol, an end user may enter either a Public Identifier, a Private Identifier or an OP Identifier. If an OP Identifier is used, the OP may then assist the end user in selecting either a Public Identifier or a Private Identifier to share with the Relying Party. The Public-Identifier was removed from the terminology section, as it was used in a single other place in the spec. The user-supplied identifier can be an identifier that the user owns (private or public), or an OP Identifier. I don't understand what you are saying. Are you saying you are making a change to the document (if so, which?) or not, in which case -- are you saying that entering a private identifier at a site is or isn't prohibited? (I am arguing that it should not be prohibited) During IIW we removed the Public Identifier from the definitions section, because it was used in only one other place in the document. The latest version in SVN allows any type of identifiers (private / public / OP-) to be entered at the RP. Section 4.1.1 - Key-Value Form Encoding If in the key-value form, I wish to transmit a value that includes a '\n', what am I supposed to do? Encode it such that it doesn't have a '\n' in it, e.g using base64. If '\n' was allowed, the protocol would permit the kind of attack described in this thread: http://openid.net/pipermail/specs/2006-November/000901.html I understand that is one possible fix. What about we define one of the possible fixes as the canonical fix for text data, otherwise different implementors will implement different fixes (base64, C- style \n, URL-style %0D%0a, ... ) and interop will suffer. [josh] Section 4.1.2 HTTP Encoding Second paragraph currently says: All of the keys in the request message MUST be prefixed with openid.. This prefix prevents interference with other parameters that are passed along with the OpenID Authentication message. When a message is sent as a POST, the application processing the HTTP request MUST only use the values in the POST body and MUST ignore any GET parameters. I think I pointed out earlier that this is more restrictive than necessary, and prevents certain implementations that make sense, such as using a service endpoint URL like http://example.com/endpoint?bizmodel=free http://example.com/endpoint?bizmodel=premium because it says that those parameters must be dropped. Further, are you guys sure that there is such a thing as a GET Parameter in the appropriate URI / HTTP standards? If so, I wonder where that is defined, because I can't find it. Better: All of the keys in the request message MUST be prefixed with openid.. This prefix prevents interference with other parameters that are passed along with the OpenID Authentication message. When a message is sent as a POST, the application processing the HTTP request MUST ignore those values provided as GET parameters for which identically-named POST parameters exist in the same request. Is there a proposed solution to this issue or does it remain open? We've made is a bit more strict; it now reads: When a message is sent as a POST, OpenID parameters MUST only be sent in and processed from the POST body. 5.1.2.2 Error Responses, and also 5.2.3 Indirect Error Responses Please clarify which language is supposed to be used for the error field, and what a party should do that receives such an error string, such as: # error Value: Unstructured text error message that SHOULD use the English language. This error message is intended to be used by technically-savvy personnel to debug problems. It is not intended to be shown to the end user. My opinion is that specifying a language is out of scope for the spec; it's up to the RP/OP to choose it. Being unstructured text, I assume it's intended to be passed (eventually) to a human behind the party receiving it. My point is that you assume and I assume and it would be good if we all assumed the same. Which is why I'm proposing to at least put a SHOULD in there for that assuming.
Re: Comments on Auth 2.0 - Pre-Draft 11
Johannes, On 8-Dec-06, at 11:08 AM, Johannes Ernst wrote: Dear Authentication 2.0 editors, I know you are going to hate me (more changes!), but I hope the attached comments are useful as you construct the final version of the OpenID 2.0 Authentication document. Not at all! As an implementer of the spec, I can assure you that more clarity is always desired. Thanks for all the patches. I've already checked-in some of them, and on others I have commented below. Johnny Section 2 - Terminology: It says: OP Endpoint URL: The URL which accepts OpenID Authentication requests, discovered by dereferencing the end user's Identifier. This value MUST be an absolute URL. Deferencing is a term that's unclear in this context. Better: OP Endpoint URL: The URL which accepts OpenID Authentication requests, found by performing discovery on the the end user's Identifier. This value MUST be an absolute URL. Done. -- The terminology section (between User-supplied Identifier and Public Identifier) implies that I MUST NOT ever enter a Private Identifier at a Relying Party. While I understand that this might not be the usual case, I don't think it should be prohibited at all. Better: User-supplied Identifier An Identifier that was presented by the end user to the Relying Party. During the initiation phase of the protocol, an end user may enter either a Public Identifier, a Private Identifier or an OP Identifier. If an OP Identifier is used, the OP may then assist the end user in selecting either a Public Identifier or a Private Identifier to share with the Relying Party. The Public-Identifier was removed from the terminology section, as it was used in a single other place in the spec. The user-supplied identifier can be an identifier that the user owns (private or public), or an OP Identifier. -- Section 4.1.1 - Key-Value Form Encoding If in the key-value form, I wish to transmit a value that includes a '\n', what am I supposed to do? Encode it such that it doesn't have a '\n' in it, e.g using base64. If '\n' was allowed, the protocol would permit the kind of attack described in this thread: http://openid.net/pipermail/specs/2006-November/000901.html -- Section 4.1.2 HTTP Encoding Second paragraph currently says: All of the keys in the request message MUST be prefixed with openid.. This prefix prevents interference with other parameters that are passed along with the OpenID Authentication message. When a message is sent as a POST, the application processing the HTTP request MUST only use the values in the POST body and MUST ignore any GET parameters. I think I pointed out earlier that this is more restrictive than necessary, and prevents certain implementations that make sense, such as using a service endpoint URL like http://example.com/endpoint?bizmodel=free http://example.com/endpoint?bizmodel=premium because it says that those parameters must be dropped. Further, are you guys sure that there is such a thing as a GET Parameter in the appropriate URI / HTTP standards? If so, I wonder where that is defined, because I can't find it. Better: All of the keys in the request message MUST be prefixed with openid.. This prefix prevents interference with other parameters that are passed along with the OpenID Authentication message. When a message is sent as a POST, the application processing the HTTP request MUST ignore those values provided as GET parameters for which identically-named POST parameters exist in the same request. -- 4.2 Integer representation I love your use of henceforth. It has always been one of my favorite words in the English language. ;-) -- 5.1.2.2 Error Responses, and also 5.2.3 Indirect Error Responses Please clarify which language is supposed to be used for the error field, and what a party should do that receives such an error string, such as: # error Value: Unstructured text error message that SHOULD use the English language. This error message is intended to be used by technically-savvy personnel to debug problems. It is not intended to be shown to the end user. My opinion is that specifying a language is out of scope for the spec; it's up to the RP/OP to choose it. Being unstructured text, I assume it's intended to be passed (eventually) to a human behind the party receiving it. -- 5.2.2 HTML FORM Redirection I don't think you need to restrict this to JavaScript. There are other languages, too, and there is no need to create a dependency on JavaScript here. Better: A mapping of keys to values can be transferred by returning an HTML page to the User-Agent that contains an HTML form element. Form submission MAY be automated, such as by using JavaScript. Done - your wording is clearer, but your reasoning and conclusion about the previous wording weren't exactly
Comments on Auth 2.0 - Pre-Draft 11
Dear Authentication 2.0 editors, I know you are going to hate me (more changes!), but I hope the attached comments are useful as you construct the final version of the OpenID 2.0 Authentication document. The good news is that you are close. ;-) Cheers, Johannes. Section 2 - Terminology: It says: OP Endpoint URL: The URL which accepts OpenID Authentication requests, discovered by dereferencing the end user's Identifier. This value MUST be an absolute URL. Deferencing is a term that's unclear in this context. Better: OP Endpoint URL: The URL which accepts OpenID Authentication requests, found by performing discovery on the the end user's Identifier. This value MUST be an absolute URL. -- The terminology section (between User-supplied Identifier and Public Identifier) implies that I MUST NOT ever enter a Private Identifier at a Relying Party. While I understand that this might not be the usual case, I don't think it should be prohibited at all. Better: User-supplied Identifier An Identifier that was presented by the end user to the Relying Party. During the initiation phase of the protocol, an end user may enter either a Public Identifier, a Private Identifier or an OP Identifier. If an OP Identifier is used, the OP may then assist the end user in selecting either a Public Identifier or a Private Identifier to share with the Relying Party. -- Section 4.1.1 - Key-Value Form Encoding If in the key-value form, I wish to transmit a value that includes a '\n', what am I supposed to do? -- Section 4.1.2 HTTP Encoding Second paragraph currently says: All of the keys in the request message MUST be prefixed with openid.. This prefix prevents interference with other parameters that are passed along with the OpenID Authentication message. When a message is sent as a POST, the application processing the HTTP request MUST only use the values in the POST body and MUST ignore any GET parameters. I think I pointed out earlier that this is more restrictive than necessary, and prevents certain implementations that make sense, such as using a service endpoint URL like http://example.com/endpoint?bizmodel=free http://example.com/endpoint?bizmodel=premium because it says that those parameters must be dropped. Further, are you guys sure that there is such a thing as a GET Parameter in the appropriate URI / HTTP standards? If so, I wonder where that is defined, because I can't find it. Better: All of the keys in the request message MUST be prefixed with openid.. This prefix prevents interference with other parameters that are passed along with the OpenID Authentication message. When a message is sent as a POST, the application processing the HTTP request MUST ignore those values provided as GET parameters for which identically-named POST parameters exist in the same request. -- 4.2 Integer representation I love your use of henceforth. It has always been one of my favorite words in the English language. ;-) -- 5.1.2.2 Error Responses, and also 5.2.3 Indirect Error Responses Please clarify which language is supposed to be used for the error field, and what a party should do that receives such an error string, such as: # error Value: Unstructured text error message that SHOULD use the English language. This error message is intended to be used by technically-savvy personnel to debug problems. It is not intended to be shown to the end user. -- 5.2.2 HTML FORM Redirection I don't think you need to restrict this to JavaScript. There are other languages, too, and there is no need to create a dependency on JavaScript here. Better: A mapping of keys to values can be transferred by returning an HTML page to the User-Agent that contains an HTML form element. Form submission MAY be automated, such as by using JavaScript. -- 6.3 Signature Algorithms Everything after RECOMMENDED is unnecessary because it expresses an opinion about the state of the market, which has no role in this kind of document -- 7.1 Initiation Given recent discussions on logo and User Experience, this needs to be different. Instead of: To initiate OpenID Authentication, the Relying Party SHOULD present the end user with a form that has a field for entering an Identifier. It is RECOMMENDED that a Relying Party place the OpenID logo at the beginning of the form field where the end user enters their Identifier. This aides in end user recognition that they can use an OpenID enabled Identifier at the Relying Party. Better: This document does not define a user experience. It is RECOMMENDED that implementors follow the OpenID user experience if and when such an OpenID user experience has been defined in a separate document. -- 7.2 Normalization I'm not sure that this -- all of which is OPTIONAL -- should be in this document. I would suggest to either make it MANDATORY -- or to take
