[OpenID] Reconsidering http://openid different from https://openid

[Jack]

George Fletcher wrote:
> 
> Joseph Holsten wrote:
>> This, and not adding complexity to to OpenID spec cause me to
>> support the IDs as seperate.
>> 
>> As an implementor, I would not think OpenID would normalize, or 
>> otherwise merge, two unique identifiers beyond the standard 
>> normalization for URI/XRI. The benefits of using a URI/XRI as an
>> identifier disappear when we add extra normalization to these
>> identifiers. Let's either use those identifiers or bite the bullet
>> and start calling me openid://josephholsten.com
>> 
> So I think I'm convinced now of this as well. I don't think the spec
> can do anything to "solve" this issue.  However, I realized that in
> the use case Johannes proposed, the issue isn't about RP or OP and
> identifiers, its about how the user communicates their identifier to
> another person or party.

I think it's also about how the user *enters* their id. See below.
> 
> If my OP always redirects my http://george.op.example to 
> https://george.op.example then my claimed identifier at all RPs is 
> really https://george.op.example.  However, I don't know this so when
>  someone asks for my OpenID I give them http://george.op.example
> because that's what I enter at all the RPs.

But you're supposed to be able to enter "george.op.example", and indeed
that's what I'd expect the majority of users to do; and it's one of the
OpenID "features" that you can use a shortcut like that.

Note earlier comments to the effect that many users rely on their
browser to resolve "www.yahoo.com", and don't expect to have to type a
scheme at all, ever.

> If this URL is added to the ACL with out first being normalized per
> section 7.2 (OpenID 2.0 draft 12) then when I try and access the
> site, I will be rejected because the site will have a claimed_id of
> https://george.op.example and the ACL will have
> http://george.op.example.
> 
> This is just too confusing for users. Especially when the OP can
> change the claimed_id from what the user entered (albeit the only
> change being from http to https).
> 
> It seems that a RP maintaining an ACL must normalized any user 
> communicated identifier before adding it to the ACL. That, matched
> with OP's following a best practice of redirecting http to https
> should solve most of the issues.  If the user choses to use
> delegation then they are on their own to understand the intricacies
> of the spec:)

Delegation is another OpenID "feature" - "use your own website's
homepage URL as your OpenID". I don't think it's at all a good idea to
relegate this feature to the category "only for geeks". Many people
maintain websites who are averse to studying specs. Specs are for
developers; users should not have to understand intricacies designed for
developers, and website maintainers are to an ever-greater extent
non-technical people. And the OpenID 2.0 spec is *much* more difficult
than it looks...

 From the POV of an ordinary user, the https and http variants of their
OpenId are just that - two variants of the same (scheme-less) Id. If
they are technically distinct Ids, then that fact needs to be made
invisible to ordinary users.

Whether the user is willing to permit a non-SSL auth is certainly a
matter for the user, not for the RP. So the OP, on receiving a non-SSL
auth request, should alert the user. And it should not be possible for
two OpenIds that differ only in the scheme to be treated as distinct
users. So an RP that maintains ACLs should de-normalise the id before
recording it in their ACL tables, confident in the knowledge that no OP
may treat an https id as distinct from an http id. And an OP should use
a scheme-less form of the id when searching for a password to validate
the user's OP login.

That is, I think the scheme specifies a detail about how auth is to
occur; it is not part of the id, as perceived by an ordinary user, and
so should not be so treated by OPs or RPs.
-- 
Jack.