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

In the meanwhile perhaps worth looking at http://www.eduroam.org/downloads/docs/GN2-08-243-DJ5-4-1-2_Advanced_Technologies_Overview_Second_Edition_20090204080004.pdf section 2.2 on the use of pseudonyms in the Chargeable User Identifier attribute.

Klaas

Sent from my iPad

On 25 feb. 2012, at 18:24, Klaas Wierenga <klaas@wierenga.net> wrote:

> Fwiw, I have agreed with Stefan Winter and Tomasz Wolniewicz to write an informational draft on the design of eduroam, including how logging is handled using pseudonymous identifiers, now if only we manage to find some time to write it up.....
> 
> Klaas
> 
> Sent from my iPad
> 
> On 25 feb. 2012, at 14:07, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 
>> 
>> Well, regardless of venue, seeing a few drafts
>> that showed us good ways to handle privacy in IETF
>> protocols would be useful IMO.
>> 
>> For example, the IESG recently reviewed the SIP
>> common log format. [1] As part of the review I asked
>> if the WG had considered privacy and the answer was
>> essentially no and nor had they thought about any
>> privacy-friendly ways to handle identifiers in
>> log files that might be exchanged between domains.
>> 
>> 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<hannes.tschofenig@gmx.net> 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, zhou.sujing@zte.com.cn
>>>>>>> <mailto:zhou.sujing@zte.com.cn> 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: smith@cardiff.ac.uk<mailto:smith@cardiff.ac.uk> /
>>>>>>> rhys.smith@ja.net<mailto:rhys.smith@ja.net> GPG: 0xDE2F024C
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________ ietf-privacy
>>>>>>> mailing list ietf-privacy@ietf.org
>>>>>>> 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: +44 1227 82 3221 Fax +44 1227 762 811 Mobile:
>>>>>> +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk 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 ietf-privacy@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ietf-privacy
>>>>> 
>>>>> _______________________________________________ ietf-privacy
>>>>> mailing list ietf-privacy@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ietf-privacy
>>>> 
>>> 