RE: Class vs. UserAlias (Was: Re: NAI decoration: User Identity i ssues)

[Avi Lior <avi@bridgewatersystems.com>]

Jari,

I don't think it would be wise to specify what Class should or should not
contain.  IMO we must not touch class.  It will break too many
implementations.

User-Alias or Billable-Identity whatever you want to call it containing a
long lived or short lived handle to the user  (depending on the privacy
need) is the way to go.


> -----Original Message-----
> From: Jari Arkko [mailto:jarkko@piuha.net] 
> Sent: July 16, 2004 3:14 AM
> To: Avi Lior
> Cc: 'Bernard Aboba'; radiusext@ops.ietf.org
> Subject: Class vs. UserAlias (Was: Re: NAI decoration: User 
> Identity issues)
> 
> 
> Avi Lior wrote:
> > A UserAlias can contain some opaque value provided that the 
> > HomeNetwork asserts that it represents a user for a period 
> of time.  
> > That is it will not change over a period of time.  The 
> period of time 
> > could be a month or even longer.
> > 
> > Class attributes could change over the lifetime of even a session 
> > because class attribute may store stuff other then just  the User 
> > Alias.
> 
> One of the problems is indeed that the Class attribute may 
> contain a lot of data, some of which could vary from message 
> to message. And there may be multiple Class attributes.
> 
> One could perhaps argue that if there's a business 
> relationship between X and Y, they should agree that a Class 
> attribute is used, and that the bytes 1-20 represent the true 
> identity. Not sure if that's reasonable, however. Particular 
> server implementations might currently use Class in ways that 
> are not compatible with this approach.
> 
> --Jari
> 

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