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 <[email protected]> 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 <[email protected]> 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<[email protected]> 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, [email protected] >>>>>>> <mailto:[email protected]> 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: [email protected]<mailto:[email protected]> / >>>>>>> [email protected]<mailto:[email protected]> GPG: 0xDE2F024C >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ ietf-privacy >>>>>>> mailing list [email protected] >>>>>>> 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: [email protected] 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 [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/ietf-privacy >>>>> >>>>> _______________________________________________ ietf-privacy >>>>> mailing list [email protected] >>>>> https://www.ietf.org/mailman/listinfo/ietf-privacy >>>> >>> _______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
