[OpenID] Where's the added value?

[Gerald Beuchelt]

Johnny -

I am trying to answer your questions and explain my points below, but in 
order to save us all from more argument exchanges, I withdraw not from 
the discussion on the list. If you (or anybody else) are interested in 
continuing, please let me know by personal email.
Best,

Gerald


Johnny Bufu wrote:
>> Well, I certainly cannot speak for Microsoft, but the current 
>> Infocard spec only talks about SAML 1.1 self-signed cards. Would it 
>> be *possible* to include any other token format? Absolutely. But why 
>> would one do this, if there is no significant benefit from either the 
>> users, RPs, or IdPs perspective?
>
> While we certainly haven't settled which is better out of the OpenID 
> and SAML tokens, you are implying above that SAML is the *best* and 
> hence no other possible token type will ever make sense. I hope you 
> don't mind if I disagree here.
>
I certainly do not mind you disagreeing. However, I still maintain that 
for a number of reasons SAML 1.1 token are better than OpenID tokens, 
since they - at the very least - offer a wider range of features.

That is why I am not too excited about the OpenID tokens: they do not 
solve any new problem or provide simpler solutions for a given scenario. 
They might be an interesting exercise, but offer nothing new for the 
Infocard system above SAML 1.x. Instead they actually limit the scope of 
addressable problems, by e.g. requiring to run in a auditing-mode like 
fashion. At the same time, they also offer no significant new feature 
for the OpenID system beyond what PAPE does.

And finally - unless there is a switch or UI element in the Windows 
CardSpace client I have not seen yet - they do "trick" users into 
believing that their IdP cannot trace their steps, while it can. This 
way they have the potential of also damaging the reputation of the 
InfoCard system and - by uneducated public extension - user centric 
identity and IdM in general.

Since we are trying to appeal to a very broad range of people that do 
not necessarily  have the background we have, we must make sure to only 
send out very clear messages.

>> IF (and only if) there are tangible benefits in supporting another 
>> token (such as e.g. SAML 2.0 - I am just teasing ;-)) it would make 
>> economic sense. Microsoft might also have other motivations to 
>> support other self-signed token formats - again, I cannot speak for 
>> them.
>
> If there aren't actual restrictions, then I imagine I could write my 
> own identity selector that would issue a different type of tokens for 
> self-issued cards, without violating the spec.
Assuming that there are no IPR or other issues, that is my understanding 
as far as the current spec goes. How useful such a selector in the wild 
would be, remains everybody's guess.

>> Also, it seems important to me to not create solutions for their own 
>> sake, but instead have customers or the market drive most 
>> interoperability solutions. Another important design principle should 
>> be simplicity - and that covers deployment, as well as architecture.
>
> That's also what we're doing with the OpenID Information Cards spec: 
> we're making them aware about an alternate possibility to be 
> considered, of which they may or may not have thought about, but which 
> we at least proved it can work (and outlined some benefits).
Oh, and I think that I gave you guys credit for doing this (at least I 
very much hope that I did). I do not intend to diminish the work you put 
into this effort - I only question whether the outcome is beneficial for 
the majority of the involved parties, especially since I do not see any 
significant advantage for either the Infocard identity system, nor for 
OpenID.

> How could the market compare and choose what works better in each 
> case, if there were no diversity and alternatives? 
Diversity is great, only I too have to report back and justify our work 
to our shareholders. I guess what I am trying to communicate is that I 
could not justify working on an OpenID Infocard token.

> Are you actually questioning why the Infocard specs allow for more 
> than one token type?
>
I answered that before, and I do not think that this is the subject of 
this discussion in the first place.