Minutes From Meeting Today

[David Strauss]

I think it's *very* important that the spec define exactly how OpenID
URLs map to unique OpenID users. Any inconsistency here would be
confusing to end users, whose OpenIDs would function differently on
different sites.

Here's an alternative for SSL negotiation. OpenID Consumer sites must,
if able, attempt to download the identity page using the https:// scheme
on the first signon. If that fails, the Consumer can fall back to using
http://. Once the Consumer has succeeded even once at pulling the
identity page using the https:// scheme, it will always use https:// for
that OpenID. This would take the user's behavior out of the picture and
allow a sort of "negotiation" for the identity page download that isn't
as significantly subject to compromise as the current protocol.

This would, at least, protect subsequent signons to OpenID Consumer
sites, which is more important than protecting initial signons.

- David

Recordon, David wrote:
> That behavior seems very specific to a relying party implementation.  I
> do like how it provides the upgrade path for users, though could be a
> bit confusing.
> 
> I think I'd lean toward the spec saying that the scheme of a URL
> identifier may be ignored and then talk through the issues in the
> security considerations section.  In terms of my understanding of the
> issue, I don't want the spec to prohibit a relying party to treat them
> as the same end user, but also don't want the spec to require it be
> done.
> 
> --David 
> 
> -----Original Message-----
> From: yadis-bounces at lists.danga.com
> [mailto:yadis-bounces at lists.danga.com] On Behalf Of David Strauss
> Sent: Saturday, June 24, 2006 9:10 AM
> To: yadis at lists.danga.com
> Subject: Re: Minutes From Meeting Today
> 
> At the minimum, consumers could allow a one-time escalation to an
> https:// identity from an http:// one. After signing on with the
> https:// equivalent once, the http:// signon for the ID would be
> disallowed.
> 
> It'd be rather easy to implement, and every OpenID server out there
> seems to already treat the http:// and https:// identities as
> equivalent.
> 
> --
> David Strauss
> Four Kitchen Studios, LLC
> GetOpenID.com
> 
> Recordon, David wrote:
>> This was something we discussed both days.  From the discussion on the
> 
>> list, there are tradeoffs on both sides.
>>
>> Treating them the same means that if your http:// identity is 
>> compromised then so is your https:// one.  Ideally you're using 
>> https:// since it is more secure.
>>
>> On the other hand, in terms of easing adoption and growth into the 
>> future, treating them as the same identity is preferred.
>>
>> I'm I missing any strong arguments on either side?
>>
>> --David
>>
>> -----Original Message-----
>> From: yadis-bounces at lists.danga.com
>> [mailto:yadis-bounces at lists.danga.com] On Behalf Of David Strauss
>> Sent: Saturday, June 24, 2006 8:34 AM
>> To: yadis at lists.danga.com
>> Subject: Re: Minutes From Meeting Today
>>
>> Recordon, David wrote:
>>> - Recommends SSL in certain areas
>> My main concern is how the current spec treats 
>> http://getopenid.com/david and https://getopenid.com/david as 
>> different identities. While I understand how there *could* be 
>> exceptions, I think both should be treated the same so users can 
>> gracefully move to using SSL identity pages. I think the lack of 
>> SSL-signed identity pages is a major weakness in OpenID that allows 
>> spoofing to direct authentication to a rogue server.
>>
>> --
>> David Strauss
>> Four Kitchen Studios, LLC
>> GetOpenID.com
>>
> 
>