[OpenID] Where's the added value?

[Johnny Bufu]

On 29-Aug-07, at 1:33 PM, Gerald Beuchelt wrote:
> 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?

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.

> 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.

> 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).

How could the market compare and choose what works better in each  
case, if there were no diversity and alternatives? Are you actually  
questioning why the Infocard specs allow for more than one token type?


Johnny