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]> 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] >>> http://lists.openid.net/mailman/listinfo/openid-specs >> >> >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
