Re: OpenID Exchange
Recordon, David wrote: Awesome, glad to see this! Would be great as Johannes said to see some flow examples and how you'd see it integrate to do something like exchange profile data or post a photo on your blog. Would love to see this formalized and happy to help however I can! I'm hoping to get some working demo examples done this weekend in some form or other, if I get time. Failing that, I'll at least try to get some written, theoretical examples written up for the scenarios I listed in my original message. ___ 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
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
