Trouble with base64-encoded OpenID claimed_id paths

Andrew Arnott andrewarnott at gmail.com
Mon Apr 5 18:46:05 UTC 2010


FYI

I just uploaded an interop test to test-id.org to measure whether an RP can
ingest claimed_id's with periods in them:
http://test-id.org/RP/TrailingPeriodsInClaimedIdPath.aspx

As part of my investigation I also came to realize that a capitalized scheme
or hostname in the claimed_id field can screw with the minds of several RPs,
so I enhanced an existing test to check for proper signature verification in
this case.
http://test-id.org/RP/SignatureCheck20.aspx

--
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 Sat, Mar 27, 2010 at 12:44 AM, John Bradley <john.bradley at wingaa.com>wrote:

> Fair enough.
>
> For new implementations we should probably encourage people using the RFC.
>
> Because the problem more or less random I didn't notice anything until we
> had more people participating in the latest interop tests for the GSA.
>
> one of the GSA folks Yahoo account triggers the bug in Andrews library and
> a separate bug in the Drupal RP.
>
> It is a problem that may exist in more than one RP,  so we should test for
> it.
>
> RP with issues will have to decide what they do about those problem Yahoo
> accounts.
>
> I am not saying Yahoo has done anything wrong,  but we have an interop
> issue non the less.
>
> I don't think there is anything you can do at this point.
>
> My concern is that people who have just implemented PPID to support the GSA
> profile look at there code before it starts being used in production.
>
> John B.
>
> On 2010-03-27, at 12:00 AM, Allen Tom wrote:
>
> 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 at 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/20100405/e28bc53b/attachment.htm>


More information about the specs mailing list