<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">I have got a feeling that it should be
      left for the trust frameworks to figure it out. <br>
      <br>
      In addition, I am not sure if refusing all personal data to avoid
      PIA is really realistic. With the use of auxilary data together
      with usage history collected over a pseudonym, the psuedonymized
      data is pretty much re-identifiable according to recent studies.
      This means that "it's FICAM LOA1 so we do not have to consider
      PIA" logic actually is quite questionable. So, I would rather not
      put too much emphasis on it. <br>
      <br>
      Nat<br>
      <br>
      (2013/10/30 10:03), John Bradley wrote:<br>
    </div>
    <blockquote
      cite="mid:292EAE48-5461-43D2-B534-D5548F87B599@ve7jtb.com"
      type="cite">
      <pre wrap="">Yes that is perhaps a better way to put it.

I would like to find a way to simplify it but we are getting a bit late in the process. 

The option would be to scrap the claims way to ask for required and let people define new acr values that require an exact mach  eg loa1-exact-match or something like that.
Adding another query parameter is too ugly.

In general the match parameter for authn context is supposed to control if you are allowed to return better than or exact etc however that never really got used properly as everyone sends exact as the match and then get returned whatever the IdP feels like, on the assumption that if it could not match the request exactly the RP will figure it out from the response.

John B.


On Oct 29, 2013, at 9:09 PM, Nat Sakimura <a class="moz-txt-link-rfc2396E" href="mailto:sakimura@gmail.com"><sakimura@gmail.com></a> wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="">RP asking for only LoA 1 and not higher with PPID may not want a LoA2 non-PPID identity as that would require them to go under full PIA. In such a case, the RP may want the request to fail if this acr cannot be fulfilled. 

So, it is not so much for privacy protection but the avoidance of privacy compliance cost. 

Cheers, 

=nat via iPhone

Oct 30, 2013 4:42、Brian Campbell <a class="moz-txt-link-rfc2396E" href="mailto:bcampbell@pingidentity.com"><bcampbell@pingidentity.com></a> のメッセージ:

</pre>
        <blockquote type="cite">
          <pre wrap="">Yesterday on the call John said that there are privacy reasons to want to be able to request "acr" as an essential claim and return an error if it fails.

Can you explain that again John? Who's privacy (I assume the end user's) about what (how/when they authenticated) is being kept from who? 

_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
        </blockquote>
        <pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
      </blockquote>
      <pre wrap="">
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Nat Sakimura (<a class="moz-txt-link-abbreviated" href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a>)
Nomura Research Institute, Ltd. 
<a class="moz-txt-link-freetext" href="Tel:+81-3-6274-1412">Tel:+81-3-6274-1412</a> Fax:+81-3-6274-1547

本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ござ&#1235
 6;&#124
14;せんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。
PLEASE READ:
The information contained in this e-mail is confidential and intended for the named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.
</pre>
  </body>
</html>