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

From: "Tschofenig, Hannes" <[email-masked]>
Date: Fri, 15 Jul 2005 16:57:50 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 15 Jul 2005 21:14:19 -0400

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="[email-masked]" strength="authenticated asserted"/>

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

Henning