Minutes From Meeting Today

[Recordon, David]

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
>