Re: [radext] CUI comments in "deprecating insecure transports"

[[e-mail]]

Hi Margaret,

> > On Jul 26, 2023, at 5:58 AM, [e-mail] wrote:
> > There are good reasons for the CUI value to be persistent, provided
> > that it is targeted to each network access provider. In this way,
> > different providers cannot collude to track users. However, they still
> > maintain the ability to *recognise* (but not identify) the same user
> > that they saw earlier
> 
> I understand the value of using a single, unique CUI per user/service
provider
> pair in application-level authentication, because the user may have
persistent
> data or state associated with previous application sessions.
> 
> The current document text claims that a persistent CUI across sessions  is
not
> needed for network access.  Do you think there is per-user state that
might be
> maintained by the access provider across sessions, requiring a persistent
CUI?

I can't think of a use-case for that at the moment; however, I wouldn't want
to rule it out, if it costs nothing to support.

> If so, we might want to say that the CUI MUST be unique per user/access
> provider pair, rather than unique per-session.
> 
> In either case, the IDP can store the user<->CUI mapping for later use,
whether
> it is generated for each access provider or for each session, so that the
user can
> be identified later, if necessary.

As I wrote previously, I don't think we need to prescribe the semantics of
the CUI value. The desired semantics may vary on a case-by-case basis, and
so should be controlled by configuration and business agreements.

> The important point is that the same CUI MUST not be sent to multiple
access
> providers to identify the same user.  Hopefully we all agreed on that.

I'm not sure I do agree with that :-) because there are lawful and
legitimate reasons for IDPs and access providers to want to do that. If CUI
doesn't meet these needs,  it is trivial to create a VSA that does...

Josh