[OpenID] Using HTTPS Openid Providers

[Peter Williams]

I see the communication error on my part, now. Having reread what
follows, I think it is actually useful to see what flows from the error.

-----------

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. 

This reader at least has now understood that the protocol designers have
an explicit assumption in this area: mainstream OpenID assumes the http
client is a full [HTML-capable] browser.

In (US) realty, the major realty standard is called RETS. Its common use
cases allow for programmatic http clients - clients that do not have an
HTML component at the RETS layer - despite using an http bearer, using
get/post requests, and communicating resultsets (and exceptions) in an
xml vocabulary within HTTP Responses. Often, folks implement such "http
data sources" using webapplication frameworks, hosted on http web
servers.

I'm guessing now that mainstream OpenID is not going to be highly
relevant to authenticating the user to those kinds of http "data"
servers. Even in implementations that layer a webview on top of those
RETS http data sources, where end-users expect browser-centric GUIs
rendering house listings in Spanish, English, Thai, Korean, etc , the
OpenID flow would really be to the second tier webview-generating
application, not the third tier http data source operating behind the
scenes.

I guess this leaves me with second OpenID/SAML use case -- and
associated OpenID<->SAML handoff. OpenID can get the browsing-user
granted access to use the webviewer webapp, and that viewer will in turn
have to leverage a SAML IDP to (programatically) present the users
credentials to the http data source, armed with SAML SP handlers. I
think this joint "handoff" design is ok. OpenID is essentially creating
a login session on the SAML IDP of the webapp, and then a handler in the
webapp causes a backroom SAML flow to relay the claim that an
OpenID-protected session exists to a SAML SP handler in the http data
source. This feels a little like the design pattern of a Liberty-enabled
client design or SAML ECP binding, but it's now using OpenID - which is
nice.

-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Martin Atkins
Sent: Saturday, June 16, 2007 3:18 AM
To: general at openid.net
Subject: Re: [OpenID] Using HTTPS Openid Providers

Peter Williams wrote:
> I don't like the use case reasoning as it appears to constrain the
> technical standard and the normative compliance agreements : it
assumes
> OpenID will only ever be used in display-centric RPs. 

I'm not really seeing how this relates to the message you replied to