Minutes From Meeting Today

Recordon, David drecordon at verisign.com
Mon Jun 26 20:39:08 UTC 2006

Could it be argued that if you hash the Yadis file returned at both
non-SSL and SSL and it is the same then they should be treated the same?
Is there a downside to that I'm not seeing?


-----Original Message-----
From: yadis-bounces at lists.danga.com
[mailto:yadis-bounces at lists.danga.com] On Behalf Of Martin Atkins
Sent: Monday, June 26, 2006 9:26 PM
To: yadis at lists.danga.com
Subject: Re: Minutes From Meeting Today

Andrew Wallace wrote:
>>I think a better goal would be to figure out a way that users can 
>>securely migrate from one identity to another, since this comes up in 
>>more cases than just SSL vs. cleartext HTTP. For example, if I'm using

>>a username.identityprovider.com URL and I want to migrate to 
>>myowndomain.com, I currently have no way to prove that the two 
>>identities are both me.
> While I appreciate the need for general solution, I think there is an 
> argument for special casing the http/https case.  The visual 
> difference is negligible, and (I suspect) for most users it's
semantically meaningless.
> The user expectation, valid or not, is likely to be that the two forms

> refer to the same entity.

How many sites genuinely offer identical content on both their plain and
SSL websites? My experience says not many. In general, the SSL bit just
contains the stuff that needs to be over SSL, and the plain bit
specifically *doesn't* contain that stuff.

Considering the two to be identical is ridiculous, both because no spec
makes no guarantee that the two will be identical and because in
practice they are almost always different.

Therefore we're going to need a way for a particular server to indicate
"Hey, although usually the SSL and the cleartext bits aren't the same,
in this case they are!". Perhaps that solution can also be applied to
tying together separate identities, or maybe not. Either way, I'd rather
see it explicitly declared than just assumed.

More information about the yadis mailing list