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
