[Concordia] OpenID Information Cards

[Gerald Beuchelt]

John, Eric -

Comments inline.

Best,

Gerald

John Kemp wrote:
> I think the basic problem though is they want the protocol talked to the
> RP to be OpenID. Thus, they have defined a simple "token" that just
> contains a name/value pair set used in the OpenID protocol response,
> which means:
>   

Yes, I agree.
> i) You've coupled an (already) OpenID provider to an (already) OpenID RP
> - as Gerald notes in his blog post, this basically duplicates an HTTP
> redirect approach. So this is a very tightly-coupled solution.
>   
And this is where Infocard as an authentication system excels: it has a 
replacement for the notoriously insecure HTTP redirect.

> I totally understand why it's specified in this simple way - it's the
> simplest approach that can work. In the early development of Liberty
> ID-FF (the Liberty Enhanced Client or Proxy profile specifically, which
> became SAML 2.0 ECP) we discovered that security with an active
> intermediary in between the IdP and RP is not a simple matter. If you'd
> like to decouple the protocols used by the identity selector when
> talking to the RP vs. when it is talking to the IdP, it gets even harder.
>   
Yup. That is why - IMO - it is ultimately important to not mix up 
semantics and maintain a clean boundary.

> ext Eric Norman wrote:
>   
>> the topic being discussed.  Even if OpenID tokens were wrapped in SAML
>> 2, what value would that add that you don't have by supporting SAML 2?
>>     
Good point: Similar to what the basic SAML 1.1 token in Windows 
CardSpace are doing, a SAML 2 (or even SAML 1) wrapped openid token 
could eliminate the RP -> OP verification, by relying on PKI and 
<KeyInfo> in the SAML token. I know that this strips pretty much the 
(little) remaining OpenID-ness out of this approach, but it would have 
some great advantages over the "minimalistic" solution proposed by SXIP:

(i) RPs could easily extract OpenID identifier values from the the SAML2 
token, thus preserving the OpenID Provider database.
(ii) This model would allow a non-auditing mode, probably the single 
most important feature of the Infocard authentication system.

Johnny's argument that their approach is better for the existing OpenID 
RP has no real merit:

Firstly, there are not too many OpenID RPs out there - hate to be the 
messenger of the bad news, but if you are honest with yourself, you will 
agree with me.

Secondly, even in the SXIP proposal, you will need to make changes to 
the RP. Whether the trivial OpenID Infocard conversion would be easier 
than than a full SAML(1,2) conversion is largely a factor of the 
packaging and deployment.

Thirdly, the difference at the OpenID IdP would be also quite small.
>> The value subtracted is that everyone now would have to deploy code
>> to handle OpenID tokens as well as SAML 2; what would be the value
>> added that makes this worthwhile?
>>     
The value-add seems obvious - at least to me: SAML2 is an established 
technology, and the token format offers many more features than the 
trivial proposal. While a SAML wrapped OpenID token can continue to 
utilize the existing OpenID IdP databases, the migration to a more 
powerful token format will allow easier extensibility going forward.

At the end of the day, we are currently facing a situation, where we 
have a very large number of OpenID IdP (with - at times - large user 
databases), but only very few RPs. Thus, it would seem prudent to 
capitalize on this situation and use it to improve the overall feature 
set and interoperability of the system.