[Openid-specs-ab] privacy & acr

Brian Campbell bcampbell at pingidentity.com
Sun Nov 3 17:44:18 UTC 2013


I'll freely admit that this is an area that I very little familiarity with
but the described scenario and the likelihood that deployments would use
the acr pieces of the spec for the avoidance of privacy compliance cost
seems really tenuous.


On Tue, Oct 29, 2013 at 8:32 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> This really only is needed if the IdP doesn't understand the trust
> framework and you want to stop them from returning a response.
>
> It is up to the RP to ask for the identifier type (pseudonymous or
> omnidirectional) and attributes so even if you ask for loa 1 as long as you
> don't ask for attributes you are OK if you get back a acr value of LoA 2 as
> that won't change the subject.
>
> I think there are other methods in connect that allow you to just get a
> pseudonymous subject that we don't necessarily need to force an error for
> privacy.
>
> We also allow discovery of the acr_values_supported so if someone wanted
> to have a exact matching acr value they would know if the IdP supported it
> before sending the request.
>
> Tony can you think of a use case where the server returning an error is
> required if a authentication context class can't be achieved for a user?
>
> John B.
>
> On Oct 30, 2013, at 12:08 AM, n-sakimura <n-sakimura at nri.co.jp> wrote:
>
>  I have got a feeling that it should be left for the trust frameworks to
> figure it out.
>
> 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.
>
> Nat
>
> (2013/10/30 10:03), John Bradley wrote:
>
> 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 <sakimura at gmail.com> <sakimura at gmail.com> wrote:
>
>
>  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 <bcampbell at pingidentity.com> <bcampbell at pingidentity.com> のメッセージ:
>
>
>  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 listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>  _______________________________________________
> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> _______________________________________________
> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> --
> Nat Sakimura (n-sakimura at nri.co.jp)
> Nomura Research Institute, Ltd. Tel:+81-3-6274-1412 <+81-3-6274-1412> Fax:+81-3-6274-1547
>
>
> 本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ござӓ
>  6;|
> 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.
>
>  _______________________________________________
>
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131103/ffa52c72/attachment.html>


More information about the Openid-specs-ab mailing list