Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth

From: Tschofenig Hannes <[email-masked]>
Date: Fri, 7 Nov 2003 10:52:34 +0100

hi jonathan, 

the problem with your approach is the following: you are simply assuming an
email type of identity (which is taken from the authentication procedure).
there you can simply split the domain part from the user part. 

however, geopriv tries to support different 'using protocols'. one possible
using protocol is sip but there are many others.  

these using protocols typically have different authentication mechanisms
which again use different identities. identities in http digest, x.509
certificates, kerberos principal names etc. have a different structure. you
need to know the structure in order to extract the domain part. 

without your <domain> approach you don't need to understand the structure of
the identifier. you only do an equality match. 

ciao
hannes

> > hi jonathan,
> > 
> > could you describe how the domain authorization procedure works?
> > where do you get the domain part for the identifier. the problem we
> > saw in the past was that you have to understand the structure of
> > the identifier in order for it to work.
> 
> I'm not sure I follow. I work for dynamicsoft.com. All URIs in my 
> domain are [email-masked]. I'd like a policy which 
> allows anyone 
> in dynamicsoft.com, but blocks a few irritating people, say joe and 
> bob. So, I would have a policy like this:
> 
> <applies-to>
>    <domain>dynamicsoft.com</domain>
>    <except>
>       <uri>[email-masked]</uri>
>       <uri>[email-masked]</uri>
>    </except>
> </applies-to>
> 
> 
> Where is the complexity here?
> 
> 
> > 
> > ciao hannes
> > 
> > btw, another small issue. the name of the authorization draft is
> > very misleading. there is no need to contain the name xcap in there
> > since the policies should actually be independent of xcap. i
> > noticed the problem with the names in various discussions. people
> > automatically think that those two belong together.
> 
> Yes, I realize that - others have commented similarly. I will 
> be happy 
> to split it up into pieces, wth the XML schema separately, once we 
> have a better grasp of how to bring these two works together.
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Nov 2003 15:00:56 -0500

Sure, not every identity system supports the notions of a user and a 
domain, but a LOT of them do. In any one system in which geopriv gets 
used, you will have to know the set of identity types that are in use. 
Any one system will support only a finite number of authentication 
systems, each of which only supports some number of identities. Even 
if you assume an authentication system that can support any type of 
identity, the geopriv processing would seem to require you to 
understand the type of identity, in order to perform an equality 
operation on it.

As such, I dont see the issue in allowing geopriv to support domain 
based identifiers. If a user is authenticated with a particular 
identity that doesnt have the concept of a domain, that user wouldn't 
be a match for any of <domain> operations.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Nov 2003 15:00:56 -0500

-Jonathan R.