Shibboleth Developers

["David L. Wasley" <>]

Yes.  I think we're converging.

In your example 2, one could look at it as
   
bob@foo
 as defined within the example.com namespace
   
bob@bar
  "  "        "     "    "            "
Clearly it would be a mistake to remove the entire RHS but then 
suppose there was another user ?  Do you assert 
bob@ or ...?

I would offer another (favorite) example.  Let's assume the EPPN is 
in fact globally unique (through use of a DNS RHS).  If Jeff Schiller 
is on sabbatical at Berkeley for a year, we might choose to assign an 
EPPN of  for him in our directory.  We all know that that 
EPPN belongs to the one and only true Jeffery I. Schiller.  In this 
case stripping the RHS clearly would be wrong.

A Relying Party, on the other hand, might want to receive  
and the fact that is was asserted by an AA/directory at UC Berkeley. 
It's AAP then would say whether to "trust" Berkeley to assert such an 
EPPN.

Maybe there's a subtle issue here: the namespace or scope of EPPN 
versus the asserting party.  In Paul's #3 below, suppose the 
assertion of EPPN is received by server Alpha.com from UCB.edu. 
Alpha then passes it to server Beta.com which passes it to resource 
manager Gamma.com.  If I were Gamma, I would want to know

  (((EPPN asserted by UCB.EDU) asserted by Alpha.com) asserted by Beta.com)

Gamma's AAP then can decide what it wants to do with the EPPN.

In any case, I still feel strongly that the EPPN should be treated as 
an opaque string by every party except perhaps the final relying 
party.  What's the downside of that?  (@xyz.edu?  Ugly 
but so what.  Maybe it should be rewritten as xyz.edu! 
(or berkeley.edu!))

        David
-----
At 11:58 AM -0500 on 1/23/02, Paul B. Hill wrote:

> Hi,
>
> I had originally suggested the EPPN to handle a couple of situations.
>
> One, so that it could be used as a SASL Authorization identifier (the SASL
> spec and most other specs that are using SASL today tend to skip over the
> naming issue when talking about this identifier.)
>
> Two, not all domains have a single namespace. Some sites may still be using
> local password files, so the RHS may actually specify an individual machine.
> E.g. 
>
>  might not be the same as 
> .
>  In
> this case if the "unique identifier" was created by the receiving
> application server it is difficult to determine what the behavior should
> actually be. (Is the receiver going to know that the fully qualified machine
> name should be on the RHS or will it just used to DNS domain name?)
>
> Three, I felt that the RHS should be specified by the originator, nopt the
> application server, so that the identifier could travel through one or more
> servers without getting mangled. By servers in this context I am including
> proxy servers, n-tier systems, relay servers, fanout systems, etc.
>
> Paul
>
> -----Original Message-----
> From: 
>
> [mailto:]On
>  Behalf Of Scott Cantor
> Sent: Wednesday, January 23, 2002 1:57 AM
> To: 'David L. Wasley'; 'Shibboleth Project'; 
> ;
>
> Subject: RE: Attributes, and Shibboleth -- the EPPN swamp
>
>
> >  Furthermore, an EPPN from one domain can not be assumed to be unique
> >  across all such domains, i.e. it is not globally unique.  Therefore,
> >  as an application or resource manager, I would always make the
> >  association
> >
> >     unique_user_identifier = concatenation (EPPN, <asserting domain> )
>
> Maybe I'm wrong, but I understood the intent to be that EPPN was
> universally (more or less) unique?
>
> In other words, I thought EPPN alone was supposed to be unique without
> appending anything else to it. Otherwise, why have the right-hand side?
>
> -- Scott

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

   http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--