RE: Chargeable-User-Identity and Operator-Name

["David B. Nelson" <dnelson@elbrysnetworks.com>]

Tomasz Wolniewicz writes...

> Observe, that the RFC allows the visited institution
> to turn an Access-Accept into and Access-Reject if the
> reply does not contain the CUI. Now *this* is something
> that is very likely to [impact] interoperability, if
> the parties have not agreed on the principles first.

Umm.  No.

First, the RFC says that's the expected / required behavior, so from an
implementation design perspective, it *can't* come as a surprise -- except
to someone who didn't read the RFC carefully.

Second, that's the way that RADIUS has traditionally implemented the notion
of a "mandatory" attribute.  If an attribute is considered "mandatory", the
RADIUS client either effectuates it faithfully or treats the entire message
as if it had been an Access-Reject.  It's an all or nothing proposition.
You'll find this behavior required in a number of RADIUS RFCs.

> Some of our concerns are not about trust in the eduroam
> infrastructure, but about making our lives easier by 
> convincing our site lawyers that the amount of opacity
> introduced by our procedures is high enough to state that
> the CUI is not personal data of our guests.

I hear you.  ;-)

CUI as originally defined certainly passed that litmus test.  How far you
can go with turning it into a secondary form of user identity understood by
multiple parties while claiming it's not personal information is an open
question, I think.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>