OpenID 2.0 proposed security profiles

[Martin Atkins]

I'm starting to come around to this profile-negotiation idea, but I 
still have a few comments...

Granqvist, Hans wrote:
>  
> The names "A" and "B" should of course be discussed. I don't
> want to name then "low security" and "medium security" as
> such distinctions carry implications and liabilities. (There
> is also a risk of security creep that forces definitions to 
> change over time -- what is now 'medium security' could be 
> 'low security' in a few years, and possibly 'useless security' 
> in yet another few years. But the definition will be stuck as
> 'medium security' forever.)

I think A and B are just as bad as "low" and "medium". Let's instead 
name them after what they actually do, so I don't have to remember that 
"A is the one that doesn't require ... " (I've forgotten already, so I 
can't finish that sentence)

Obviously it'll be tricky to come up with a terse way to name them, but 
even if it just calls out one major difference between the two it'd be 
better than completely arbitrary labels, especially since we're likely 
to start adding profiles C, D and E in the future when situations change.

 > Profile A
 > http://openid.net/auth/2.0/A
 >

 > Profile B
 > http://openid.net/auth/2.0/B
 >

I realise that this is nit-picking, but I would like it if the "auth" 
here was changed to "authen", just so it's clear that we're talking 
about authentication rather than authorization. In the URIs for earlier 
versions I suggested "signon" to avoid calling it "auth", but "authen"'s 
probably a clearer term.

> I don't think (although I am not sure) compliance to a specific 
> profile should be mandatory in the OpenID auth spec itself.
>  

I'm going to show how rusty I've got with Yadis now.
Is it acceptable (as far as XRI is concerned) to specify multiple types?

     <Service>
         <Type>http://openid.net/authen/2.0/A</Type>
         <Type>http://openid.net/authen/2.0/B</Type>
         <URI>http://www.livejournal.com/openid/server.bml</URI>
     </Service>

If this is acceptable, then I think it's okay to say that "everything is 
a profile". The above declares that I support both profiles. Since I've 
not carefully studied the contents of each profile I'm not sure if 
that's even possible, but if we assume that there's going to be a 
profile that essentially says "I support everything", with these two 
being a subset of it, then we can easily require that all 
implementations comply with at least one profile!

Presumably for a time services will be declaring support for OpenID 1.0 
and/or 1.1 in addition to at least one 2.0 profile, too. Is it fair to 
consider OpenID 1.1 to be a profile of OpenID 2.0? That is, we write in 
the 2.0 spec how to simultaneously be compatible with 1.1 and call that 
a profile in addition to the above.