[OpenID] Using HTTPS Openid Providers

[Martin Atkins]

Peter Williams wrote:
> 
> The design rationale in the conversation implied that one MUST show a
> _visible_ message to alert a person, when a given OP provider has not
> been authorized to present claims to a given OP Consumer. To present a
> visible message would assume we are in a browser/HTML context. That
> (pure HTML) context assumption got me thinking about where I can and
> cannot apply OpenID in my own little world; how a design would have to
> workaround limits of today's (mainstream) OpenID capabilities.
> 
> If I attempt a recap, we had said that all OP servers creating claims
> MUST be assumed usable at all OP claims Consumers. Then we said, if
> that's not true in a given OP Consumer's security policy case... then
> the protocol MUST convey the Consumer's [HTML] message explaining why.
> This all implied a full [HTML] browser communication context - with
> language/character encoding/etc support. 
> 

"The protocol" (OpenID Auth) isn't really involved in this situation, 
because it is the RP generating the error. One would assume that in the 
example from my original message the RP wouldn't even initiate OpenID 
authentication, it'd just produce the error message for the user 
immediately.

In a web context, this error message would likely be presented as part 
of an HTML page. However, the RP could return the error message by any 
other means appropriate to the situation.

To be clear, I was not suggesting that anything like this be part of the 
protocol. I was merely saying that in a situation where an RP is 
discriminating for some reason against a particular class of OP they are 
likely to return a specific error message to the end-user rather than 
the generic "discovery failed" error message you'd be likely to get if 
the discovery failed at a lower layer -- for example, if the underlying 
HTTP client library doesn't support SSL.