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