Re: password-free login without SSL and OP reliance (an anti-phishing solution)
Douglas Otis wrote: For clarity, OpenID Authentication 2.0 - Draft 11 4.1.1. Key-Value Form Encoding should change to something like Keyword-Value Form Encoding. Avoid using the word key to mean field or label. This will cause confusion. While I believe that key-value pairs is a common enough term that confusion is unlikely by any knowledgeable developer, I suggest that if it be changed it be changed to name-value form encoding, since I think this is more commonly used than keyword-value. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)
Johnny Bufu wrote: I believe a key difference here is between what people would be willing to do, and what people actually (will) do. For example: - I would be willing to go to a rugby game, but I don't know if any of my friends are going, so I probably won't go - most of my friends who like rugby may be thinking and acting the same way, or - most of my friends would go if they knew rugby, but they haven't discovered it yet. From a purely selfish point of view, I'm happy for this discussion to take part on the specs list just so I don't have to join and configure YET ANOTHER MAILING LIST(tm). :) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)
Johnny Bufu wrote: These two seem to have been the rationale of the recent discussions about splitting the OpenID spec into core/discovery/etc., which seemed to make sense to a number of people (I'm just not sure if it's worth / good tactical move at this stage). I tend to think it's a good idea to modularize specifications in the same way as you'd probably modularize the implementation. This is why[1] I was pushing for separate Auth / service discovery stuff: the service discovery stuff is obviously useful for things other than auth, and there are *already* separate libraries for it (Service::Yadis and friends), so it makes sense for it to be given as a separate specification. On the other hand, I also think it's a good idea not to modularize too early: until there's some implementation experience, it's hard to say with certainty what parts make sense as distinct modules. I'm not that familiar with the AX stuff yet, but my gut feeling is that it'd be a good idea for someone to make an experimental implementation to get some implementation experience and then it'll probably be a lot more clear where the articulation points are that make spec modularization worthwhile. There's little point in debating it at this early stage, in my opinion. - [1] One of the reasons, anyway. The other reason was to reach a situation where the OpenID Authentication specification can largely reference only other specifications under the OpenID umberella, which means bringing the Yadis tech into OpenID land (which it basically already is, despite the distinct brand) and defining a subset of the XRDS schema to avoid referencing the entirety of XRI Resolution 2.0, which contains lots of stuff that is not necessary for OpenID and related tech. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: password-free login without SSL and OP reliance (an anti-phishing solution)
On Sat, 2007-04-07 at 11:43 +0100, Martin Atkins wrote: Douglas Otis wrote: For clarity, OpenID Authentication 2.0 - Draft 11 4.1.1. Key-Value Form Encoding should change to something like Keyword-Value Form Encoding. Avoid using the word key to mean field or label. This will cause confusion. While I believe that key-value pairs is a common enough term that confusion is unlikely by any knowledgeable developer, I suggest that if it be changed it be changed to name-value form encoding, since I think this is more commonly used than keyword-value. For me, he term key-value was a bit confusing because it was not explicit. This term key currently refers to either fields or sub-fields in sections- 4.1.2., 5.1.1., 5.1.2., 5.1.2.2., 5.2., 7.1., 10.1., 11.2., 11.4.1., 11.4.2.1., 14.2., 15.1.2. There are sub-fields identified as name where the term name would get confusing in section 5.2.2., 7.1., 9.2., 12. and A.5. How about this: --- 4.1. Protocol Messages The OpenID Authentication protocol messages are mappings of plain-text labels to plain-text values. The keys and values permit the full Unicode character set (UCS). When the keys and values need to be converted to/from bytes, they MUST be encoded using UTF-8(Yergeau, F., “UTF-8, a transformation format of Unicode and ISO 10646,” .) [RFC3629]. Messages MUST NOT contain multiple parameters with the same label. Throughout this document, all OpenID message parameters are REQUIRED, unless specifically marked as OPTIONAL. 4.1.1. Label-Value Form Encoding A message in Label-Value form is a sequence of lines. Each line begins with a field label, followed by a colon, and the value associated with the label. The line is terminated by a single newline (UCS codepoint 10, \n). A label or value MUST NOT contain a newline and a label also MUST NOT contain a colon. Additional characters, including whitespace, MUST NOT be added before or after the colon or newline. The message MUST be encoded in UTF-8 to produce a byte string. Label-Value Form encoding is used for signature calculation and for direct responses(Direct Response) to Relying Parties. For brevity, this specification may refer to sub-components of the label. For example, the field label openid.mode may be referenced as just mode. --- This would then require all locations that use the term key when referring to a field label to be changed to label. -Doug ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Label replacing Key
On Sat, 2007-04-07 at 08:58 -0700, Douglas Otis wrote: Oops. I missed two references to keys. --- 4.1. Protocol Messages The OpenID Authentication protocol messages are mappings of plain-text labels to plain-text values. The labels and values permit the full Unicode character set (UCS). When the labels and values need to be converted to/from bytes, they MUST be encoded using UTF-8(Yergeau, F., “UTF-8, a transformation format of Unicode and ISO 10646,” .) [RFC3629]. Messages MUST NOT contain multiple parameters with the same label. Throughout this document, all OpenID message parameters are REQUIRED, unless specifically marked as OPTIONAL. 4.1.1. Label-Value Form Encoding A message in Label-Value form is a sequence of lines. Each line begins with a field label, followed by a colon, and the value associated with the label. The line is terminated by a single newline (UCS codepoint 10, \n). A label or value MUST NOT contain a newline and a label also MUST NOT contain a colon. Additional characters, including whitespace, MUST NOT be added before or after the colon or newline. The message MUST be encoded in UTF-8 to produce a byte string. Label-Value Form encoding is used for signature calculation and for direct responses(Direct Response) to Relying Parties. For brevity, this specification may refer to sub-components of the label. For example, the field label openid.mode may be referenced as just mode. --- This would then require all locations that use the term key when referring to a field label to be changed to label ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Label replacing Key
On 4/7/07, Douglas Otis [EMAIL PROTECTED] wrote: This would then require all locations that use the term key when referring to a field label to be changed to label -1 If it needs to be changed, Martin's suggestion of name instead is much better. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Label replacing Key
On Sat, 2007-04-07 at 10:30 -0700, Josh Hoyt wrote: On 4/7/07, Douglas Otis [EMAIL PROTECTED] wrote: This would then require all locations that use the term key when referring to a field label to be changed to label -1 If it needs to be changed, Martin's suggestion of name instead is much better. Okay, but the use of name should be explicitly defined. The use of just name creates some ambiguity with the name attribute. Review sections 5.2.2. and 7.1.. Or with DNS name in 9.2. and and 12. The OpenID draft refers to the field name and to the right most labels of the field name as being synonymous with key. This short-hand should be clearly defined using other terms. Key is not a term used in w3.org definitions, that tend to use the all encompassing keyword instead. Key normally refers to keyboard keys, or cryptographic keys. Unfortunately Name does not permit an explicit definition due to conflicts within the spec and the ambiguity when using subordinate naming elements. note: rfc2822 (2.2.) for email defines roughly the same structure as field name followed by a field body. rfc1034 (3.1.) for dns defines names as a tree structure of labels. How about: Additional terms clarified within the terminology section such as: --- 2. Terminology ... Attribute: Attributes hold associated properties of HTML elements and may have values. Attribute/value pairs appear before the final of an element's start tag. Any number of (legal) attribute value pairs, separated by spaces, may appear in any order within an element's start tag. Message Parameter: Message Parameters are in Field Name-Value Form as a sequence of lines terminated by a single newline (UCS codepoint 10, \n). Each line begins with a field name, followed by a colon, and a single value or a comma separated list associated with the field name. Short Name: A Short Name is resolved by removing or assuming an openid prefix of an associated Field Name. --- --- 4.1. Protocol Messages The OpenID Authentication protocol messages parameters are mappings of plain-text field names to plain-text field values. The field names and field values permit the full unicode character set (UCS). When the field names and field values need to be converted to/from bytes, they MUST be encoded using UTF-8 (Yergeau, F., “UTF-8, a transformation format of Unicode and ISO 10646,”) [RFC3629]. Messages MUST NOT contain multiple values within the same field name. Throughout this document, all OpenID message parameters are REQUIRED, unless specifically marked as OPTIONAL. 4.1.1. Field Name-Value Form Encoding A message in Field Name-Value Form is a sequence of lines. Each line begins with a field name, followed by a colon, and the field value associated with the field name. The line is terminated by a single newline (UCS codepoint 10, \n). A field name or field value MUST NOT contain a newline and a field name also MUST NOT contain a colon. Additional characters, including whitespace, MUST NOT be added before or after the colon or newline. The message MUST be encoded in UTF-8 to produce a byte string. A Short Name-Value Form of encoding is used for signature calculation and for direct responses(Direct Response) to Relying Parties. See sections 5.1.2, 5.1.2.2, 6.1, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 11.4.2.2. --- This change requires all locations that use the term key when referring to a field name to be changed to field name. When referring to a derived short name to be changed to short name. -Doug ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Label replacing Key
On Sat, 2007-04-07 at 18:22 -0700, Douglas Otis wrote: Oops. 4.1. Protocol Messages (second paragraph) Messages MUST NOT contain multiple values within the same field name. Messages MUST NOT contain message parameters with the same field name. -Doug ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: SREG namespace URI rollback
On 2-Apr-07, at 6:06 PM, Recordon, David wrote: Sure, though I think there has also been a desire to do a bit of an Are we in agreement then (about 1.0 and 1.1 sharing the same type URI)? I went ahead and implemented SREG in openid4java, and exposed it in such a way that the users won't have to know about all these v1.0 / 1.1 details. But in order for that to work and my implementation to be compliant, the type URI of SREG 1.1 needs to change as proposed by Josh in the next (final?) draft. Thanks, Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
