[Openid-specs-ab] privacy & acr
ve7jtb at ve7jtb.com
Wed Oct 30 03:32:17 UTC 2013
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?
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.
> (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.
>>> =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
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
> 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.
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4507 bytes
Desc: not available
More information about the Openid-specs-ab