<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Regarding U-Prove and failed efforts at consumer PKI:<br>
    <br>
    For high assurance consumer applications that (should) require
    strong authentication, such as online banking, payments, access to
    patient health records and other sensitive personal information,
    what are the possibilities for doing strong authentication?<br>
    <br>
    Since PKI doesn't seem to be a realistic possibility at the consumer
    level (at least not now), it seems that the current choice is
    limited to one-time passwords, at least for consistency with IAF and
    NIST 800-63 v1.0.2.<br>
    <br>
    U-Prove tokens are a potentially viable method for transmitting high
    assurance claims to a RP for these consumer apps.&nbsp; But even so, the
    consumer will still need to strongly authenticate to either an
    identity provider (who issues the tokens), or to a cloud-based
    active client / token agent&nbsp; / claims agent.&nbsp; Or both (??).&nbsp; With
    the demise of Cardspace, the use of a self-issued infocard for
    performing this authentication seems to be out.&nbsp; <br>
    <br>
    Joni has asked for volunteers for a strategy subcommittee to help
    Kantara become more effective, attract more members, etc.&nbsp; I'm
    wondering whether one possible strategic goal for Kantara could be
    to help transform PKI into something that is practical for use by
    consumers.<br>
    <br>
    For example, could Kantara have a role to play in making it
    practical to provision client-side certificates to consumers, so
    that websites can enable the use of two-way SSL for consumers who
    have client-side certificates?&nbsp; <br>
    <br>
    A second possible strategic direction is to help in getting U-Prove
    to be implemented in a way that is usable by consumers.&nbsp; There is a
    related effort in the form of a claims agent working group in
    Identity Commons, but that is not specific to U-Prove. &nbsp; <br>
    <br>
    Maybe these thoughts are best discussed in the strategy subcommittee
    instead, but I just wanted to put this out there and get some sense
    as to whether anyone thinks these might be reasonable goals to
    pursue.&nbsp; Or not?&nbsp; Would such goals stray too far from Kantara's
    mission?<br>
    <br>
    Thanks&nbsp; <br>
    <br>
    Bob P.<br>
    <br>
    <br>
    On 3/14/2011 10:50 AM, John Bradley wrote:
    <blockquote
      cite="mid:23C84B8D-E904-4886-8074-413BFF895AAF@ve7jtb.com"
      type="cite">I helped start Xcert software (now RSA KeyOn) 12 years
      ago to work on federated identity issues using PKI client Auth.
      &nbsp;Why PKI failed in the consumer/internet space is a big topic.</blockquote>
    <blockquote
      cite="mid:23C84B8D-E904-4886-8074-413BFF895AAF@ve7jtb.com"
      type="cite">I should also mention that u-prove (zero knowledge
      prrof) cryptography contains elements of both certificates and
      assertions. &nbsp; I have limited expectations for any short term
      traction on that however.&nbsp;</blockquote>
    <blockquote
      cite="mid:23C84B8D-E904-4886-8074-413BFF895AAF@ve7jtb.com"
      type="cite">
      <div><br>
      </div>
      <div><br>
      </div>
      <div>
        <div>
          <div>On 2011-03-14, at 8:08 AM, Rainer H&ouml;rbe wrote:</div>
          <br class="Apple-interchange-newline">
          <blockquote type="cite">
            <div style="word-wrap: break-word;">John, Patrick and I had
              a discussion about the pros and cons of federation models
              based on credentials versus assertions. The attached
              document is a preliminary result with conclusions like
              <div>
                <div>
                  <ul class="MailOutline">
                    <li>PKI and non-PKI federation models need to be
                      combined in most cases at higher LoA</li>
                    <li><span lang="EN-US">To implement a federation an
                        RFC 3647-style policy is insufficient; A more
                        complete Trust Framework is needed</span></li>
                    <li><span lang="EN-US"><font
                          class="Apple-style-span" size="3"><span
                            class="Apple-style-span" style="font-size:
                            12px;">Whereas the Higher Education sector
                            favors brokered trust, e-Government and
                            Industry prefer the PKI approach. But it is
                            not a question of&nbsp;</span></font></span><font
                        face="Arial"><span id="IDAAZACI"
                          direction="target"><font
                            class="Apple-style-span" size="3"><span
                              class="Apple-style-span" style="font-size:
                              12px;">one way or the other.</span></font><span
                            class="nbsp1" style="height: 12px; width:
                            4px; padding-left: 4px;"><font
                              class="Apple-style-span" size="3"><span
                                class="Apple-style-span"
                                style="font-size: 12px;">&nbsp;</span></font></span></span></font></li>
                  </ul>
                </div>
                <div><br>
                </div>
                <div>Request for feedback:</div>
                <div>I wonder where this discussion should be homed.
                  FIWG, BCTF and TFMM are related, and it is also an
                  extrakantarian issue. Any interest to take over this
                  discussion? &nbsp;</div>
                <div><br>
                </div>
                <div>- Rainer</div>
              </div>
            </div>
            <span>&lt;pki vs non-pki.pdf&gt;</span></blockquote>
        </div>
      </div>
    </blockquote>
    <pre class="moz-signature" cols="72">  
</pre>
  </body>
</html>