<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Just to be even more pedantic on the terminology: No Infocard "carries"
any tokens. Instead, they reference endpoints where tokens can be
obtained. <br>
<br>
Johnny Bufu wrote:
<blockquote cite="mid:14548AB2-7242-4CE4-AEF1-C9981F7AF48E@sxip.com"
 type="cite">
  <pre wrap="">On 29-Aug-07, at 11:53 AM, Eric Norman wrote:
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">The OpenID Information Cards specification targets existing OpenID
RPs (which require minimal changes), and offers them a new means of
requesting / transporting the OpenID claims / assertions, which has
a few advantages over the regular OpenID flow.
      </pre>
    </blockquote>
    <pre wrap="">Well, that's the question.  What are those advantages to the
relying party, or to the user, or to any other stakeholder.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
For the RP: if it requires logins with an OpenID Infocard, it will  
know that the user - OP/STS authentication is phishing resistant.
  </pre>
</blockquote>
It should be noted that this is only real news for the OpenID token -
and can also be averted by other means. <br>
<blockquote cite="mid:14548AB2-7242-4CE4-AEF1-C9981F7AF48E@sxip.com"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">The RP already has to install, configure, and maintain code
that can deal with Information Cards carrying SAML tokens
(to use your terminology).
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Why is that? SAML tokens are not required by the Infocard specs.
  </pre>
</blockquote>
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. <br>
<br>
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. <br>
<br>
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. <br>
<br>
And as far as trust goes, the WCS self-signed tokens are on exactly the
same footing as any OpenID token. <br>
<br>
Sorry to be a little obnoxious about this topic, but I personally think
that the way the OpenID tokens are proposed, they will neither benefit
OpenID, nor the Infocard identity system. I could stay quiet, rejoice
and hope that Liberty take their place, but (i) that would be cynical
(especially after issuing a NAC) , but more importantly (ii) I think
that the potential backlash would hurt the efforts of all identity
system developers. <br>
<br>
Best, <br>
<br>
Gerald<br>
<br>
</body>
</html>