[OpenID] Where's the added value?

[Gerald Beuchelt]

Johnny Bufu wrote:
>
> On 29-Aug-07, at 12:53 PM, Gerald Beuchelt wrote:
>>> Why is that? SAML tokens are not required by the Infocard specs.
>> Hmm, let's just take a quick step back: what is today and - very 
>> likely - also going forward the most commonly deployed 
>> Infocard-enabled RP? That would be IIS with the .NET Framework. And 
>> this platform has built-in support for SAML 1.x tokens.
>>
>> Also, ANY relying party that would like to support self-signed cards 
>> MUST also support SAML 1.1. So, while theoretically true, this 
>> statement is at least somewhat unrealistic.
>
> The token issuer and token type are two different things.
>
> With the above, you're implying that no "self" IdP embedded with a 
> selector will ever issue token types other than SAML 1.x. Is something 
> like this actually backed by the Infocard specs (especially the "ever" 
> part)? (This is an honest question - I haven't looked in such detail 
> at the self-issued card requirements.)
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?

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.
> You can call it unrealistic, but I'm sure the OpenID as a whole seemed 
> unrealistic from the SAML point of view two years ago.
I would not call OpenID itself unrealistic - or ever have. In fact, I 
was helping to get the NAC for OpenID and our own experimental OpenID 
program out of the door. However, I also think that when architecting 
interoperability, it is extremely crucial to carefully consider even the 
smallest semantical differences.

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.

Best,

Gerald