[OpenID] http and https...again

[Joe Tele]

Yes, it has nothing to do with fragments or recycling.  It has to do with inconsistencies with how OPs normalize (or not) their user's claimed ids from user supplied indentifiers.  Verisign does nothing.  These are types of things which could be argued as "features" or "bugs" but in my opinion could result in user base confusion (and RP confusion).  


--- On Mon, 9/8/08, SitG Admin <sysadmin at shadowsinthegarden.com> wrote:

> From: SitG Admin <sysadmin at shadowsinthegarden.com>
> Subject: Re: [OpenID] http and https...again
> To: "Joe Tele" <pnwtele at yahoo.com>
> Cc: general at openid.net
> Date: Monday, September 8, 2008, 1:38 PM
> >http://openid.net/pipermail/general/2008-September/005426.html
> 
> I don't know about Verizon, but your reference to a
> user typing in 
> this extra information is a clue that this doesn't have
> to do with 
> generation fragments (distinguishing between successive
> users with 
> the same URI). I'm thinking it's either a user
> identification method 
> (such as Sun offers to assert "This is one of our
> employees, but 
> we're not saying exactly who.") that tells the OP
> (in this case, 
> Verizon) who the user is claiming to be (facilitating the
> login flow) 
> without revealing anything meaningful about the user's
> identity to 
> the RP, or something weird with how Verizon is resolving
> claimed_id 
> (if the URI is different enough to not qualify as the same
> user 
> anymore, you'd think Verizon's OP would detect that
> and return an 
> error that the user did not exist).
> 
> Are you getting these "?a=1" variables appended
> by real users, or are 
> they just showing up in tests? If the former, I'd
> assume it to be 
> there for a reason; if the latter, I'd contact Verizon
> about it.
> 
> -Shade