[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> Well, not the names of consortium members, but fact that a particular
> user is in a particular location is, of course, private and sensitive.
> Quoting from the abstract of RFC 5580:
> The distribution of location information is a privacy-sensitive task.
> Dealing with mechanisms to preserve the user's privacy is important
> and is addressed in this document.
Well, GEOPRIV is all about specifying the rather react location of
particular users. Certainly some of that level of concern spills over to
the eduroam use case, but I don't see them as analogous. Still, that's
really none of my concern. I'm only interested in how RADIUS attributes are
re-used in this case.
> Since the visited network does not bill us for our users, we have no
> reason to know where our user is, but more importantly, we would not
> want this information to travel in the open.
OK, that sounds a bit paranoid. If the user wants to maintain true
anonymity, they will need to use EAP methods with an anonymous outer
identity. In that case all that can be detected is the number of users
visiting a particular university on a particular day, not their identity.
I'll admit there is *some* information there, but if you're going to perform
traffic analysis of eduroam traffic, that kind of information is going to
come out anyway.
> We want to have the Operator-Name (or equivalent) for just one reason -
> when we generate the CUI we want to do something like:
Sure. You don't need it to be the actual name of an operator. I
understand. What I'm challenging is whether it's acceptable practice to
overload an existing RADIUS attribute to carry a new data object. Including
a "unique but meaningless salt" in an attribute defined to hold a human
readable operator name sounds attribute overloading to me.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.