Subject: [Sip] draft-ietf-sip-asserted-identity-00

From: "Cullen Jennings" <[email-masked]>
Date: Mon, 27 May 2002 22:38:43 -0700

Jon, Mark, and I have put together a new version of the asserted identity
draft - until it arrives in the archives, you can find it at:

http://www.cs.ubc.ca/~jennings/draft-ietf-sip-asserted-identity-00.html
http://www.cs.ubc.ca/~jennings/draft-ietf-sip-asserted-identity-00.txt

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: Juha Heinanen <[email-masked]>
Date: Tue, 28 May 2002 10:22:32 +0300

once again:

the term "hint" is not a good one.  if user adds the a-i, then the
network MUST respect it or reject the request.  the network MUST not
override the a-i and pick one of the identities on its own.  for
example, the user may have misspelled the its uri in the a-i.

also, the text should say that in case from is anonymous the user MUST
insert the a-i header if it has multiple identities, because otherwise
the network cannot know which identity the user wants to use.

finally, for backwards compatibility, if from is not anonymous and the
user has multiple identities, then from uri can serve as the purpose of
a-i.

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 28 May 2002 13:30:06 -0500

Juha wrote:
> once again:
> 
> the term "hint" is not a good one.  if user adds the a-i, 
> then the network MUST respect it or reject the request.  the 
> network MUST not override the a-i and pick one of the 
> identities on its own.  for example, the user may have 
> misspelled the its uri in the a-i.
> 
> also, the text should say that in case from is anonymous the 
> user MUST insert the a-i header if it has multiple 
> identities, because otherwise the network cannot know which 
> identity the user wants to use.
> 
> finally, for backwards compatibility, if from is not 
> anonymous and the user has multiple identities, then from uri 
> can serve as the purpose of a-i.

Oh my! I think Juha is absolutely correct, in the nost common case. Of
course, there may be other cases.

Commonly, the UA asserts an identity. If it has credentials to do so
(say, a cert issued by a trusted CA) it MAY use those credentials to
provide support for its assertion.

An intermediate service node (authentication or identification server)
MAY also support the assertion by applying its own credentials.

In the common case, the identification server would be expected to
support the assertion made by the UA if the UA made any assertion of
identity. If the UA doesn't assert identity with a-i, then one might
consider the "from" field as a lower-strength assertion of identity, and
the identification server could cryptographically support that identity.
One could also establish the identity to be asserted based on the
identity used in authentication (with digest, for example) or as a
matter of policy (the user didn't say, so they get their "default"
identity asserted).

Of course, there may be special agreements between the user and the
identification server which fall outside this common usage.

Consider, for example, the "anonymization server". Such a server might
strip away all other user identity information, substituting  a "stage
name" (say, "sip:[email-masked]"), which would then be
cryptographically supported by the server. Such a construction would not
be depdendent on any kind of "hinting" mechanism. It would have the
advantage of traceability and nonrepudiability back to the anonymizer
service, which could then (if needed) provide reachability back to the
actual user. This application, while not the general case, does
represent a mode in which the requirements put forth by Juha in the
above text do not actually apply.

So I think it important to differentiate the common usage from the
possible usage. This suggests softening some of the MUSTs suggested by
Juha into SHOULDs, accompanied by appropriate discussion of the possible
use cases.

--
Dean