Re: clarifying section 11.2 in draft 11 for HTML discovery?
On Thu, May 24, 2007 at 10:19:08AM -0700, Josh Hoyt wrote: On 5/24/07, Peter Watkins [EMAIL PROTECTED] wrote: Shouldn't the spec clarify what is required for an HTML discovery to uphold an assertion that triggers 11.2's discovery process? The spec as it is currently written does not support using identifier selection with HTML discovery. That was intentional, to keep things simpler. A user should never have to add markup to trigger identifier selection. That is the responsibility of the OpenID provider. I don't think we need to add a way to trigger identifier selection with HTML discovery. Speaking as a potential OP, I like the idea that I could support directed identity for all my users by simply adding a couple tags to a web page -- for instance, setting openid2.local_id to the identifier_select URL. HTML discovery's simplicity is appealing. It's also appealing to have a single URL that would be usable in an OpenID login form and would display helpful content to users. The XRI spec draft looks overwhelming. Yadis doesn't look too bad -- essentially, any old HTML page could be used, so long as it included one tag that contained the URL of an XRDS file. I would have found it valuable for the openid 2.0 spec to include an example of using a meta http-equiv tag for Yadis discovery. It's too bad Yadis doesn't allow embedding the XRDS document in something like a META tag to avoid that second Yadis HTTP request, but perhaps that's something I should take up at yadis.org. :-) Peter ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: clarifying section 11.2 in draft 11 for HTML discovery?
On 25-May-07, at 11:18 AM, Peter Watkins wrote: It's too bad Yadis doesn't allow embedding the XRDS document in something like a META tag to avoid that second Yadis HTTP request If you send an Accept header that includes application/xrds+xml the OP can return the XRDS document on the first request. (From the Yadis 1.0 spec, Section 6.2.4) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Realm spoofing spec patch
Josh, On 24-May-07, at 4:19 PM, Josh Hoyt wrote: Please review the additions. If you'd like to see the specific changes, you can look at the diffs in revision control[3]. Looks good to me. One minor issue about the wording - we have now two return URL verifications: one done by the OP and a totally different one done by the RP. Would it make sense to call this new one something different, e.g. RP endpoint verification (or validation)? Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Realm spoofing spec patch
On 24-May-07, at 5:54 PM, Recordon, David wrote: I guess since we're unable to fully resolve this issue from a technical perspective, and no I don't have a better technical solution, I'm wondering if this should actually be an extension to the core protocol versus seeming like a resolution to the problem when it really doesn't completely solve it. -1 An extension is totally optional. On the other hand, when I implement a spec I treat all SHOULDs as MUSTs by default, and only examine them if I can't deal with something. The main issue with this attack I believe was the OP making a false statement to their users, thus compromising their trust. Even with the SHOULDs, the OPs have the means to decide how they interact with their users. If this results in not granting access to unverified RPs, the OP can say well, the RP you're trying to go to really SHOULD implement RP discovery. With an extension the OP's statement would be we're using this extension and can't let you go to this RP because they don't implement it and we can't verify their endpoints. Having said that, I would certainly like some of these SHOULDs to be turned into MUSTs if doing so doesn't lead to other issues (deployments, etc.). Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: attribute exchange value encoding
Johnny Bufu wrote: While at IIW, I asked around what people thought about the encoding mechanisms we've added recently, in order to allow for transferring any data types. The consensus was that everyone would prefer something simpler and lighter. So I've rewritten the encoding section, such that: - for strings, only the newline (and percent) characters are required to be escaped, (to comply with OpenID's data formats), using percent-encoding; - base64 must be used for encoding binary data, and defined an additional field for this: openid.ax.encoding.alias=base64 Please review section 3.3 Attribute Values to see if there are any issues. One remaining question is about the choice of encoding for strings. Percent-encoding (RFC3968) seems the simplest from a spec perspective, however some libraries provide (better) support for the older URL-encoding (RFC1738), which throws '+' characters into the mix. Which do you think would work best for implementers, users, and would cause less interop problems? Johnny, FWIW, encoding + can be a hassle as it's a legal character in media type values and is also sometimes used for spaces. I'd vote for pure RFC3986 percent-encoding. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
