Trouble with base64-encoded OpenID claimed_id paths

Andrew Arnott andrewarnott at gmail.com
Thu Mar 25 22:56:48 UTC 2010


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100325/131e4dbe/attachment.htm>


More information about the specs mailing list