Trouble with base64-encoded OpenID claimed_id paths

[Andrew Arnott]

Fair points, Dick.

Working around the faulty code in .NET would require rewriting the entire
HTTP stack (I'm not kidding), and it wouldn't work on shared hosting servers
either due to security gates in .NET and the shared hosts.  But I have some
other hacky workarounds in mind... each with their downsides, but at least
they can still leverage the existing HTTP stack.

--
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 Thu, Mar 25, 2010 at 4:43 PM, Dick Hardt <dick.hardt at gmail.com> wrote:

> Perhaps you need to sink to a lower level in a .Net implementation so that
> you can work around the issue. Changing a spec to deal with a bug in an
> implementation does not seem like the right path. .Net should be able to
> parse URIs properly, and when it does not, the module needs to work around
> this.
>
> I recall having to do this often in Perl on Windows where the MS library
> did not work per standards. A real pain in the ass, but the reality of the
> situation.
>
> On Thu, Mar 25, 2010 at 3:56 PM, Andrew Arnott <andrewarnott at gmail.com>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
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100325/026238f1/attachment.htm>