Re: [Geopriv] consensus call: authenticated and asserted identities

Henning Schulzrinne <hgs@cs.columbia.edu> Sat, 16 July 2005 01:14 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtbGd-0004ly-ND; Fri, 15 Jul 2005 21:14:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtbGb-0004jW-Sg for geopriv@megatron.ietf.org; Fri, 15 Jul 2005 21:14:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11635 for <geopriv@ietf.org>; Fri, 15 Jul 2005 21:14:55 -0400 (EDT)
Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtbjX-0005Yz-0h for geopriv@ietf.org; Fri, 15 Jul 2005 21:44:51 -0400
Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net [141.153.198.113]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6G1EnKE025684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Jul 2005 21:14:54 -0400 (EDT)
Message-ID: <42D85F6B.7020103@cs.columbia.edu>
Date: Fri, 15 Jul 2005 21:14:19 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Tschofenig, Hannes" <hannes.tschofenig@siemens.com>
Subject: Re: [Geopriv] consensus call: authenticated and asserted identities
References: <ECDC9C7BC7809340842C0E7FCF48C393421E32@MCHP7IEA.ww002.siemens.net>
In-Reply-To: <ECDC9C7BC7809340842C0E7FCF48C393421E32@MCHP7IEA.ww002.siemens.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5
X-Spam-Score: 0.2 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: 7bit
Cc: GEOPRIV <geopriv@ietf.org>
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
Sender: geopriv-bounces@ietf.org
Errors-To: geopriv-bounces@ietf.org

I think the basic question is whether this is likely to be explainable 
to users and whether this is likely to be practically useful, without 
incurring undue complexity.

I would argue that it is neither. In particular, both techniques 
encompass a range of approaches, where there "authenticated is stronger 
than asserted" statements, or vice versa, cannot be made reliably.

As I mentioned before, portability suffers since you now may have to 
list every personal rule twice, just in case the new PA doesn't support 
one or the other. Since there doesn't seem to be universal rule that one 
implies the other, this means duplicating all rules in many cases.

Thus, my suggestion is to either drop the distinction or to make the 
strength a part of the id object, as in

<id entity="alice@example.com" strength="authenticated asserted"/>

with a suitable default value that implies that either is acceptable.

Henning

Tschofenig, Hannes wrote:
> hi all, 
> 
> as raised in a recent discussion about the xml schema of the
> common-policy document there might not be a desire to differentiate
> between authenticated and asserted identity. 
> 
> background:
> -----------
> 
> we used the term authenticated identity if the policy server PS itself
> verified the identity of the watcher/recipient (WR) (typically using
> cryptographic means).
> 
> we used the term asserted identity if the policy server PS verified that
> the WR was authenticated by another party (PS would have to trust the
> other party). as an example, the identity enhancements described in RFC
> 3325 would fit into this category. the PS only gets the assurance that
> another party performed the authentication. 
> 
> if a rule cannot distinguish between these two concepts then the rule
> make implicitly needs to trust the parties trusted by the policy server.
> 
> 
> question: 
> ---------
> 
> should we combine the concepts of authenticated and asserted identities
> (and therefore avoiding a differentiation between them)?  
> 
> ciao
> hannes
> 
> 
> 
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv