[OpenID] Where's the added value?

[Johnny Bufu]

On 29-Aug-07, at 12:53 PM, Gerald Beuchelt wrote:
>>> The RP already has to install, configure, and maintain code
>>> that can deal with Information Cards carrying SAML tokens
>>> (to use your terminology).
>>>
>>
>> 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.)

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.

> Therefore I think that Eric raises a very good point: if the RP  
> supports SAML tokens anyway (which is quite likely), why should it  
> burden itself to also accept OpenID tokens. At the end of the day,  
> ALL Windows CardSpace clients can at least provide SAML 1.1 tokens.

If the RPs already have reasons to prefer SAML tokens, our spec will  
likely not change their minds. Again, what we're proposing targets  
OpenID RPs, about which you can't say "they already have SAML code"  
-- they don't.


Johnny