Before going to deep on charter names and all, I think it'd be good to
discuss whether it makes sense to have a WG do this work.
The first deliverable is a revision of 4474. There are differing
opinions on the table about whats included in that revision. If all
we're going to do is update it so that its clearer that it really
doesn't work with numbers, we don't need a WG to do that. If we're going
to 'fix' it to work with numbers - I'd prefer to start with a plausible
proposal, and frankly I don't think there is one (an enum-based solution
is pure science fiction...).
We're also pretty far from consensus so far on how/if the SBC problems
can be fixed. Along the same lines, I think we need some agreement that
this is a fixable problem, before chartering a group.
Guidelines for usage of e164 numbers for identifiers - well that is a
REAL problem and a constant source of interop issues (tel vs. sip? + or
not-+?). Worth addressing I think.
Unanticipated respondent problem - we haven't solved this problem yet,
and frankly I'm not convinced we really need to. Given the size of the
gulf between real usage of SIP security and identity mechanisms, and the
specs we've produced, I am reluctant to start new work here without
clear expectation that folks are lining up to actually USE it.
So, net/net is that I am unconvinced there is enough content here to
propose a new WG.
-Jonathan R.
Dean Willis wrote:
I've revised the proposed charter fora RETIRE working group based on
list comments. This is still a very early concept, and the formation of
such a working group is contingent on a great many things that are
outside of my control.
--------
The "REal Time Identity and Role Expression" (RETIRE) Working Group's
purpose is to standardize the expression and assertion of identity and
roles needed for real-time communications with the IETF's Realtime
Applications Infrastructure (RAI) area protocols, primarily the Session
Initiation Protocol (SIP) and others used in conjunction with SIP.
By "Identity", we mean authenticated addresses of record (as defined in
RFC 4474 "Enhancements for Authenticated Identity Management in the
Session Initiation Protocol". RFC 4474 provides a means by which a SIP
server may vouch for the "From" address of a request transiting that
server. It further provides a cryptographic mechanism for testing the
source of the assertion. In the typical case, this mechanism is
dependent on the same Public Key Infrastructure that supports secure
HTTP services. Since RFC 4474 provides only authentication of the source
of SIP request messages and it is also important to determine the
identity of the sender of responses, RFC 4916 "Connected Identity in the
Session Initiation Protocol" provides authenticated identity in an
ongoing SIP dialog by applying RFC 4474 to requests in the reverse
direction. While adequate for some scenarios, this mechanism is not
useful for SIP interactions having a single non-dialog transaction, such
as MESSAGE requests. RFC 4474 suffers additional limitations relating to
its use with E.164 numbers, gateways, session border controllers, and
back-to-back user agents.
By "Role", we mean aspects of a a system user that are related identity,
but more dynamic in nature. For example, Alice might delegate her calls
to Bob. A calling party, expecting to reach Alice but reaching Bob,
needs to know that this is a reasonable thing and what Bob's role in
relation to Alice is. This problem is in general referred to as the
"unanticipated respondent problem", and it has impacts both at the level
of user expectations and key management. Proposals for fixing it have
included deprecation of proxy retargeting and the use of a new SIP
provisional response to inform the calling party about the retargeting
operation.
Security Assertion Markup Language (SAML) is an XML-based standard for
exchanging authentication and authorization data between security
domains, that is, between an identity provider (a producer of
assertions) and a service provider (a consumer of assertions). SAML is a
product of the OASIS Security Services Technical Committee. The SIP
working group worked for several years on applying SAML to SIP with
mixed results, but the technique appears to have great promise.
The initial deliverables of the RETIRE working group are:
1) A standards-track revision of RFC 4474 that resolves its limitations
with respect to E.164 numbers, gateways, session border controllers,
and back-to-back user agents. This revision will also address the use of
Authenticated Identity Management in conjunction with SIP response
messages. It may also be necessary to document the impact of such
changes, if any, on the DTLS-SRTP framework.
2) Specify a solution (or set of solutions) for the Unanticipated
Respondent Problem in SIP.
3) Guidelines for the use of E.164 numbers as SIP identifiers.
4) Guidelines for the use of SAML with SIP for the purposes of
expressing identity and role, specifically in the contexts of #1, #2 and
#3 above.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
--
Jonathan D. Rosenberg, Ph.D. 499 Thornall St.
Cisco Fellow Edison, NJ 08837
Cisco, Voice Technology Group
[EMAIL PROTECTED]
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
