Allen, what you're doing is a perfectly legal URL, AFAIK. I'm don't mean to imply Yahoo is doing something wrong. I'm just saying it's problematic for one of your clients.
-- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Fri, Mar 26, 2010 at 9:00 PM, Allen Tom <[email protected]> wrote: > Um, we’ve been doing this since 1996, waaay before the RFC. > > > Allen > > > > > On 3/26/10 7:57 PM, "John Bradley" <[email protected]> wrote: > > Allen for URL safe base64 encoding + (plus) is replaced by - (minus) not . > (period) close but someone misread the RFC. > http://www.faqs.org/rfcs/rfc3548.html > > Not quite sure what you can do about it at this point. > > John B. > On 2010-03-26, at 10:15 PM, Allen Tom wrote: > > The Yahoo proprietary version of base64 is like regular base64 but is URL > safe. In our version of base64, the + character is substituted with “.” > > As far as I can tell, what we’re doing is perfectly legal.... > Allen > > > On 3/25/10 4:15 PM, "John Bradley" <[email protected] <x-msg: > //139/[email protected] <http:///139/[email protected]>> > > wrote: > > I don't know that it is plausible for OP to change existing claimed_id that > will break real customers. > > I also don't know of a base64 encoding that includes . The characters in > base64 that is normally an issue for URL are + / the URL base64 replaces > that with minus and underscore > > Now that you mention it I did see similar issues from the Drupal RP not > long ago with Yahoo. > > Recommending RFC4648 encoding with URL safe alphabet for new OP's is > reasonable. > > I would like to understand why Yahoo is doing that. > > John B. > > On 2010-03-25, at 6:56 PM, Andrew Arnott wrote: > > It turns out that .NET apparently makes it *impossible* to perform > identifier discovery when the claimed_id includes periods at the end of any > segment of the URI path. Some pseudonymous identifiers include base64 > encoded parts in their paths (Yahoo is one such OP) which will at times end > with a period, making discovery on this identifier impossible from a .NET > RP. > > While .NET limitations are not Yahoo's problem or any other OP, I wonder if > a future version of the OpenID spec might suggest that OPs avoid ending path > segments of their issued claimed_id's with periods, perhaps by tacking on a > hyphen or something at the end of all base64 encoded strings that appear in > URI paths. Obviously being retroactive is problematic, but perhaps newly > issued OpenIDs can do this to help OP's customers to log into .NET clients. > Another fix would be to use base64url as outlined in RFC 4648 < > http://www.ietf.org/rfc/rfc4648.txt> instead of a base64 that uses > periods. > > .NET 4.0, which has not yet released, includes an undesirable (but at least > possible) workaround for this limitation, but since it opens up other > security concerns to activate this workaround and since the .NET 4.0 install > base is close to 0% and will remain low for some time through the near > future, so accounting for this limitation would be most helpful to promote > interoperability. > > (I hate saying .NET is insufficient to fit the bill, but it's the sad truth > in this instance). > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre > _______________________________________________ > specs mailing list > [email protected] > <x-msg://139/[email protected]<http:///139/[email protected]>> > > http://lists.openid.net/mailman/listinfo/openid-specs > > > > ------------------------------ > _______________________________________________ > specs mailing list > [email protected] > <x-msg://139/[email protected]<http:///139/[email protected]>> > > http://lists.openid.net/mailman/listinfo/openid-specs > > > >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
