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
I think this is better, but it just occurs to me that we don't necessarily want to limit this to "authorized end users" -- it could also be "authorized software agents" or what have you. On Dec 15, 2006, at 16:27, Josh Hoyt wrote: > 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=specifications&path=%2F&rev=235&sc=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
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=specifications&path=% > 2F&rev=236&sc=1 > > > Johnny ___ 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=specifications&path=% 2F&rev=236&sc=1 Johnny ___ 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=specifications&path=%2F&rev=235&sc=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/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
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=specifications&path=% > 2F&rev=212&sc=1 > > 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=specifications&path=% >> 2F&rev=201&sc=1 >> and http://openid.net/svn/listing.php?repname=specifications&path=% >> 2F&rev=209&sc=1 >> >> Josh ___ 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: 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
On 12/11/06, Johannes Ernst <[EMAIL PROTECTED]> wrote: > >> 14. Discovering OpenID Relying Parties > >> > >> Can I ask to append the following sentence? > >>> The element is OPTIONAL for this use of the > >>> element. If the element is not given, it > >>> is assumed to be the URI on which Yadis discovery was performed > >>> to lead to the XRDS document. > >> > >> This would be a useful default that would come very handy. And > >> right now, the way it is written, this is underdefined in any case. > > Resolution? I made the section explicit on requiring the element to be present. [1] This isn't what you asked for, but it avoids the issue of e.g. what to do if the discovery was performed on an XRI. I hope this is satisfactory. Josh 1. http://openid.net/svn/listing.php?repname=specifications&path=%2F&rev=213&sc=1 ___ 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: 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=specifications&path=%2F&rev=201&sc=1 > and > http://openid.net/svn/listing.php?repname=specifications&path=%2F&rev=209&sc=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/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=specifications&path=%2F&rev=212&sc=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
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
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
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 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
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
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
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
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 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
Just wanted to give a +1 - For all recent changes being discussed. Not so much by the revised language used in the spec - which I agree is *totally* important - but its the discussion that goes on between the knowledgeable parties, coming up with the consensus, that is really helping me to learn / catch-up. I realise it is the theme of open-source communities, but none the less wanted to put forward my appreciation for everyone's time/effort. >>> On Tuesday, December 12, 2006 at 11:41, in message <[EMAIL PROTECTED]>, Johnny Bufu <[EMAIL PROTECTED]> 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. > > > 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 >> se
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 assum
Re: Comments on Auth 2.0 - Pre-Draft 11
Fair enough ;-) You know what I mean ... the opposite of OPTIONAL. On Dec 11, 2006, at 9:59, Josh Hoyt wrote: > On 12/11/06, Johannes Ernst <[EMAIL PROTECTED]> wrote: >> >> It is unclear which of those parameters are MANDATORY and which >> >> are OPTIONAL > > Thanks for your detailed reading and feedback. I'm not commenting in > this message about any specific point that you have, but just pointing > out that RFC2119 does not define MANDATORY. > > Today I'll be talking to Johnny and hopefully we'll have some good > feedback about specifics after that. > > 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: > >> It is unclear which of those parameters are MANDATORY and which > >> are OPTIONAL Thanks for your detailed reading and feedback. I'm not commenting in this message about any specific point that you have, but just pointing out that RFC2119 does not define MANDATORY. Today I'll be talking to Johnny and hopefully we'll have some good feedback about specifics after that. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Comments on Auth 2.0 - Pre-Draft 11
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) 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. 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? 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. 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 Proposed resolution? 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 fol
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 b
