Subject: [Sip] Asserted-Identity: How to 'hint'?

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 17 May 2002 16:02:11 -0500

In the course of the discussion between Mark Watson, Cullen Jennings and
myself about the short-term identity work, we have returned a few times to
the question of the infamous hint. This hint is, of course, a way that a
user agent (one that is not a member of the Trust Domain in the short-term
network asserted identity space) can provide a 'hint' to the intermediary
that will generate an Asserted-Identity indicating which identity among
several possibilities should be asserted.

The need for this arises particularly from the 3G space, in which the
authentication process takes place independently of SIP and does not carry
this sort of personal identity information. It also assumes that the
operators of the intermediary in question are aware of several legitimate
identities which the user can elect to assert.

It has been proposed on the mailing list and elsewhere that the
Asserted-Identity header should be re-used by user agents outside the Trust
Domain to provide such a hint. I see a number of reasons for and against
using the Asserted-Identity for this purpose. For example, today, there is a
requirement that asserted-identities which are transmitted from untrusted
sources should not be used in any way - this would seem to weaken that
requirement. There is also possibly some behavior that still needs to be
specified (like how an intermediary would reject or otherwise handle a
request with an inappropriate hint) that might be impactful to our choice.

For the time being, however, I would like to suggest that providing the hint
is outside the scope of the current deliverables (the asserted-identity
requirements and mechanism drafts), which need to be complete, as we
discussed in the interim meeting, by the end of this month. I believe that a
separate draft should propose the use of Asserted-Identity or any other
header for this hint (in whatever timeframe is appropriate for 3G's
requirements), but that we should not speak to this matter in the current
asserted-identity deliverables. There is, as I see it, no dependency on
defining this hint before we dictate how intermediaries will assert
identities.

Any comments on this plan?

Jon Peterson
NeuStar, Inc.

_______________________________________________
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: [email-masked]
Date: Sat, 18 May 2002 07:47:22 +0300

> Any comments on this plan?

first, i don't like at all the idea that ietf sip working group
discussions are dictated and constrained by 3gpp schedules.  we must
have time to really solve the problems and not just hide them under the
carpet because of 3gpp.

second, it is not possible to assert a sip identity of a user without
the hint capability in case the user has more than one possible sip
identity, because in that case the asserting entity would have no other
choice than to reject the call.

third, i don't see the hinting problem to be so complex that it would
need to be hidden under the carper.  in case the caller doesn't want to
be anonymous, the sip uri in the from header can serve as the hint.
this is also good because of backwards compatibility.  in case the from
header is "Anonymous", the hint needs to be provided by another header
that looks like the from header.  we could call it anything, for
example, Really-From.

-- juha