[Openid-specs-ab] privacy & acr

n-sakimura n-sakimura at nri.co.jp
Wed Oct 30 03:08:54 UTC 2013


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> 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> ??????:
>>
>>> 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
>>> 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
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://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 Fax:+81-3-6274-1547

????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131030/7ba14ef9/attachment.html>


More information about the Openid-specs-ab mailing list