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
