Re: [ietf-privacy] 答复: Re: 答复: RE: anonymity definition in"draft-hansen-privacy-terminology-03"

[David Chadwick <[e-mail]>]

On 25/02/2012 13:07, Stephen Farrell wrote:

> ...cut... nor had they thought about any
> privacy-friendly ways to handle identifiers in
> log files that might be exchanged between domains.
>

As part of the recently completed EC TAS3 project we considered this and 
implemented a (partial) proof of concept. This uses the Liberty Alliance 
scheme of passing encrypted PIDs between SPs. But the process is very 
unwieldy and gets very complex once a log record refers to the PIDs of 
several different entities, each of which has a different PID at each 
SP. So it is not a system that I would especially recommend

regards

David

> It'd have been great to be able to say "go look
> at RFC xxxx where it shows you ten possible ways
> to do that."
>
> S
>
> [1] http://datatracker.ietf.org/doc/draft-ietf-sipclf-problem-statement/
>
>
> On 02/24/2012 10:33 PM, David Chadwick wrote:
>> Hi Klaas
>>
>> I agree with you. It might that IRTF is more appropriate for some work
>> items, but this is something the ADs can decide
>>
>> regards
>>
>> David
>>
>> On 24/02/2012 18:56, Klaas Wierenga wrote:
>>> Hi Hannes,
>>>
>>> Perhaps I am mistaken, but it seems that there is a bit too much
>>> focus on what is possible with *todays* technology. I would rather
>>> like to focus on properties we would *like* to see, and possibly work
>>> on those in the IETF (but most likely other fora).... But still that
>>> is probably not for a terminology document, but I do think we need to
>>> be able to express all desirable properties using the terms from the
>>> terminology document.
>>>
>>> Klaas
>>>
>>> Sent from my iPad
>>>
>>> On 24 feb. 2012, at 19:47, Hannes
>>> Tschofenig<[e-mail]> wrote:
>>>
>>>> Hi David,
>>>>
>>>> this specific case seems to have pretty tough privacy requirements:
>>>> you want to avoid having relying parties to know who the identity
>>>> providers are AND also want to avoid letting identity providers
>>>> know which relying parties data subjects talk to AND finally you
>>>> want to avoid collusion among relying parties to learn more about
>>>> data subjects.
>>>>
>>>> It is interesting to see how a set of privacy requirements produce
>>>> a system that has questionable privacy properties...
>>>>
>>>> Ciao Hannes
>>>>
>>>> PS: Whenever one talks about trust it is useful to mention 'who is
>>>> trusted by whom to do what'.
>>>>
>>>> On Feb 22, 2012, at 12:37 AM, David Chadwick wrote:
>>>>
>>>>>
>>>>>
>>>>> On 20/02/2012 17:16, Rhys Smith wrote:
>>>>>> On 15 Feb 2012, at 06:06, [e-mail]
>>>>>> <mailto:[e-mail]> wrote:
>>>>>>
>>>>>>>> Well, even more, the idp should not know at all which rp I
>>>>>>>> talk to in the first place.
>>>>>>>
>>>>>>> It is a strong privacy reqirement. Ｉdoubt solutions in ABFAB
>>>>>>> can provide this feature.
>>>>>>
>>>>>> Yes, ABFAB cannot do this natively.
>>>>>>
>>>>>> Though there are always ways around this. SAML cannot do this
>>>>>> natively either, but the Cabinet Office (UK government) is in
>>>>>> the middle of setting up a national federated infrastructure
>>>>>> with exactly this properly, which it achieves by having a
>>>>>> gateway in the middle which mediates all traffic.
>>>>>
>>>>> Hmmm. the design of this is very questionnable (and opaque). Full
>>>>> trust must be given to the gateway, without any assurance that it
>>>>> is trustworthy. It is not even mentioned in the trust assurance
>>>>> document.
>>>>>
>>>>> regards
>>>>>
>>>>> David
>>>>>
>>>>>>
>>>>>> Note that this privacy requirement may well be asymmetric -
>>>>>> there may be a difference between the IdP not being able to
>>>>>> know about which RP the user is using, and the RP not knowing
>>>>>> which IdP the user came from...
>>>>>>
>>>>>> R. -- Dr Rhys Smith Identity, Access, and Middleware
>>>>>> Specialist Cardiff University& Janet - the UK's education and
>>>>>> research network
>>>>>>
>>>>>> email: [e-mail]<mailto:[e-mail]> /
>>>>>> [e-mail]<mailto:[e-mail]> GPG: 0xDE2F024C
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ ietf-privacy
>>>>>> mailing list [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/ietf-privacy
>>>>>
>>>>> --
>>>>>
>>>>> *****************************************************************
>>>>>
>>>>>
>> David W. Chadwick, BSc PhD
>>>>> Professor of Information Systems Security School of Computing,
>>>>> University of Kent, Canterbury, CT2 7NF Skype Name:
>>>>> davidwchadwick Tel: [phone] Fax [phone] Mobile:
>>>>> [phone] Email: [e-mail] Home Page:
>>>>> http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research
>>>>> Web site:
>>>>> http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust
>>>>> key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5
>>>>>
>>>>> *****************************************************************
>>>>>
>>>>>
>> _______________________________________________
>>>>> ietf-privacy mailing list [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ietf-privacy
>>>>
>>>> _______________________________________________ ietf-privacy
>>>> mailing list [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ietf-privacy
>>>
>>
>

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
School of Computing, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: [phone]
Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************