Discovery of an OpenID session at an OP

[Chris Obdam]

It sure would be a more transparent way to show the end user that a request to OP is being done with the x-has-session variable.
But this is a solution that requires specific browser functionality. Don't know if that is feasible in the near future?

And it is a bit solving the problem in the wrong way? You now delegate the confirmation of the 'is-logged-in' check to the browser, which askes the end user. Why  not ask the end user in the first way?

Op 15 dec 2009, om 20:46 heeft Peter Watkins het volgende geschreven:

> On Tue, Dec 15, 2009 at 09:12:05AM -0800, Breno de Medeiros wrote:
> 
>> I think John's point is that the mechanism to protect privacy should
>> be optionally available to OPs: There should be a rule to allow OPs to
>> push this information without user consent.
> 
> If it's designed right, the user might not even need the OP's help.
> 
> Generally (at least pre-HTML-5, I'm behind on my reading there), any
> discovery process would probably have to work much like checkid_immediate,
> with the end user's browser being used to convey the RP's discovery request
> and the OP's discovery response -- because the OP needs to see if the browser
> possesses cookies or other authentication credentials for the OP's realm. 
> 
> This OP discovery request/response spec could be designed such that the end
> user's browser could essentially discard the RP's query and assert control
> over his privacy even if the OP was hard-wired to always make the data
> available. E.G., if the RP's request for OP discovery included an 
> OpenID-specific X- response header, then an OpenID-aware browser could
> recognize the 302/Location redirect as actually being a request for OP
> information, and could give the end user the power to block that request
> and send the RP an unsigned response telling the RP that no information 
> would be provided about that user's relationship to the OP.
> 
>> John anchored this point on the fact that the information is already
>> available via DOM/JS tricks. I think that these DOM/JS tricks are not
>> difficult to be fixed on the client side so I would prefer not to make
>> arguments for how to move forward based on accidental circumstances.
> 
> Great, I don't seem to hear anyone arguing the grandfather fallacy now. :-)
> 
>> Regardless of the justification, one could argue that OPs should not
>> be mandated to implement the privacy solution because they may know
>> better what their consumers want. That is good as it goes, but we
>> should still make sure that the design makes it easy for RPs to
>> implement the privacy issue
> 
> You mean easy for the OPs to implement, right?
> 
>> because if it becomes an issue of
>> technical complexity (as opposed to finding out what users want) and
>> there's a loophole (it's optional), then it will likely not be
>> implemented.
> 
> Yes, I think you're quite right.
> 
>> The risk of having no privacy story is a backlash that results in the
>> baby being thrown out with the bath water.
> 
> Right -- providing a mechanism in the spec for protecting privacy will
> allow us to take advantage of the usability improvements for the users
> who choose usability over privacy, which I think we all expect will be
> a large majority of users (especially if OPs tend to default to making
> this information available).
> 
> Tell me, am I the only one who thinks that this "OP discovery" --at least
> the most basic case where an OP only vouches for one particular claimed
> identity or directed identity URL-- sounds just like Luke Shepard's 
> checkid_immediate "middle state" proposal? 
> http://www.sociallipstick.com/2009/04/15/lets-detect-logged-in-state/
> 
> Why not 
> 1) add Luke's middle state, some response that would indicate
>    that the end user is known to the OP and the OP would be able
>    to assert an identity for the user 
> 2) give the OP the option of returning something like setup_needed 
>    even if the user is authenticated with the OP (this allows OPs to 
>    offer formal privacy options to users)
> 3) specify that the RP must add one or more specific X-OpenID-Something
>    response headers when redirecting the user agent for checkid_immediate
>    (so smart user agents recognize the potential privacy invasion)
> 4) specify that RPs must treat unsigned responses to checkid_immediate
>    as equivalent to setup_needed (so smart user agents can both protect 
>    the user's privacy even for OPs that don't offer privacy options *and*
>    so smart user agents can prevent RP-to-OP info leakage) Note: RPs 
>    must verify signatures for id_res positive assertions, of course!
> 
> Privacy advocates could then hack XPI/BHO/Chrome extensions if they couldn't
> convince their otherwise-preferred OPs to protect their privacy. 
> 
> And the community would get a good framework for better UX.
> 
> I'd also like to see some formal manner for user agents to make unsigned
> setup_needed and middle state claims on their own, much like step 4. Such a
> mechanism would allow for smart client-side selectors to interoperate with
> RPs. My browser could know that I have Google and Yahoo accounts and that
> I would like it to send middle state claims to RPs even if I haven't yet 
> logged in to Google or Yahoo -- I'd get better UX at the RP because my own
> user agent would tell it something that Google and Yahoo could not.
> 
> -Peter
>