Subject: [Sip] Asserted-Identity - new hint proposal

From: "Cullen Jennings" <[email-masked]>
Date: Tue, 4 Jun 2002 22:36:26 -0700

I am getting the feeling that people want to put the hint in a separate
header. How would everyone feel about something along the lines of:

P-Suggested-Identity: "Cullen Jennings" <sip:[email-masked]>;mandatory

The UAC would insert this header to indicate the Asserted-Identity that it
wished the Trust Domain to choose. The "mandatory" indicates that the Trust
Domain MUST return some 4xx response if it is not going to assert this
identity. If the "mandatory" was not present, it would not return an 4xx if
it choose a different identity to assert for the user.

Should we go with two headers (PSI and PAI)?

Does PSI need some flag (like mandatory) to say how it is handled in the
case the suggested identity is not going to be provided?

Alternatively, should we go with one header and the argument that Dean so
nicely summed up as
> I think existence of a P-A-I header in a message means "a previous hop
> (sender or proxy) has asserted this identity. Deal with it."
>
> Options for dealing with it are:
>
> 1) Believe it
> 2) Delete it (in conjunction with "privacy" modifier)
> 3) Delete it and assert a different identity
> 4) Reject the message

Thanks, Cullen

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 5 Jun 2002 01:48:42 -0500

> header. How would everyone feel about something along the lines of:

I liked one header -- I thought the semantic was pretty good "SOMEBODY
asserted this identity -- vouch for it or reject it". But at this point
I just don't care anymore. . .

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 5 Jun 2002 11:08:47 +0300

Dean Willis writes:

 > But at this point I just don't care anymore. . .

sama here as long as the header that the ua uses is a real sip header,
not a p header.  see the discussion from yesterday.  i'm very suprised
that you simply decided to ignore it and thus caused this vaste of
bandwidth.

-- juha

---

From: Michael Thomas <[email-masked]>
Date: Wed, 5 Jun 2002 07:35:59 -0700 (PDT)

So, I still haven't heard why the role based
assertions is better than the alternative of
identity based assertions. The way it's structured
now, you seemingly either lose information along
the way, or have an ambiguous situtation with
multiple P-Asserted-Identity's. Suppose for
example that my real name is thomasm, but I
want to use my alias mat. What I'd do is:

Asserted-Identity: <sip:[email-masked]>; asserted-by: <[email-masked]>;etc

At my first hop proxy, it would check to see if
[email-masked] was an acceptible alias, and if it
is, it would add a new AI to vouch for me:

Asserted-Identity: <sip:[email-masked]>; asserted-by: <[email-masked]>

When it's forwarded to the UAS proxy, it would
know that it trusts proxy-15's assertions (but not
thomasm's) and therefore add a new header for the
UAS:

Asserted-Identity: <sip:[email-masked]>; asserted-by: <[email-masked]>

So clear back at luser.mtcc.com we finally get the 
INVITE and see these asserted-identities:

Asserted-Identity: <sip:[email-masked]>; asserted-by: <[email-masked]>;etc
Asserted-Identity: <sip:[email-masked]>; asserted-by: <[email-masked]>
Asserted-Identity: <sip:[email-masked]>; asserted-by: <[email-masked]>

The UAS cdr's through the list and discovers --
aha! -- an asserted identity by [email-masked]
which it trusts since it's the inbound proxy.
Therefore, luser.mtcc.com knows that the identity
it will use for the callerid is the one supplied by
proxy-22. If proxy-22 didn't insert an
asserted-identity, it probably means that it
didn't trust the previous hop, and that the UAS
should mark the callerid as suspect, if it
displays anything at all.

Notice that we don't need "roles" here of UA and
proxy, but instead uses their actual identities.
Note also that this could be generally applicable
for more cases where you need to assert identity
such as the firewall-proxy traversal case
especially if it were combined with cryptographic
proof by the party asserting the identity. It
would also allow flexibility of _who_ enables
traversal as well, ie that one of my proxies could
insert the necessary credentials to get me through
a foreign proxy instead of the UAC directly which
would enable aggregation, and separation.

	     Mike