Response to Issue 46

["Adrangi, Farid" <farid.adrangi@intel.com>]

Background:
===========
The CUI document define a new RADIUS attribute called a CUI.  The CUI
functions as an handle or an alias to a user identity especially when
the more traditional user identity attributes (username) do not convey
the user identity.  The draft cites one example when this happens mainly
EAP methods that hide that hide the identity.
 
As per the document, the CUI is assigned a value by the home network so
that entities outside the home network, can have a handle to the user to
fulfill certain business scenarios.  The document cites two cases: 1)
when an intermediary requires to ensure that a user is only logged in
once; and 2) For the purpose of billing mediation.
 
To function as a handle to the user identity, it is suffice that the CUI
which is of type string contain an opaque value that is generated by the
home network.  This value is an assertion by the home network that
represents a unique user in their network.  The only operation that is
reasonably allowed to be performed by none home network entities on this
attribute therefore is a binary comparison.

Are there other use-cases?
=========================-

As instructed by David Nelson we are seeking any other use-case
scenarios that would demonstrate the need to change the content of the
CUI, that is would require non-opaqueness; Or ones that would require
semantic changes to the current document.   We are not looking for use
cases that will further support the current CUI document.
 
If there are such use cases, can you please respond with: "[CUI USECASE]
some title" on the list. We will look for consensus to support this
scenario.

BR,
Farid

--
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/>