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 <[email protected]>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" <[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
