[OpenID] Using HTTPS Openid Providers

[Peter Williams]

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. That is: ajax
calls and flash iframes collecting xsl/xml resources are not allowed, if
one goes down this track.

I know, I know; social networking, wikis, blogs, and web2.0 are the
roots of OpenID, where all the world is a browser. But, the movement is
obviously professionalizing in OpenID2.0 beyond those (professional)
application areas. Surely I can used the OPenID Protocol to get access
granted to an RP that only delivers XML?

At the end of the day, OpenID has to sell itself on its actual security
properties. If we want Wikipedia to allow its editors into their
privileged write mode rights set using OpenID, the security model has to
be reasonably assured. WikiPedia cannot afford the public-confidence
drop associated with too many breaches, where the article on China gets
hacked to say something evil; and then vice versa on the Taiwan entry;
for ever.

If we answer that Wikipedia administrative editing is not in the scope
of an _intended_ application deployment, then I'm on the wrong list.
Realty has own premier blogging destination (realtown.com); and I need
them to believe OpenID is mainstream enough so they add it to their SAML
and WS-Fed methods.

IF we say that DoD must use the same crypto in its OP as foobar RP -
when DoD contractors then use a formal Dod wiki to design bombs, again
we are lost. Lots of crypto regulations control that OP organization. DH
(the exponentiation-based strength variety) is not even in vogue any
more (after 20 years of being used to try and fend off RSA crypto!)

This is going to be a very hard transition for some in the grassroots
movement. But look on its positively: SSL went through the same, and
came out with self-signed certs being perfectly accepted everywhere, if
you don't happen to like DoD, VeriSign, GeoTrust, etc or payin' $1600
for a cert. This is a model for successful security adoption in a
sophisticated culture; high end stuff than can be used in a low-end
modality initially, with no FUD. When it's time to move up the risk
scale, service providers offering value-add come into their own.
 
-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Martin Atkins
Sent: Friday, June 15, 2007 12:23 PM
To: general at openid.net
Subject: Re: [OpenID] Using HTTPS Openid Providers

Josh Hoyt wrote:
> On 6/15/07, Martin Atkins <mart at degeneration.co.uk> wrote:
>> All RPs must be able to authenticate against all conformant OPs for
>> reasons of user experience.
> 
> I disagree with this reasoning. Ideally, every priovider would work
> with every relying party, but there will be plenty of cases where a
> provider doesn't work with a relying party for reasons of policy.
> There will be times when a relying party rejects authentication
> because, for instance, it doesn't trust the provider. To a user, this
> is equivalent (my identifier doesn't work here).

At least in this case the RP can say,

"Sorry. We don't accept logins from insecureidp.com because they are 
known to have security problems."

A concious policy decision (with a suitable explanation) is one thing, 
but it just not working (for example, discovery just failing with a 
generic error message) makes it look like OpenID is broken rather than 
the blame falling on either the RP that instituted the policy or the OP 
for having whatever limitation caused them to be verboten.

> There will always be trade-offs. It's important to consider
> consistency of user experience, but I think that requiring relying
> parties to support SSL providers and identifiers will just result in
> the same relying parties being out-of-spec.
> 
> I think that in this case, SHOULD is adequate. From RFC2119:
> 
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.
> 
> "My hosting environment doesn't have SSL support in my language
> runtime" is a valid reason not to support SSL, in my opinion.
> 

Perhaps as a compromise the full situation could be clarified by 
including an extra sentence that explains why it sucks for an RP *not* 
to support SSL. If they still want to go ahead and leave it out then 
it's their call, but at least they can't say they weren't warned.



_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general