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
