RE: Response to Issue 46 - status so far

[John Loughney <john.loughney@nokia.com>]

Hi Farid,

My guess is that if someone hasn't suggested additional use-cases, then
we should be OK with the current text.  If anyone feels that something
needs to be added, we should probably confirm working consensus before
adding it to the draft.

thanks,
John



--- Original Message ---
From: "ext Adrangi, Farid" <farid.adrangi@intel.com>
To: radiusext@ops.ietf.org
CC: dnelson@enterasys.com, Bernard Aboba <aboba@internaut.com>
Date: Mon Jan 24  05:02:17 EET 2005
Subject: RE: Response to Issue 46 - status so far 




Based on our discussion so far, we have agreed to make the following
clarification on the use-case currently included in the document. 

"
The CUI attribute serves as an alias to the user's real identity,
representing a chargeable identity as defined and provided by the home
network as a supplemental or alternative information to User-Name(1).
Typically the CUI represents the identity of the actual user but it may
also indicate other chargeable identities such as a group of users. 
"

To best of my knowledge, there hasn't been any other use-cases proposed
to the list.  We are planning to submit an update this week -- please
let us know if you have any new use-cases in mind.

BR,
Farid


On Sun, 16 Jan 2005, Adrangi, Farid wrote:

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