cui-inner.post-auth and cui.post-auth

[Tomasz Wolniewicz]

W dniu 2014-01-29 11:35, stefan.paetow at diamond.ac.uk pisze:
>> The Operator-Name is controlled by the visited site, the CUI is
>> generated to serve the visited site, if the visited site wants to
>> complicate things by messing with the values of the Operator-Name, the
>> authenticating site cannot do much about it nor it should care.
> However, having the user's home site generating different CUI values because the visited site happens to have used for example '1diamond.ac.uk' on one server, and after an upgrade using '1DIAMOND.AC.UK', is not ideal either. If the Operator-Name is technically speaking case-insensitive, then it would make sense to normalise it in some sort or fashion to generate consistent CUIs regardless of casing of the visited site's Operator-Name.
We do not know if every defined namespace of Operator-Name is (or is 
going to be) case-insensitive. REALM definitely is (technically), but 
the implementation does not assume anything about the namespace.

If the visited site cannot control what is sends in the Operator-Name 
then tough luck. CUI is of no value the the home site, so the only side 
affected by the problem is the side that causes the problem.

As I said, no harm can be expected from adding the lower case, but if it 
does not serve any purpose then why add it?

Tomasz

-- 
Tomasz Wolniewicz
           twoln at umk.pl        http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne   Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika     Nicolaus Copernicus University,
pl. Rapackiego 1, Torun               pl. Rapackiego 1, Torun, Poland
tel: +48-56-611-2750     fax: +48-56-622-1850       tel kom.: +48-693-032-576