If your goal is to have a short, focused and constrained WG, I would pull SAML out of it.
Also, RETIRE is probably not the best of acronyms. :) How about "Sip Identity for Generic Name and E.164 Deployments"? (SIGNED) Or "Identity for Trust Assurance with Sip Topologies for Everyone"? (I-TASTE, which is the only way I can identify what I am Sipping :) -hadriel > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean > Willis > Sent: Wednesday, June 25, 2008 12:13 PM > To: [email protected] > Subject: [Sip] Second draft, RETIRE Charter > > 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 _______________________________________________ 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
