Trouble with base64-encoded OpenID claimed_id paths

[Allen Tom]

Um, we¹ve been doing this since 1996, waaay before the RFC.


Allen



On 3/26/10 7:57 PM, "John Bradley" <john.bradley at wingaa.com> 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" <john.bradley at wingaa.com
>> <x-msg://139/john.bradley@wingaa.com> > 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
>>>> specs at lists.openid.net <x-msg://139/specs@lists.openid.net>
>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> specs mailing list
>>> specs at lists.openid.net <x-msg://139/specs@lists.openid.net>
>>> http://lists.openid.net/mailman/listinfo/openid-specs
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100326/ed60a83f/attachment-0001.htm>