Hi Dean,
the revised charter sounds good.
I'm not sure I like the agronym as it somehow sounds that it will take
longer to solve that problem.
But tht is just naming, the content is more important ;-)
Ciao
Steffen
PS: How about RISE: Roles and Identities in SIP Environments?
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Dean Willis
> Sent: Wednesday, June 25, 2008 6: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
