From nobody Wed Sep 3 13:00:59 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21181A6F0B for ; Wed, 3 Sep 2014 13:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.567 X-Spam-Level: X-Spam-Status: No, score=-99.567 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oVsEXuJeUbe for ; Wed, 3 Sep 2014 13:00:52 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 976F11A0AE4 for ; Wed, 3 Sep 2014 13:00:52 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s83JxxsH013165; Wed, 3 Sep 2014 16:00:51 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1p5n55ahgt-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 03 Sep 2014 16:00:50 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.97]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Wed, 3 Sep 2014 16:00:50 -0400 From: "Peterson, Jon" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] A SIP OAuth use case Thread-Index: AQHPvtLmZYbTlD+FuE+zMNKWASQKqZvhvfeAgAAwjgCADcUOgA== Date: Wed, 3 Sep 2014 20:00:50 +0000 Message-ID: References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> <53FB83FA.8010101@alum.mit.edu> In-Reply-To: <53FB83FA.8010101@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [192.168.129.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <913989F3363F33449FA91E63E5DC4501@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7550 signatures=670510 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=7.7715611723761e-16 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.999510175003986 urlsuspect_oldscore=0.999510175003986 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.999510175003986 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409030213 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/ei93l-pGkZClKygoZJk5w8AvZqI Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 20:00:57 -0000 While I would echo Paul's thoughts below about the plausibility of service providers using this model to authorize recording, I also agree that third-party recording is an excellent example of a service architecture that requires an authorization mechanism like OAuth. An end user needs to authorize a third party to participate in the session under certain constraints, and coordinate the association between the third party and the VoIP service. This example also (rightly, in my opinion) conducts the majority of the flow in HTTP where it belongs. Many of the use cases under discussion in this thread, though, are of the form where there are really only two involved parties: an end user and a service provider. If you are my service provider, then in traditional SIP I share a secret with you that I use to REGISTER my devices. I don't think you need OAuth for that. I do understand that OAuth 2.0 is used in the wild for SSO, though I sympathize with Matt that the base flow shown in RFC6749 Sec 1.2 just doesn't map onto the requirements for SSO. I think, though, we might usefully break uses cases here down by who the intended relying party is: - The user's own SIP service provider (my enterprise, my carrier, my OTT provider) - A third party that a user wants to authorize for a service (recording service... But anything else?) I would also append some use cases where the relying party: - Someone with no association with the user (caller ID sorts of cases) This last is where I've argued things like IdP might be relevant. Are there any other high-level buckets of use cases here? Jon Peterson Neustar, Inc. On 8/25/14, 11:44 AM, "Paul Kyzivat" wrote: >On 8/25/14 11:50 AM, Rifaat Shekh-Yusef wrote: >> Hi Matt, >> >> The use case and the solution provided assumes that the VoIP Provider >> makes the decision on when and what to record. >> While this is a valid use case, there are other use cases that allow the >> user to decide on when and what to record; take a look at RFC6341 for >> more info. >> http://datatracker.ietf.org/doc/rfc6341/ > >SIPREC supports numerous topologies. >It would support the one that Matt outlines as well as end-user >controlled ones. > >I found Matt's use case interesting. I think it would be nice if such >services were available in that form. But I have difficulty imagining >any of the VoIP providers I'm aware of supporting this model. My >impression is that this means that they are giving up a value added >revenue market, that they are loath to do. The most likely justification >I can imagine that they don't want to legal consequences of doing >recording. > > Thanks, > Paul > >> For these use cases, where the user is in control, you need to away to >> authenticate and control which users are allowed to record and the level >> of service provided for that specific user. >> This is where the solutions provided in section 3 or section 4 of the >> SIP OAuth proposal come into play. >> Obviously, in this case the authorization server is different from >> authorization server used to establish the trust relationship between >> the VoIP Provider and the CRS Provider. >> In this case, the authorization server must authenticate the user and >> provide his UA with an access token or a code that controls the user's >> access to the service. >> >> Regards, >> Rifaat >> >> >> >> On Sat, Aug 23, 2014 at 9:05 AM, Matt Ryan > > wrote: >> >> Included is the use case I spoke of before. My apologies for the >>delay. >> >> This is written as though it could be included in >> [draft-yusef-sipcore-sip-oauth] at section 6. >> >> >> 6. Examples >> >> 6.1. Example: Call Recording Service >> >> This example illustrates the use of SIP OAuth between three >> parties: A hosted VoIP service provider, a Call Recording Service >> provider, and a phone system end-user. In this example: >> - The phone system end-user is a customer of both the hosted VoIP >> provider and the Call Recording Service provider >> - The hosted VoIP service provider is a standard provider of hosted >> business-class VoIP telephone service using SIP >> - The Call Recording Service provider is a distinct entity from the >> hosted VoIP provider >> >> The Call Recording Service provides to customers both the call >> recording abilities and management of call recordings >> (configuration, sharing and distribution, retention, etc.). This >> service can accept and record RTP traffic, associate all RTP streams >> with a single call together, and store and catalog the recorded data >> for future searching and retrieval. The service also offers a web >> interface where customers may view and retrieve stored calls. >> Stored calls may range from simple person-to-person voice calls to >> multi-party conferences with a multitude of audio and video >> streams. In this example, customers are billed based on the amount >> of data they store, although other models are certainly possible. >> >> 6.1.1. OAuth 2.0 Roles >> >> In this example, each party assumes the following OAuth 2.0 roles as >> defined in [RFC6749] Section 1.1: >> - The end-user assumes the role of resource owner >> - The hosted VoIP service provider assumes the role of client >> - The Call Recording Service provider assumes the role of resource >> server as well as the role of authorization server >> >> 6.1.2. Description >> >> There are two parts to the example: Initial configuration and >> real-time recording authorization. >> >> Each section includes a simplified flow diagram for the purpose of >> describing the corresponding portion of the example. For the sake >> of brevity, certain parts of the OAuth dialog have been eliminated. >> Implements should refer to [RFC6749] for details on OAuth. >> >> 6.1.2.1 Initial Configuration >> >> +-------------+ +---------------+ +--------------+ >> | End-User | | VoIP Provider | | CRS Provider | >> | Web Browser | | Website | | | >> +-------------+ +---------------+ +--------------+ >> | | | >> | HTTP 1 | | >> | (Configure CRS) | | >> |------------------->| | >> | | | >> | HTTP 2 | | >> | (OAuth Redirect | | >> | to CRS Website) | | >> |<-------------------| | >> | | | >> | HTTP 3 | | >> | (Authorize SIP from VoIP provider | >> |----------------------------------------->| >> | | | >> | HTTP 4 | | >> | (OAuth Redirect back to VoIP portal) | >> |<-----------------------------------------| >> | | | >> | HTTP 5 | | >> |------------------->| | >> | | HTTP 6 | >> | | (Request Access and | >> | | refresh tokens) | >> | |-------------------->| >> | | | >> >> Some time after having signed up for both services, but prior to >> attempting to record any calls, the end-user logs into the web >> portal of the hosted VoIP provider with a web browser and configures >> their call recording service (HTTP 1). This configuration includes >> providing a URI where the call recording service may be reached, >> along with a set of API credentials, provided by the call recording >> service, which will allow the client to initiate an OAuth exchange. >> The end-user also configures the conditions under which call >> recordings should take place. For example, the end-user may request >> to record every multi-party (conference) call, or every call >> involving a specific set of users. The end-user may also specify >> other restrictions, such as restricting codec negotiation to G.711u >> for audio and H.264 for video in order to record the RTP streams. >> Once the end-user saves the configuration, the hosted VoIP provider >> web portal redirects the end-user's web browser to the call >> recording service website and a standard HTTP OAuth dialog begins >> (HTTP 2). The end-user authorizes the hosted VoIP provider to >> access (i.e. send SIP and RTP traffic to) the call recording >> service, for the purpose of recording calls, so long as the >> configured conditions are met (HTTP 3). The result of this >> interaction is that the hosted VoIP provider ends up receiving an >> OAuth access token and refresh token from the call recording service >> (HTTP 4, HTTP 5, HTTP 6). These tokens are saved in the end-user's >> hosted VoIP account database. >> >> 6.1.2.2 Real-time Recording Authorization >> >> +-------------+ +---------------+ +--------------+ >> | End-User | | VoIP Provider | | CRS Provider | >> | SIP Phone | | Website | | | >> +-------------+ +---------------+ +--------------+ >> | | | >> | SIP INVITE 1 | | >> |------------------->| | >> | | SIP INVITE 2 | >> | | (with access token) | >> | |--------------------->| >> | | | >> | | SIP 401 Unauthorized | >> | |<---------------------| >> | | | >> | | SIP INVITE 3 | >> | | (with refresh token) | >> | |--------------------->| >> | | | >> | | SIP 200 1 | >> | | (new access token) | >> | |<---------------------| >> | | | >> | | SIP INVITE 4 | >> | | (with access token) | >> | |--------------------->| >> | | | >> | | SIP 200 2 | >> | |<---------------------| >> | | | >> >> Independently of and after the initial configuration phase, the >> end-user makes a telephone call using the hosted VoIP provider (SIP >> INVITE 1). When this call takes place, the hosted VoIP provider >> looks to see whether it believes this call should be recorded. If >> so, at this point it would branch the call session to the call >> recording service, using SIP OAuth to pass the previously provided >> access token for authorization (SIP INVITE 2). Once the access >> token is validated by the call recording service (perhaps after >> first providing a new access token based on receipt of a valid >> refresh token), the call recording service will check the rights >> that were previously authorized and examine the SIP to determine >> whether it can accept the call. If so, it completes the >> establishment of the session and begins receiving and recording the >> RTP stream(s) (SIP 200 OK). The call recording service provider >> could also deny the request, either because the tokens are invalid >> or because the content of >> the SIP invite does not match the previously authorized >> conditions, in which case a SIP 403 would be returned by the call >> recording service provider and the call would not be recorded - >> however, the initial call branch would continue without >>interruption. >> >> Note: >> [RFC6749] specifies that when a client uses a refresh token to >> request a new access token, the response is HTTP 200 with the new >> access token and optionally a new refresh token included in the >> payload. In this example, a SIP 200 response (SIP 200 1) is sent >> which contains the new token(s). However, this could be confusing >> as SIP 200 is generally viewed as the acceptance of the INVITE, >> which is not what is happening in this case. Should SIP 200 be used >> for consistency, or should another mechanism be used? >> >> 6.1.3. Justification >> >> 6.1.3.1. Hosted VoIP Service Provider >> >> In this example, the hosted VoIP service provider can allow their >> customers to enable call recording in their VoIP service by >> selecting from any of a number of supported call recording service >> providers. This allows the hosted VoIP service provider to offer >> this feature to customers without requiring that the hosted VoIP >> service provider implement and support this feature themselves. >> >> 6.1.3.2. Call Recording Service Provider >> >> In this example, the Call Recording Service provider can focus on >> value and innovation in the area of recording calls and managing >> recorded calls without having to build a full-featured telephony >> offering. >> >> 6.1.3.3. Customer >> >> In this example, the customer has more flexibility in choosing a >> complete solution that meets all of the customer needs. The >> customer does not have to settle for a substandard call recording >> service offering in order to obtain other features they seek in a >> hosted VoIP provider, and vice versa. >> >> 6.1.4. Variants >> >> A simple variant of this example is one wherein one of the services >> (either the VoIP service or the call recording service) is managed >> directly by the end-user, but the other is not. For example, the >> end-user may wish to make use of an external hosted VoIP service >> provider, but may have business or legal reasons that forbid the >> end-user from allowing a third party to store and manage recorded >> calls. The end-user could choose to set up their own call recording >> service as described in this example, and use SIP OAuth to >> facilitate interaction between the hosted VoIP service and the >> end-user's own call recording service. >> >> 6.2. Other SIP OAuth examples >> >> Many other SIP-based services could leverage SIP OAuth to provide >> value-added service to an end-user of a hosted VoIP service >> provider. Some examples of these types of services are listed >>below. >> >> Voicemail service provider: The end-user configures their hosted >> VoIP service provider to manage voicemail through a separate >> voicemail service provider, which chooses whether to store voicemail >> based on existing quotas, Caller ID, etc. >> >> Conferencing service provider: A conferencing service may wish to >> bill customers in a more granular fashion, for example, based on the >> number of participants and attendees in a conference, the duration >> of conference, whether video was also included, which codecs were >> being used, etc. instead of a flat monthly rate. SIP OAuth would >> facilitate metered authorization for a client's use of the service, >> instead of all-or-nothing access. >> >> Call center service provider: A third party may provide ring groups >> or call queues for a hosted VoIP provider along with detailed >> reports and dashboards. The end-user uses OAuth over SIP to control >> who can log into which queues or ring groups, etc. >> >> >> >> -- >> Matt Ryan >> code slinger | zoomulus.com >> ietf at mvryan dot org >> >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Sep 4 08:31:42 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70821A894D for ; Thu, 4 Sep 2014 08:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vhMSPBJ2BDP for ; Thu, 4 Sep 2014 08:31:33 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B131A894A for ; Thu, 4 Sep 2014 08:31:03 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id z11so11531718lbi.8 for ; Thu, 04 Sep 2014 08:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Nw+ZSSGuiOxnzjsvriMoB0u8SuaXFTd7CDQKSmWsXjg=; b=Txxzq2iWd10WPLP++vDYcI+V+SoqeGJyKcmofQehYThES/12cV9gL9teYIBM5r/KWs WXSbysz+YTM2rHQHEK5XprOZO2PZjQex6NAVo5KCv8YYrPpwwe0K6H022/iaWKegjCRy wkC0jfRFt1FOLxj/BnJXp/GDvJMxrlNXF6XSwDuNXVkTMh04XWBImFRuCwKNbpucQKRz tvJvhp6YvVojNz7QUJ2A7ABbUfZbbqqA/hQvILDychX0Vjhp1DgbFX0poLLi5lP3ABgr h3fdtZ4gEenZ/T4U2ld6L8I+XIkx3krAytpvIQ8ifFc3UBiMYGV45SY9n2jFzUDcmXNP ouTA== MIME-Version: 1.0 X-Received: by 10.112.186.35 with SMTP id fh3mr4401424lbc.31.1409844661902; Thu, 04 Sep 2014 08:31:01 -0700 (PDT) Received: by 10.114.2.34 with HTTP; Thu, 4 Sep 2014 08:31:01 -0700 (PDT) In-Reply-To: References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> <53FB83FA.8010101@alum.mit.edu> Date: Thu, 4 Sep 2014 11:31:01 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=001a1134dcc842e27e05023f0a12 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/MBacBXcl1HhkmwXI2iGdo6hG8o8 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 15:31:37 -0000 --001a1134dcc842e27e05023f0a12 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 3, 2014 at 4:00 PM, Peterson, Jon wrote: > > While I would echo Paul's thoughts below about the plausibility of service > providers using this model to authorize recording, I also agree that > third-party recording is an excellent example of a service architecture > that requires an authorization mechanism like OAuth. An end user needs to > authorize a third party to participate in the session under certain > constraints, and coordinate the association between the third party and > the VoIP service. This example also (rightly, in my opinion) conducts the > majority of the flow in HTTP where it belongs. > > I agree with that. > Many of the use cases under discussion in this thread, though, are of the > form where there are really only two involved parties: an end user and a > service provider. If you are my service provider, then in traditional SIP > I share a secret with you that I use to REGISTER my devices. I don't think > you need OAuth for that. If you assume that there is one server that provides all the services, then you are right. But that is not the case all the time. I think that Dale articulated that clearly in the following response: http://www.ietf.org/mail-archive/web/sipcore/current/msg06233.html > I do understand that OAuth 2.0 is used in the > wild for SSO, though I sympathize with Matt that the base flow shown in > RFC6749 Sec 1.2 just doesn't map onto the requirements for SSO. > > I agree that the OAuth 2.0 "as is" does not address the SSO requirements. The SIP OAuth proposal is not just using OAuth 2.0 "as is", but it is extending the framework to authenticate and provide a *user* specific token. Since Matt mentioned OpenID few times, I looked at the OpenID specification. What they are doing there is that they defined a new token, called ID Token, that is associated with the *user*; which is exactly what the SIP OAuth proposal is doing. http://openid.net/specs/openid-connect-core-1_0.html#IDToken My plan is to use the same terminology, ID Token, in the next version of the SIP OAuth document to clarify that, and to differentiate it from the access token. > I think, though, we might usefully break uses cases here down by who the > intended relying party is: > > - The user's own SIP service provider (my enterprise, my carrier, my OTT > provider) > - A third party that a user wants to authorize for a service (recording > service... But anything else?) > > I would also append some use cases where the relying party: > > - Someone with no association with the user (caller ID sorts of cases) > > This last is where I've argued things like IdP might be relevant. > > EKR has a nice description for binding IdP to OAuth in his WebRTC Security Architecture document here: https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10#appendix-A.2 We could use the same idea for SIP. Regards, Rifaat > Are there any other high-level buckets of use cases here? > > Jon Peterson > Neustar, Inc. > > On 8/25/14, 11:44 AM, "Paul Kyzivat" wrote: > > >On 8/25/14 11:50 AM, Rifaat Shekh-Yusef wrote: > >> Hi Matt, > >> > >> The use case and the solution provided assumes that the VoIP Provider > >> makes the decision on when and what to record. > >> While this is a valid use case, there are other use cases that allow the > >> user to decide on when and what to record; take a look at RFC6341 for > >> more info. > >> http://datatracker.ietf.org/doc/rfc6341/ > > > >SIPREC supports numerous topologies. > >It would support the one that Matt outlines as well as end-user > >controlled ones. > > > >I found Matt's use case interesting. I think it would be nice if such > >services were available in that form. But I have difficulty imagining > >any of the VoIP providers I'm aware of supporting this model. My > >impression is that this means that they are giving up a value added > >revenue market, that they are loath to do. The most likely justification > >I can imagine that they don't want to legal consequences of doing > >recording. > > > > Thanks, > > Paul > > > >> For these use cases, where the user is in control, you need to away to > >> authenticate and control which users are allowed to record and the level > >> of service provided for that specific user. > >> This is where the solutions provided in section 3 or section 4 of the > >> SIP OAuth proposal come into play. > >> Obviously, in this case the authorization server is different from > >> authorization server used to establish the trust relationship between > >> the VoIP Provider and the CRS Provider. > >> In this case, the authorization server must authenticate the user and > >> provide his UA with an access token or a code that controls the user's > >> access to the service. > >> > >> Regards, > >> Rifaat > >> > >> > >> > >> On Sat, Aug 23, 2014 at 9:05 AM, Matt Ryan >> > wrote: > >> > >> Included is the use case I spoke of before. My apologies for the > >>delay. > >> > >> This is written as though it could be included in > >> [draft-yusef-sipcore-sip-oauth] at section 6. > >> > >> > >> 6. Examples > >> > >> 6.1. Example: Call Recording Service > >> > >> This example illustrates the use of SIP OAuth between three > >> parties: A hosted VoIP service provider, a Call Recording Service > >> provider, and a phone system end-user. In this example: > >> - The phone system end-user is a customer of both the hosted VoIP > >> provider and the Call Recording Service provider > >> - The hosted VoIP service provider is a standard provider of hosted > >> business-class VoIP telephone service using SIP > >> - The Call Recording Service provider is a distinct entity from the > >> hosted VoIP provider > >> > >> The Call Recording Service provides to customers both the call > >> recording abilities and management of call recordings > >> (configuration, sharing and distribution, retention, etc.). This > >> service can accept and record RTP traffic, associate all RTP streams > >> with a single call together, and store and catalog the recorded data > >> for future searching and retrieval. The service also offers a web > >> interface where customers may view and retrieve stored calls. > >> Stored calls may range from simple person-to-person voice calls to > >> multi-party conferences with a multitude of audio and video > >> streams. In this example, customers are billed based on the amount > >> of data they store, although other models are certainly possible. > >> > >> 6.1.1. OAuth 2.0 Roles > >> > >> In this example, each party assumes the following OAuth 2.0 roles as > >> defined in [RFC6749] Section 1.1: > >> - The end-user assumes the role of resource owner > >> - The hosted VoIP service provider assumes the role of client > >> - The Call Recording Service provider assumes the role of resource > >> server as well as the role of authorization server > >> > >> 6.1.2. Description > >> > >> There are two parts to the example: Initial configuration and > >> real-time recording authorization. > >> > >> Each section includes a simplified flow diagram for the purpose of > >> describing the corresponding portion of the example. For the sake > >> of brevity, certain parts of the OAuth dialog have been eliminated. > >> Implements should refer to [RFC6749] for details on OAuth. > >> > >> 6.1.2.1 Initial Configuration > >> > >> +-------------+ +---------------+ +--------------+ > >> | End-User | | VoIP Provider | | CRS Provider | > >> | Web Browser | | Website | | | > >> +-------------+ +---------------+ +--------------+ > >> | | | > >> | HTTP 1 | | > >> | (Configure CRS) | | > >> |------------------->| | > >> | | | > >> | HTTP 2 | | > >> | (OAuth Redirect | | > >> | to CRS Website) | | > >> |<-------------------| | > >> | | | > >> | HTTP 3 | | > >> | (Authorize SIP from VoIP provider | > >> |----------------------------------------->| > >> | | | > >> | HTTP 4 | | > >> | (OAuth Redirect back to VoIP portal) | > >> |<-----------------------------------------| > >> | | | > >> | HTTP 5 | | > >> |------------------->| | > >> | | HTTP 6 | > >> | | (Request Access and | > >> | | refresh tokens) | > >> | |-------------------->| > >> | | | > >> > >> Some time after having signed up for both services, but prior to > >> attempting to record any calls, the end-user logs into the web > >> portal of the hosted VoIP provider with a web browser and configures > >> their call recording service (HTTP 1). This configuration includes > >> providing a URI where the call recording service may be reached, > >> along with a set of API credentials, provided by the call recording > >> service, which will allow the client to initiate an OAuth exchange. > >> The end-user also configures the conditions under which call > >> recordings should take place. For example, the end-user may request > >> to record every multi-party (conference) call, or every call > >> involving a specific set of users. The end-user may also specify > >> other restrictions, such as restricting codec negotiation to G.711u > >> for audio and H.264 for video in order to record the RTP streams. > >> Once the end-user saves the configuration, the hosted VoIP provider > >> web portal redirects the end-user's web browser to the call > >> recording service website and a standard HTTP OAuth dialog begins > >> (HTTP 2). The end-user authorizes the hosted VoIP provider to > >> access (i.e. send SIP and RTP traffic to) the call recording > >> service, for the purpose of recording calls, so long as the > >> configured conditions are met (HTTP 3). The result of this > >> interaction is that the hosted VoIP provider ends up receiving an > >> OAuth access token and refresh token from the call recording service > >> (HTTP 4, HTTP 5, HTTP 6). These tokens are saved in the end-user's > >> hosted VoIP account database. > >> > >> 6.1.2.2 Real-time Recording Authorization > >> > >> +-------------+ +---------------+ +--------------+ > >> | End-User | | VoIP Provider | | CRS Provider | > >> | SIP Phone | | Website | | | > >> +-------------+ +---------------+ +--------------+ > >> | | | > >> | SIP INVITE 1 | | > >> |------------------->| | > >> | | SIP INVITE 2 | > >> | | (with access token) | > >> | |--------------------->| > >> | | | > >> | | SIP 401 Unauthorized | > >> | |<---------------------| > >> | | | > >> | | SIP INVITE 3 | > >> | | (with refresh token) | > >> | |--------------------->| > >> | | | > >> | | SIP 200 1 | > >> | | (new access token) | > >> | |<---------------------| > >> | | | > >> | | SIP INVITE 4 | > >> | | (with access token) | > >> | |--------------------->| > >> | | | > >> | | SIP 200 2 | > >> | |<---------------------| > >> | | | > >> > >> Independently of and after the initial configuration phase, the > >> end-user makes a telephone call using the hosted VoIP provider (SIP > >> INVITE 1). When this call takes place, the hosted VoIP provider > >> looks to see whether it believes this call should be recorded. If > >> so, at this point it would branch the call session to the call > >> recording service, using SIP OAuth to pass the previously provided > >> access token for authorization (SIP INVITE 2). Once the access > >> token is validated by the call recording service (perhaps after > >> first providing a new access token based on receipt of a valid > >> refresh token), the call recording service will check the rights > >> that were previously authorized and examine the SIP to determine > >> whether it can accept the call. If so, it completes the > >> establishment of the session and begins receiving and recording the > >> RTP stream(s) (SIP 200 OK). The call recording service provider > >> could also deny the request, either because the tokens are invalid > >> or because the content of > >> the SIP invite does not match the previously authorized > >> conditions, in which case a SIP 403 would be returned by the call > >> recording service provider and the call would not be recorded - > >> however, the initial call branch would continue without > >>interruption. > >> > >> Note: > >> [RFC6749] specifies that when a client uses a refresh token to > >> request a new access token, the response is HTTP 200 with the new > >> access token and optionally a new refresh token included in the > >> payload. In this example, a SIP 200 response (SIP 200 1) is sent > >> which contains the new token(s). However, this could be confusing > >> as SIP 200 is generally viewed as the acceptance of the INVITE, > >> which is not what is happening in this case. Should SIP 200 be used > >> for consistency, or should another mechanism be used? > >> > >> 6.1.3. Justification > >> > >> 6.1.3.1. Hosted VoIP Service Provider > >> > >> In this example, the hosted VoIP service provider can allow their > >> customers to enable call recording in their VoIP service by > >> selecting from any of a number of supported call recording service > >> providers. This allows the hosted VoIP service provider to offer > >> this feature to customers without requiring that the hosted VoIP > >> service provider implement and support this feature themselves. > >> > >> 6.1.3.2. Call Recording Service Provider > >> > >> In this example, the Call Recording Service provider can focus on > >> value and innovation in the area of recording calls and managing > >> recorded calls without having to build a full-featured telephony > >> offering. > >> > >> 6.1.3.3. Customer > >> > >> In this example, the customer has more flexibility in choosing a > >> complete solution that meets all of the customer needs. The > >> customer does not have to settle for a substandard call recording > >> service offering in order to obtain other features they seek in a > >> hosted VoIP provider, and vice versa. > >> > >> 6.1.4. Variants > >> > >> A simple variant of this example is one wherein one of the services > >> (either the VoIP service or the call recording service) is managed > >> directly by the end-user, but the other is not. For example, the > >> end-user may wish to make use of an external hosted VoIP service > >> provider, but may have business or legal reasons that forbid the > >> end-user from allowing a third party to store and manage recorded > >> calls. The end-user could choose to set up their own call recording > >> service as described in this example, and use SIP OAuth to > >> facilitate interaction between the hosted VoIP service and the > >> end-user's own call recording service. > >> > >> 6.2. Other SIP OAuth examples > >> > >> Many other SIP-based services could leverage SIP OAuth to provide > >> value-added service to an end-user of a hosted VoIP service > >> provider. Some examples of these types of services are listed > >>below. > >> > >> Voicemail service provider: The end-user configures their hosted > >> VoIP service provider to manage voicemail through a separate > >> voicemail service provider, which chooses whether to store voicemail > >> based on existing quotas, Caller ID, etc. > >> > >> Conferencing service provider: A conferencing service may wish to > >> bill customers in a more granular fashion, for example, based on the > >> number of participants and attendees in a conference, the duration > >> of conference, whether video was also included, which codecs were > >> being used, etc. instead of a flat monthly rate. SIP OAuth would > >> facilitate metered authorization for a client's use of the service, > >> instead of all-or-nothing access. > >> > >> Call center service provider: A third party may provide ring groups > >> or call queues for a hosted VoIP provider along with detailed > >> reports and dashboards. The end-user uses OAuth over SIP to control > >> who can log into which queues or ring groups, etc. > >> > >> > >> > >> -- > >> Matt Ryan > >> code slinger | zoomulus.com > >> ietf at mvryan dot org > >> > >> > >> > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > >> > >> > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > > >_______________________________________________ > >sipcore mailing list > >sipcore@ietf.org > >https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a1134dcc842e27e05023f0a12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Sep 3, 2014 at 4:00 PM, Peterson, Jon <= ;jon.peterson= @neustar.biz> wrote:

While I would echo Paul's thoughts below about the plausibility of serv= ice
providers using this model to authorize recording, I also agree that
third-party recording is an excellent example of a service architecture
that requires an authorization mechanism like OAuth. An end user needs to authorize a third party to participate in the session under certain
constraints, and coordinate the association between the third party and
the VoIP service. This example also (rightly, in my opinion) conducts the majority of the flow in HTTP where it belongs.


I agree with that.

=A0
Many of the use cases under discussion in this thread, though, are of the form where there are really only two involved parties: an end user and a service provider. If you are my service provider, then in traditional SIP I share a secret with you that I use to REGISTER my devices. I don't th= ink
you need OAuth for that.

If you assume tha= t there is one server that provides all the services, then you are right.
But that is not the case all the time. I think that Dale articulat= ed that clearly in the following response:

=A0
I do understand that OAuth 2.0 is used in th= e
wild for SSO, though I sympathize with Matt that the base flow shown in
RFC6749 Sec 1.2 just doesn't map onto the requirements for SSO.


I agree that the OAuth 2.0 "as is= " does not address the SSO requirements.
The SIP OAuth propo= sal is not just using OAuth 2.0 "as is", but it is extending the = framework to authenticate and provide a *user* specific token.

Since Matt mentioned OpenID few times, I looked at the = OpenID specification.
What they are doing there is that they defi= ned a new token, called ID Token, that is associated with the *user*; which= is exactly what the SIP OAuth proposal is doing.

My plan is to use the same terminol= ogy, ID Token, in the next version of the SIP OAuth document to clarify tha= t, and to differentiate it from the access token.

=A0
I think, though, we might usefully break uses cases here down by who the intended relying party is:

- The user's own SIP service provider (my enterprise, my carrier, my OT= T
provider)
- A third party that a user wants to authorize for a service (recording
service... But anything else?)

I would also append some use cases where the relying party:

- Someone with no association with the user (caller ID sorts of cases)

This last is where I've argued things like IdP might be relevant.


EKR has a nice description for binding= IdP to OAuth in his WebRTC Security Architecture document here:

We could use the same idea for SIP.

Regards,
=A0Rifaat


=A0
Are there any other high-level buckets of use cases here?

Jon Peterson
Neustar, Inc.

On 8/25/14, 11:44 AM, "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote:

>On 8/25/14 11:50 AM, Rifaat Shekh-Yusef wrote:
>> Hi Matt,
>>
>> The use case and the solution provided assumes that the VoIP Provi= der
>> makes the decision on when and what to record.
>> While this is a valid use case, there are other use cases that all= ow the
>> user to decide on when and what to record; take a look at RFC6341 = for
>> more info.
>> http://datatracker.ietf.org/doc/rfc6341/
>
>SIPREC supports numerous topologies.
>It would support the one that Matt outlines as well as end-user
>controlled ones.
>
>I found Matt's use case interesting. I think it would be nice if su= ch
>services were available in that form. But I have difficulty imagining >any of the VoIP providers I'm aware of supporting this model. My >impression is that this means that they are giving up a value added
>revenue market, that they are loath to do. The most likely justificatio= n
>I can imagine that they don't want to legal consequences of doing >recording.
>
>=A0 =A0 =A0 =A0Thanks,
>=A0 =A0 =A0 =A0Paul
>
>> For these use cases, where the user is in control, you need to awa= y to
>> authenticate and control which users are allowed to record and the= level
>> of service provided for that specific user.
>> This is where the solutions provided in section 3 or section 4 of = the
>> SIP OAuth proposal come into play.
>> Obviously, in this case the authorization server is different from=
>> authorization server used to establish the trust relationship betw= een
>> the VoIP Provider and the CRS Provider.
>> In this case, the authorization server must authenticate the user = and
>> provide his UA with an access token or a code that controls the us= er's
>> access to the service.
>>
>> Regards,
>>=A0 =A0Rifaat
>>
>>
>>
>> On Sat, Aug 23, 2014 at 9:05 AM, Matt Ryan <ietf@mvryan.org
>> <mailto:ie= tf@mvryan.org>> wrote:
>>
>>=A0 =A0 =A0Included is the use case I spoke of before.=A0 My apolog= ies for the
>>delay.
>>
>>=A0 =A0 =A0This is written as though it could be included in
>>=A0 =A0 =A0[draft-yusef-sipcore-sip-oauth] at section 6.
>>
>>
>>=A0 =A0 =A06. Examples
>>
>>=A0 =A0 =A06.1. Example: Call Recording Service
>>
>>=A0 =A0 =A0This example illustrates the use of SIP OAuth between th= ree
>>=A0 =A0 =A0parties:=A0 A hosted VoIP service provider, a Call Recor= ding Service
>>=A0 =A0 =A0provider, and a phone system end-user.=A0 In this exampl= e:
>>=A0 =A0 =A0- The phone system end-user is a customer of both the ho= sted VoIP
>>=A0 =A0 =A0provider and the Call Recording Service provider
>>=A0 =A0 =A0- The hosted VoIP service provider is a standard provide= r of hosted
>>=A0 =A0 =A0business-class VoIP telephone service using SIP
>>=A0 =A0 =A0- The Call Recording Service provider is a distinct enti= ty from the
>>=A0 =A0 =A0hosted VoIP provider
>>
>>=A0 =A0 =A0The Call Recording Service provides to customers both th= e call
>>=A0 =A0 =A0recording abilities and management of call recordings >>=A0 =A0 =A0(configuration, sharing and distribution, retention, etc= .).=A0 This
>>=A0 =A0 =A0service can accept and record RTP traffic, associate all= RTP streams
>>=A0 =A0 =A0with a single call together, and store and catalog the r= ecorded data
>>=A0 =A0 =A0for future searching and retrieval.=A0 The service also = offers a web
>>=A0 =A0 =A0interface where customers may view and retrieve stored c= alls.
>>=A0 =A0 =A0Stored calls may range from simple person-to-person voic= e calls to
>>=A0 =A0 =A0multi-party conferences with a multitude of audio and vi= deo
>>=A0 =A0 =A0streams.=A0 In this example, customers are billed based = on the amount
>>=A0 =A0 =A0of data they store, although other models are certainly = possible.
>>
>>=A0 =A0 =A06.1.1. OAuth 2.0 Roles
>>
>>=A0 =A0 =A0In this example, each party assumes the following OAuth = 2.0 roles as
>>=A0 =A0 =A0defined in [RFC6749] Section 1.1:
>>=A0 =A0 =A0- The end-user assumes the role of resource owner
>>=A0 =A0 =A0- The hosted VoIP service provider assumes the role of c= lient
>>=A0 =A0 =A0- The Call Recording Service provider assumes the role o= f resource
>>=A0 =A0 =A0server as well as the role of authorization server
>>
>>=A0 =A0 =A06.1.2. Description
>>
>>=A0 =A0 =A0There are two parts to the example:=A0 Initial configura= tion and
>>=A0 =A0 =A0real-time recording authorization.
>>
>>=A0 =A0 =A0Each section includes a simplified flow diagram for the = purpose of
>>=A0 =A0 =A0describing the corresponding portion of the example.=A0 = For the sake
>>=A0 =A0 =A0of brevity, certain parts of the OAuth dialog have been = eliminated.
>>=A0 =A0 =A0Implements should refer to [RFC6749] for details on OAut= h.
>>
>>=A0 =A0 =A06.1.2.1 Initial Configuration
>>
>>=A0 =A0 =A0 =A0 +-------------+=A0 =A0 =A0+---------------+=A0 =A0 = =A0+--------------+
>>=A0 =A0 =A0 =A0 |=A0 End-User=A0 =A0|=A0 =A0 =A0| VoIP Provider |= =A0 =A0 =A0| CRS Provider |
>>=A0 =A0 =A0 =A0 | Web Browser |=A0 =A0 =A0|=A0 =A0 Website=A0 =A0 |= =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 +-------------+=A0 =A0 =A0+---------------+=A0 =A0 = =A0+--------------+
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| HTTP 1=A0 =A0 =A0 =A0 =A0 =A0 =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| (Configure CRS)=A0 =A0 |=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|------------------->|=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| HTTP 2=A0 =A0 =A0 =A0 =A0 =A0 =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| (OAuth Redirect=A0 =A0 |=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 to CRS Website)=A0 =A0|=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<-------------------|=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| HTTP 3=A0 =A0 =A0 =A0 =A0 =A0 =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| (Authorize SIP from VoIP provider= =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|-----------------------------------= ------>|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| HTTP 4=A0 =A0 =A0 =A0 =A0 =A0 =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| (OAuth Redirect back to VoIP porta= l)=A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<-------------------------------= ----------|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| HTTP 5=A0 =A0 =A0 =A0 =A0 =A0 =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|------------------->|=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | HTTP 6=A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | (Request Access and |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 refresh tokens)=A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |-------------------->|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>
>>=A0 =A0 =A0Some time after having signed up for both services, but = prior to
>>=A0 =A0 =A0attempting to record any calls, the end-user logs into t= he web
>>=A0 =A0 =A0portal of the hosted VoIP provider with a web browser an= d configures
>>=A0 =A0 =A0their call recording service (HTTP 1).=A0 This configura= tion includes
>>=A0 =A0 =A0providing a URI where the call recording service may be = reached,
>>=A0 =A0 =A0along with a set of API credentials, provided by the cal= l recording
>>=A0 =A0 =A0service, which will allow the client to initiate an OAut= h exchange.
>>=A0 =A0 =A0The end-user also configures the conditions under which = call
>>=A0 =A0 =A0recordings should take place.=A0 For example, the end-us= er may request
>>=A0 =A0 =A0to record every multi-party (conference) call, or every = call
>>=A0 =A0 =A0involving a specific set of users.=A0 The end-user may a= lso specify
>>=A0 =A0 =A0other restrictions, such as restricting codec negotiatio= n to G.711u
>>=A0 =A0 =A0for audio and H.264 for video in order to record the RTP= streams.
>>=A0 =A0 =A0Once the end-user saves the configuration, the hosted Vo= IP provider
>>=A0 =A0 =A0web portal redirects the end-user's web browser to t= he call
>>=A0 =A0 =A0recording service website and a standard HTTP OAuth dial= og begins
>>=A0 =A0 =A0(HTTP 2).=A0 The end-user authorizes the hosted VoIP pro= vider to
>>=A0 =A0 =A0access (i.e. send SIP and RTP traffic to) the call recor= ding
>>=A0 =A0 =A0service, for the purpose of recording calls, so long as = the
>>=A0 =A0 =A0configured conditions are met (HTTP 3).=A0 The result of= this
>>=A0 =A0 =A0interaction is that the hosted VoIP provider ends up rec= eiving an
>>=A0 =A0 =A0OAuth access token and refresh token from the call recor= ding service
>>=A0 =A0 =A0(HTTP 4, HTTP 5, HTTP 6).=A0 These tokens are saved in t= he end-user's
>>=A0 =A0 =A0hosted VoIP account database.
>>
>>=A0 =A0 =A06.1.2.2 Real-time Recording Authorization
>>
>>=A0 =A0 =A0 =A0 +-------------+=A0 =A0 =A0+---------------+=A0 =A0 = =A0 +--------------+
>>=A0 =A0 =A0 =A0 |=A0 End-User=A0 =A0|=A0 =A0 =A0| VoIP Provider |= =A0 =A0 =A0 | CRS Provider |
>>=A0 =A0 =A0 =A0 |=A0 SIP Phone=A0 |=A0 =A0 =A0|=A0 =A0 Website=A0 = =A0 |=A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 +-------------+=A0 =A0 =A0+---------------+=A0 =A0 = =A0 +--------------+
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| SIP INVITE 1=A0 =A0 =A0 =A0|=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|------------------->|=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP INVITE 2=A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | (with access token)=A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |--------------------->|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP 401 Unauthorized |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |<---------------------|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP INVITE 3=A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | (with refresh token) |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |--------------------->|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP 200 1=A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | (new access token)=A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |<---------------------|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP INVITE 4=A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | (with access token)=A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |--------------------->|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP 200 2=A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |<---------------------|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>
>>=A0 =A0 =A0Independently of and after the initial configuration pha= se, the
>>=A0 =A0 =A0end-user makes a telephone call using the hosted VoIP pr= ovider (SIP
>>=A0 =A0 =A0INVITE 1).=A0 When this call takes place, the hosted VoI= P provider
>>=A0 =A0 =A0looks to see whether it believes this call should be rec= orded.=A0 If
>>=A0 =A0 =A0so, at this point it would branch the call session to th= e call
>>=A0 =A0 =A0recording service, using SIP OAuth to pass the previousl= y provided
>>=A0 =A0 =A0access token for authorization (SIP INVITE 2).=A0 Once t= he access
>>=A0 =A0 =A0token is validated by the call recording service (perhap= s after
>>=A0 =A0 =A0first providing a new access token based on receipt of a= valid
>>=A0 =A0 =A0refresh token), the call recording service will check th= e rights
>>=A0 =A0 =A0that were previously authorized and examine the SIP to d= etermine
>>=A0 =A0 =A0whether it can accept the call.=A0 If so, it completes t= he
>>=A0 =A0 =A0establishment of the session and begins receiving and re= cording the
>>=A0 =A0 =A0RTP stream(s) (SIP 200 OK).=A0 The call recording servic= e provider
>>=A0 =A0 =A0could also deny the request, either because the tokens a= re invalid
>>=A0 =A0 =A0or because the content of
>>=A0 =A0 =A0 =A0the SIP invite does not match the previously authori= zed
>>=A0 =A0 =A0conditions, in which case a SIP 403 would be returned by= the call
>>=A0 =A0 =A0recording service provider and the call would not be rec= orded -
>>=A0 =A0 =A0however, the initial call branch would continue without<= br> >>interruption.
>>
>>=A0 =A0 =A0Note:
>>=A0 =A0 =A0[RFC6749] specifies that when a client uses a refresh to= ken to
>>=A0 =A0 =A0request a new access token, the response is HTTP 200 wit= h the new
>>=A0 =A0 =A0access token and optionally a new refresh token included= in the
>>=A0 =A0 =A0payload.=A0 In this example, a SIP 200 response (SIP 200= 1) is sent
>>=A0 =A0 =A0which contains the new token(s).=A0 However, this could = be confusing
>>=A0 =A0 =A0as SIP 200 is generally viewed as the acceptance of the = INVITE,
>>=A0 =A0 =A0which is not what is happening in this case.=A0 Should S= IP 200 be used
>>=A0 =A0 =A0for consistency, or should another mechanism be used? >>
>>=A0 =A0 =A06.1.3. Justification
>>
>>=A0 =A0 =A06.1.3.1. Hosted VoIP Service Provider
>>
>>=A0 =A0 =A0In this example, the hosted VoIP service provider can al= low their
>>=A0 =A0 =A0customers to enable call recording in their VoIP service= by
>>=A0 =A0 =A0selecting from any of a number of supported call recordi= ng service
>>=A0 =A0 =A0providers.=A0 This allows the hosted VoIP service provid= er to offer
>>=A0 =A0 =A0this feature to customers without requiring that the hos= ted VoIP
>>=A0 =A0 =A0service provider implement and support this feature them= selves.
>>
>>=A0 =A0 =A06.1.3.2. Call Recording Service Provider
>>
>>=A0 =A0 =A0In this example, the Call Recording Service provider can= focus on
>>=A0 =A0 =A0value and innovation in the area of recording calls and = managing
>>=A0 =A0 =A0recorded calls without having to build a full-featured t= elephony
>>=A0 =A0 =A0offering.
>>
>>=A0 =A0 =A06.1.3.3. Customer
>>
>>=A0 =A0 =A0In this example, the customer has more flexibility in ch= oosing a
>>=A0 =A0 =A0complete solution that meets all of the customer needs.= =A0 The
>>=A0 =A0 =A0customer does not have to settle for a substandard call = recording
>>=A0 =A0 =A0service offering in order to obtain other features they = seek in a
>>=A0 =A0 =A0hosted VoIP provider, and vice versa.
>>
>>=A0 =A0 =A06.1.4. Variants
>>
>>=A0 =A0 =A0A simple variant of this example is one wherein one of t= he services
>>=A0 =A0 =A0(either the VoIP service or the call recording service) = is managed
>>=A0 =A0 =A0directly by the end-user, but the other is not.=A0 For e= xample, the
>>=A0 =A0 =A0end-user may wish to make use of an external hosted VoIP= service
>>=A0 =A0 =A0provider, but may have business or legal reasons that fo= rbid the
>>=A0 =A0 =A0end-user from allowing a third party to store and manage= recorded
>>=A0 =A0 =A0calls.=A0 The end-user could choose to set up their own = call recording
>>=A0 =A0 =A0service as described in this example, and use SIP OAuth = to
>>=A0 =A0 =A0facilitate interaction between the hosted VoIP service a= nd the
>>=A0 =A0 =A0end-user's own call recording service.
>>
>>=A0 =A0 =A06.2. Other SIP OAuth examples
>>
>>=A0 =A0 =A0Many other SIP-based services could leverage SIP OAuth t= o provide
>>=A0 =A0 =A0value-added service to an end-user of a hosted VoIP serv= ice
>>=A0 =A0 =A0provider.=A0 Some examples of these types of services ar= e listed
>>below.
>>
>>=A0 =A0 =A0Voicemail service provider:=A0 The end-user configures t= heir hosted
>>=A0 =A0 =A0VoIP service provider to manage voicemail through a sepa= rate
>>=A0 =A0 =A0voicemail service provider, which chooses whether to sto= re voicemail
>>=A0 =A0 =A0based on existing quotas, Caller ID, etc.
>>
>>=A0 =A0 =A0Conferencing service provider:=A0 A conferencing service= may wish to
>>=A0 =A0 =A0bill customers in a more granular fashion, for example, = based on the
>>=A0 =A0 =A0number of participants and attendees in a conference, th= e duration
>>=A0 =A0 =A0of conference, whether video was also included, which co= decs were
>>=A0 =A0 =A0being used, etc. instead of a flat monthly rate.=A0 SIP = OAuth would
>>=A0 =A0 =A0facilitate metered authorization for a client's use = of the service,
>>=A0 =A0 =A0instead of all-or-nothing access.
>>
>>=A0 =A0 =A0Call center service provider:=A0 A third party may provi= de ring groups
>>=A0 =A0 =A0or call queues for a hosted VoIP provider along with det= ailed
>>=A0 =A0 =A0reports and dashboards.=A0 The end-user uses OAuth over = SIP to control
>>=A0 =A0 =A0who can log into which queues or ring groups, etc.
>>
>>
>>
>>=A0 =A0 =A0--
>>=A0 =A0 =A0Matt Ryan
>>=A0 =A0 =A0code slinger | zoomulus.com <http://zoomulus.com>
>>=A0 =A0 =A0ietf at mvryan dot org
>>
>>
>>
>>
>>=A0 =A0 =A0_______________________________________________
>>=A0 =A0 =A0sipcore mailing list
>>=A0 =A0 =A0si= pcore@ietf.org <mailto:sipcore@ietf.org>
>>=A0 =A0 =A0https://www.ietf.org/mailman/listinfo/sipcore
>>
>>
>>
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf= .org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>
>_______________________________________________
>sipcore mailing list
>sipcore@ietf.org<= /a>
>https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--001a1134dcc842e27e05023f0a12-- From nobody Thu Sep 4 15:10:50 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331C41A00F0 for ; Thu, 4 Sep 2014 15:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmpY8S7wRY0I for ; Thu, 4 Sep 2014 15:10:46 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 104BC1A00F8 for ; Thu, 4 Sep 2014 15:10:39 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta13.westchester.pa.mail.comcast.net with comcast id nA8C1o0031swQuc5DAAfY1; Thu, 04 Sep 2014 22:10:39 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta15.westchester.pa.mail.comcast.net with comcast id nAAf1o0011KKtkw3bAAf29; Thu, 04 Sep 2014 22:10:39 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s84MAcIZ001102; Thu, 4 Sep 2014 18:10:38 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s84MAbSV001101; Thu, 4 Sep 2014 18:10:38 -0400 Date: Thu, 4 Sep 2014 18:10:38 -0400 Message-Id: <201409042210.s84MAbSV001101@hobgoblin.ariadne.com> From: worley@alum.mit.edu (Dale R. Worley) Sender: worley@alum.mit.edu (Dale R. Worley) To: Matt Ryan In-reply-to: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> (ietf@mvryan.org) References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1409868639; bh=V0zqRwjn+jjPfDPGKLM2y8IG4ZOBOnfyajYWF2I02e4=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=mUA+XeEmID6LTm6vF4iKfLXno2PDhounaK9TbEj2ABpaClCHzpcC/DpUKVT/Wl/A4 TOLocdDrpm6gJa9MWzQGyFTsDfZ7rfkyFxSH5cVRkIbTv1CCXUi9p5oFoUdhKuO4MP 5IiyjO4DSannEpAepg0HYmkULt2R9F8SJPbfB1dU3ZD6jdiNtVjXGxhBaJxuXVnX0f f7QkSVsQctJwFL3Q3PP1tb2T3gERanoN2YkyeuUwsaG5L9e2NXWRrH/QrkbV4vbQIO 9de2Ujuawn6zea61xKM1F4XdYpJRBCoqQQJjjVUwZ+ec8kcIgUaLPJoBfWHKPccRbn /eIcAvfpzn56g== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/zbTFSLTZhF0OMWjSb_tL1aboK4Q Cc: sipcore@ietf.org Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 22:10:49 -0000 > From: Matt Ryan > 6.1.2.2 Real-time Recording Authorization This is the most detailed example I've see so far, and as such, it's quite valuable, regardless of whether the business case is plausible or not. It would help me to see detailed message examples for these flows. > +-------------+ +---------------+ +--------------+ > | End-User | | VoIP Provider | | CRS Provider | > | SIP Phone | | Website | | | > +-------------+ +---------------+ +--------------+ > | | | > | SIP INVITE 1 | | > |------------------->| | > | | SIP INVITE 2 | > | | (with access token) | > | |--------------------->| > | | | > | | SIP 401 Unauthorized | > | |<---------------------| > | | | > | | SIP INVITE 3 | > | | (with refresh token) | > | |--------------------->| > | | | > | | SIP 200 1 | > | | (new access token) | > | |<---------------------| > | | | > | | SIP INVITE 4 | > | | (with access token) | > | |--------------------->| > | | | > | | SIP 200 2 | > | |<---------------------| > | | | > [RFC6749] specifies that when a client uses a refresh token to > request a new access token, the response is HTTP 200 with the new > access token and optionally a new refresh token included in the > payload. In this example, a SIP 200 response (SIP 200 1) is sent > which contains the new token(s). However, this could be confusing > as SIP 200 is generally viewed as the acceptance of the INVITE, > which is not what is happening in this case. Should SIP 200 be used > for consistency, or should another mechanism be used? I would say that the answer depends on whether response "SIP 200 1" establishes a dialog or not. If it does, then 200 (or 2xx) is correct. If it does not establish a dialog, and "VoIP Provider" must send another INVITE to establish a dialog, then a 4xx response is needed. Naively, it's not clear why there would be a requirement for "VoIP Provider" to send another INVITE containing the access token that it just received in a SIP response. But I suppose if that worked, "VoIP Provider" would just send the refresh token every time. There is also the architectural possbility that "VoIP Provider" uses a protocol other than SIP to convert the refresh token into a new access token. Dale From nobody Thu Sep 4 16:28:31 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44631A02E9 for ; Thu, 4 Sep 2014 16:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.566 X-Spam-Level: X-Spam-Status: No, score=-101.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dOTWoe75DC0 for ; Thu, 4 Sep 2014 16:28:26 -0700 (PDT) Received: from mx0a-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FBB01A02D9 for ; Thu, 4 Sep 2014 16:28:26 -0700 (PDT) Received: from pps.filterd (m0049376.ppops.net [127.0.0.1]) by m0049376.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s84NRCPX008192; Thu, 4 Sep 2014 19:27:52 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049376.ppops.net-0018ba01. with ESMTP id 1p6pun9v3d-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 04 Sep 2014 19:27:50 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.97]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Thu, 4 Sep 2014 19:27:49 -0400 From: "Peterson, Jon" To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] A SIP OAuth use case Thread-Index: AQHPvtLmZYbTlD+FuE+zMNKWASQKqZvhvfeAgAAwjgCADcUOgIABvEuAgAAP2QA= Date: Thu, 4 Sep 2014 23:27:48 +0000 Message-ID: References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> <53FB83FA.8010101@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [192.168.129.1] Content-Type: multipart/alternative; boundary="_000_D02E41DF131993jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7551 signatures=670511 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=6.10622663543836e-16 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 urlsuspect_oldscore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.993311949948012 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409040217 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/gQwoL3wyMuI8OXk0hTPCw-7r-QU Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 23:28:29 -0000 --_000_D02E41DF131993jonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I understand that OAuth can be altered from its basic flows to provide toke= ns for OpenID, and IdP could be bound to OAuth, and while this is all very = interesting it doesn't change much about the requirements discussion I thin= k we need to have: the one about what kinds of use cases we want to satisfy= and who the relying parties are in those cases. Once we understand that, w= e will understand what tools are applicable to these use cases - preferably= , not tools that need to be twisted into a different shape to be applicable= . It would helpful, in the enterprise SSO case, for us to understand what kin= ds of application servers a user might need to access, and what exactly tho= se application servers need to know about the user in order to accomplish t= heir function. Jon Peterson Neustar, Inc. From: Rifaat Shekh-Yusef > Date: Thursday, September 4, 2014 at 8:31 AM To: Jon Peterson = > Cc: Paul Kyzivat >, "si= pcore@ietf.org" > Subject: Re: [sipcore] A SIP OAuth use case On Wed, Sep 3, 2014 at 4:00 PM, Peterson, Jon > wrote: While I would echo Paul's thoughts below about the plausibility of service providers using this model to authorize recording, I also agree that third-party recording is an excellent example of a service architecture that requires an authorization mechanism like OAuth. An end user needs to authorize a third party to participate in the session under certain constraints, and coordinate the association between the third party and the VoIP service. This example also (rightly, in my opinion) conducts the majority of the flow in HTTP where it belongs. I agree with that. Many of the use cases under discussion in this thread, though, are of the form where there are really only two involved parties: an end user and a service provider. If you are my service provider, then in traditional SIP I share a secret with you that I use to REGISTER my devices. I don't think you need OAuth for that. If you assume that there is one server that provides all the services, then= you are right. But that is not the case all the time. I think that Dale articulated that c= learly in the following response: http://www.ietf.org/mail-archive/web/sipcore/current/msg06233.html I do understand that OAuth 2.0 is used in the wild for SSO, though I sympathize with Matt that the base flow shown in RFC6749 Sec 1.2 just doesn't map onto the requirements for SSO. I agree that the OAuth 2.0 "as is" does not address the SSO requirements. The SIP OAuth proposal is not just using OAuth 2.0 "as is", but it is exten= ding the framework to authenticate and provide a *user* specific token. Since Matt mentioned OpenID few times, I looked at the OpenID specification= . What they are doing there is that they defined a new token, called ID Token= , that is associated with the *user*; which is exactly what the SIP OAuth p= roposal is doing. http://openid.net/specs/openid-connect-core-1_0.html#IDToken My plan is to use the same terminology, ID Token, in the next version of th= e SIP OAuth document to clarify that, and to differentiate it from the acce= ss token. I think, though, we might usefully break uses cases here down by who the intended relying party is: - The user's own SIP service provider (my enterprise, my carrier, my OTT provider) - A third party that a user wants to authorize for a service (recording service... But anything else?) I would also append some use cases where the relying party: - Someone with no association with the user (caller ID sorts of cases) This last is where I've argued things like IdP might be relevant. EKR has a nice description for binding IdP to OAuth in his WebRTC Security = Architecture document here: https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10#appendix-A.2 We could use the same idea for SIP. Regards, Rifaat Are there any other high-level buckets of use cases here? Jon Peterson Neustar, Inc. On 8/25/14, 11:44 AM, "Paul Kyzivat" > wrote: >On 8/25/14 11:50 AM, Rifaat Shekh-Yusef wrote: >> Hi Matt, >> >> The use case and the solution provided assumes that the VoIP Provider >> makes the decision on when and what to record. >> While this is a valid use case, there are other use cases that allow the >> user to decide on when and what to record; take a look at RFC6341 for >> more info. >> http://datatracker.ietf.org/doc/rfc6341/ > >SIPREC supports numerous topologies. >It would support the one that Matt outlines as well as end-user >controlled ones. > >I found Matt's use case interesting. I think it would be nice if such >services were available in that form. But I have difficulty imagining >any of the VoIP providers I'm aware of supporting this model. My >impression is that this means that they are giving up a value added >revenue market, that they are loath to do. The most likely justification >I can imagine that they don't want to legal consequences of doing >recording. > > Thanks, > Paul > >> For these use cases, where the user is in control, you need to away to >> authenticate and control which users are allowed to record and the level >> of service provided for that specific user. >> This is where the solutions provided in section 3 or section 4 of the >> SIP OAuth proposal come into play. >> Obviously, in this case the authorization server is different from >> authorization server used to establish the trust relationship between >> the VoIP Provider and the CRS Provider. >> In this case, the authorization server must authenticate the user and >> provide his UA with an access token or a code that controls the user's >> access to the service. >> >> Regards, >> Rifaat >> >> >> >> On Sat, Aug 23, 2014 at 9:05 AM, Matt Ryan >> >> wrote: >> >> Included is the use case I spoke of before. My apologies for the >>delay. >> >> This is written as though it could be included in >> [draft-yusef-sipcore-sip-oauth] at section 6. >> >> >> 6. Examples >> >> 6.1. Example: Call Recording Service >> >> This example illustrates the use of SIP OAuth between three >> parties: A hosted VoIP service provider, a Call Recording Service >> provider, and a phone system end-user. In this example: >> - The phone system end-user is a customer of both the hosted VoIP >> provider and the Call Recording Service provider >> - The hosted VoIP service provider is a standard provider of hosted >> business-class VoIP telephone service using SIP >> - The Call Recording Service provider is a distinct entity from the >> hosted VoIP provider >> >> The Call Recording Service provides to customers both the call >> recording abilities and management of call recordings >> (configuration, sharing and distribution, retention, etc.). This >> service can accept and record RTP traffic, associate all RTP streams >> with a single call together, and store and catalog the recorded data >> for future searching and retrieval. The service also offers a web >> interface where customers may view and retrieve stored calls. >> Stored calls may range from simple person-to-person voice calls to >> multi-party conferences with a multitude of audio and video >> streams. In this example, customers are billed based on the amount >> of data they store, although other models are certainly possible. >> >> 6.1.1. OAuth 2.0 Roles >> >> In this example, each party assumes the following OAuth 2.0 roles as >> defined in [RFC6749] Section 1.1: >> - The end-user assumes the role of resource owner >> - The hosted VoIP service provider assumes the role of client >> - The Call Recording Service provider assumes the role of resource >> server as well as the role of authorization server >> >> 6.1.2. Description >> >> There are two parts to the example: Initial configuration and >> real-time recording authorization. >> >> Each section includes a simplified flow diagram for the purpose of >> describing the corresponding portion of the example. For the sake >> of brevity, certain parts of the OAuth dialog have been eliminated. >> Implements should refer to [RFC6749] for details on OAuth. >> >> 6.1.2.1 Initial Configuration >> >> +-------------+ +---------------+ +--------------+ >> | End-User | | VoIP Provider | | CRS Provider | >> | Web Browser | | Website | | | >> +-------------+ +---------------+ +--------------+ >> | | | >> | HTTP 1 | | >> | (Configure CRS) | | >> |------------------->| | >> | | | >> | HTTP 2 | | >> | (OAuth Redirect | | >> | to CRS Website) | | >> |<-------------------| | >> | | | >> | HTTP 3 | | >> | (Authorize SIP from VoIP provider | >> |----------------------------------------->| >> | | | >> | HTTP 4 | | >> | (OAuth Redirect back to VoIP portal) | >> |<-----------------------------------------| >> | | | >> | HTTP 5 | | >> |------------------->| | >> | | HTTP 6 | >> | | (Request Access and | >> | | refresh tokens) | >> | |-------------------->| >> | | | >> >> Some time after having signed up for both services, but prior to >> attempting to record any calls, the end-user logs into the web >> portal of the hosted VoIP provider with a web browser and configures >> their call recording service (HTTP 1). This configuration includes >> providing a URI where the call recording service may be reached, >> along with a set of API credentials, provided by the call recording >> service, which will allow the client to initiate an OAuth exchange. >> The end-user also configures the conditions under which call >> recordings should take place. For example, the end-user may request >> to record every multi-party (conference) call, or every call >> involving a specific set of users. The end-user may also specify >> other restrictions, such as restricting codec negotiation to G.711u >> for audio and H.264 for video in order to record the RTP streams. >> Once the end-user saves the configuration, the hosted VoIP provider >> web portal redirects the end-user's web browser to the call >> recording service website and a standard HTTP OAuth dialog begins >> (HTTP 2). The end-user authorizes the hosted VoIP provider to >> access (i.e. send SIP and RTP traffic to) the call recording >> service, for the purpose of recording calls, so long as the >> configured conditions are met (HTTP 3). The result of this >> interaction is that the hosted VoIP provider ends up receiving an >> OAuth access token and refresh token from the call recording service >> (HTTP 4, HTTP 5, HTTP 6). These tokens are saved in the end-user's >> hosted VoIP account database. >> >> 6.1.2.2 Real-time Recording Authorization >> >> +-------------+ +---------------+ +--------------+ >> | End-User | | VoIP Provider | | CRS Provider | >> | SIP Phone | | Website | | | >> +-------------+ +---------------+ +--------------+ >> | | | >> | SIP INVITE 1 | | >> |------------------->| | >> | | SIP INVITE 2 | >> | | (with access token) | >> | |--------------------->| >> | | | >> | | SIP 401 Unauthorized | >> | |<---------------------| >> | | | >> | | SIP INVITE 3 | >> | | (with refresh token) | >> | |--------------------->| >> | | | >> | | SIP 200 1 | >> | | (new access token) | >> | |<---------------------| >> | | | >> | | SIP INVITE 4 | >> | | (with access token) | >> | |--------------------->| >> | | | >> | | SIP 200 2 | >> | |<---------------------| >> | | | >> >> Independently of and after the initial configuration phase, the >> end-user makes a telephone call using the hosted VoIP provider (SIP >> INVITE 1). When this call takes place, the hosted VoIP provider >> looks to see whether it believes this call should be recorded. If >> so, at this point it would branch the call session to the call >> recording service, using SIP OAuth to pass the previously provided >> access token for authorization (SIP INVITE 2). Once the access >> token is validated by the call recording service (perhaps after >> first providing a new access token based on receipt of a valid >> refresh token), the call recording service will check the rights >> that were previously authorized and examine the SIP to determine >> whether it can accept the call. If so, it completes the >> establishment of the session and begins receiving and recording the >> RTP stream(s) (SIP 200 OK). The call recording service provider >> could also deny the request, either because the tokens are invalid >> or because the content of >> the SIP invite does not match the previously authorized >> conditions, in which case a SIP 403 would be returned by the call >> recording service provider and the call would not be recorded - >> however, the initial call branch would continue without >>interruption. >> >> Note: >> [RFC6749] specifies that when a client uses a refresh token to >> request a new access token, the response is HTTP 200 with the new >> access token and optionally a new refresh token included in the >> payload. In this example, a SIP 200 response (SIP 200 1) is sent >> which contains the new token(s). However, this could be confusing >> as SIP 200 is generally viewed as the acceptance of the INVITE, >> which is not what is happening in this case. Should SIP 200 be used >> for consistency, or should another mechanism be used? >> >> 6.1.3. Justification >> >> 6.1.3.1. Hosted VoIP Service Provider >> >> In this example, the hosted VoIP service provider can allow their >> customers to enable call recording in their VoIP service by >> selecting from any of a number of supported call recording service >> providers. This allows the hosted VoIP service provider to offer >> this feature to customers without requiring that the hosted VoIP >> service provider implement and support this feature themselves. >> >> 6.1.3.2. Call Recording Service Provider >> >> In this example, the Call Recording Service provider can focus on >> value and innovation in the area of recording calls and managing >> recorded calls without having to build a full-featured telephony >> offering. >> >> 6.1.3.3. Customer >> >> In this example, the customer has more flexibility in choosing a >> complete solution that meets all of the customer needs. The >> customer does not have to settle for a substandard call recording >> service offering in order to obtain other features they seek in a >> hosted VoIP provider, and vice versa. >> >> 6.1.4. Variants >> >> A simple variant of this example is one wherein one of the services >> (either the VoIP service or the call recording service) is managed >> directly by the end-user, but the other is not. For example, the >> end-user may wish to make use of an external hosted VoIP service >> provider, but may have business or legal reasons that forbid the >> end-user from allowing a third party to store and manage recorded >> calls. The end-user could choose to set up their own call recording >> service as described in this example, and use SIP OAuth to >> facilitate interaction between the hosted VoIP service and the >> end-user's own call recording service. >> >> 6.2. Other SIP OAuth examples >> >> Many other SIP-based services could leverage SIP OAuth to provide >> value-added service to an end-user of a hosted VoIP service >> provider. Some examples of these types of services are listed >>below. >> >> Voicemail service provider: The end-user configures their hosted >> VoIP service provider to manage voicemail through a separate >> voicemail service provider, which chooses whether to store voicemail >> based on existing quotas, Caller ID, etc. >> >> Conferencing service provider: A conferencing service may wish to >> bill customers in a more granular fashion, for example, based on the >> number of participants and attendees in a conference, the duration >> of conference, whether video was also included, which codecs were >> being used, etc. instead of a flat monthly rate. SIP OAuth would >> facilitate metered authorization for a client's use of the service, >> instead of all-or-nothing access. >> >> Call center service provider: A third party may provide ring groups >> or call queues for a hosted VoIP provider along with detailed >> reports and dashboards. The end-user uses OAuth over SIP to control >> who can log into which queues or ring groups, etc. >> >> >> >> -- >> Matt Ryan >> code slinger | zoomulus.com >> ietf at mvryan dot org >> >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_D02E41DF131993jonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

I understand that OAuth can be altered from its basic flows to provide= tokens for OpenID, and IdP could be bound to OAuth, and while this is all = very interesting it doesn't change much about the requirements discussion I= think we need to have: the one about what kinds of use cases we want to satisfy and who the relying parti= es are in those cases. Once we understand that, we will understand what too= ls are applicable to these use cases - preferably, not tools that need to b= e twisted into a different shape to be applicable.

It would helpful, in the enterprise SSO case, for us to understand wha= t kinds of application servers a user might need to access, and what exactl= y those application servers need to know about the user in order to accompl= ish their function.

Jon Peterson
Neustar, Inc.

From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Thursday, September 4, 2014 a= t 8:31 AM
To: Jon Peterson <jon.peterson@neustar.biz>
Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>, "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] A SIP OAuth = use case




On Wed, Sep 3, 2014 at 4:00 PM, Peterson, Jon <jon.peter= son@neustar.biz> wrote:

While I would echo Paul's thoughts below about the plausibility of service<= br> providers using this model to authorize recording, I also agree that
third-party recording is an excellent example of a service architecture
that requires an authorization mechanism like OAuth. An end user needs to authorize a third party to participate in the session under certain
constraints, and coordinate the association between the third party and
the VoIP service. This example also (rightly, in my opinion) conducts the majority of the flow in HTTP where it belongs.


I agree with that.

 
Many of the use cases under discussion in this thread, though, are of the form where there are really only two involved parties: an end user and a service provider. If you are my service provider, then in traditional SIP I share a secret with you that I use to REGISTER my devices. I don't think<= br> you need OAuth for that.

If you assume that there is one server that provides all the services,= then you are right.
But that is not the case all the time. I think that Dale articulated t= hat clearly in the following response:

 
I do understand that OAuth 2.0 is used in the
wild for SSO, though I sympathize with Matt that the base flow shown in
RFC6749 Sec 1.2 just doesn't map onto the requirements for SSO.


I agree that the OAuth 2.0 "as is" does not address the SSO = requirements.
The SIP OAuth proposal is not just using OAuth 2.0 "as is", = but it is extending the framework to authenticate and provide a *user* spec= ific token.

Since Matt mentioned OpenID few times, I looked at the OpenID specific= ation.
What they are doing there is that they defined a new token, called ID = Token, that is associated with the *user*; which is exactly what the SIP OA= uth proposal is doing.

My plan is to use the same terminology, ID Token, in the next version = of the SIP OAuth document to clarify that, and to differentiate it from the= access token.

 
I think, though, we might usefully break uses cases here down by who the intended relying party is:

- The user's own SIP service provider (my enterprise, my carrier, my OTT provider)
- A third party that a user wants to authorize for a service (recording
service... But anything else?)

I would also append some use cases where the relying party:

- Someone with no association with the user (caller ID sorts of cases)

This last is where I've argued things like IdP might be relevant.


EKR has a nice description for binding IdP to OAuth in his WebRTC Secu= rity Architecture document here:

We could use the same idea for SIP.


Regards,
 Rifaat


 
Are there any other high-level buckets of use cases here?

Jon Peterson
Neustar, Inc.

On 8/25/14, 11:44 AM, "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote:

>On 8/25/14 11:50 AM, Rifaat Shekh-Yusef wrote:
>> Hi Matt,
>>
>> The use case and the solution provided assumes that the VoIP Provi= der
>> makes the decision on when and what to record.
>> While this is a valid use case, there are other use cases that all= ow the
>> user to decide on when and what to record; take a look at RFC6341 = for
>> more info.
>> http://datatracker.ietf.org/doc/rfc6341/
>
>SIPREC supports numerous topologies.
>It would support the one that Matt outlines as well as end-user
>controlled ones.
>
>I found Matt's use case interesting. I think it would be nice if such >services were available in that form. But I have difficulty imagining >any of the VoIP providers I'm aware of supporting this model. My
>impression is that this means that they are giving up a value added
>revenue market, that they are loath to do. The most likely justificatio= n
>I can imagine that they don't want to legal consequences of doing
>recording.
>
>       Thanks,
>       Paul
>
>> For these use cases, where the user is in control, you need to awa= y to
>> authenticate and control which users are allowed to record and the= level
>> of service provided for that specific user.
>> This is where the solutions provided in section 3 or section 4 of = the
>> SIP OAuth proposal come into play.
>> Obviously, in this case the authorization server is different from=
>> authorization server used to establish the trust relationship betw= een
>> the VoIP Provider and the CRS Provider.
>> In this case, the authorization server must authenticate the user = and
>> provide his UA with an access token or a code that controls the us= er's
>> access to the service.
>>
>> Regards,
>>   Rifaat
>>
>>
>>
>> On Sat, Aug 23, 2014 at 9:05 AM, Matt Ryan <ietf@mvryan.org
>> <mailto:ie= tf@mvryan.org>> wrote:
>>
>>     Included is the use case I spoke of before.&nbs= p; My apologies for the
>>delay.
>>
>>     This is written as though it could be included = in
>>     [draft-yusef-sipcore-sip-oauth] at section 6. >>
>>
>>     6. Examples
>>
>>     6.1. Example: Call Recording Service
>>
>>     This example illustrates the use of SIP OAuth b= etween three
>>     parties:  A hosted VoIP service provider, = a Call Recording Service
>>     provider, and a phone system end-user.  In= this example:
>>     - The phone system end-user is a customer of bo= th the hosted VoIP
>>     provider and the Call Recording Service provide= r
>>     - The hosted VoIP service provider is a standar= d provider of hosted
>>     business-class VoIP telephone service using SIP=
>>     - The Call Recording Service provider is a dist= inct entity from the
>>     hosted VoIP provider
>>
>>     The Call Recording Service provides to customer= s both the call
>>     recording abilities and management of call reco= rdings
>>     (configuration, sharing and distribution, reten= tion, etc.).  This
>>     service can accept and record RTP traffic, asso= ciate all RTP streams
>>     with a single call together, and store and cata= log the recorded data
>>     for future searching and retrieval.  The s= ervice also offers a web
>>     interface where customers may view and retrieve= stored calls.
>>     Stored calls may range from simple person-to-pe= rson voice calls to
>>     multi-party conferences with a multitude of aud= io and video
>>     streams.  In this example, customers are b= illed based on the amount
>>     of data they store, although other models are c= ertainly possible.
>>
>>     6.1.1. OAuth 2.0 Roles
>>
>>     In this example, each party assumes the followi= ng OAuth 2.0 roles as
>>     defined in [RFC6749] Section 1.1:
>>     - The end-user assumes the role of resource own= er
>>     - The hosted VoIP service provider assumes the = role of client
>>     - The Call Recording Service provider assumes t= he role of resource
>>     server as well as the role of authorization ser= ver
>>
>>     6.1.2. Description
>>
>>     There are two parts to the example:  Initi= al configuration and
>>     real-time recording authorization.
>>
>>     Each section includes a simplified flow diagram= for the purpose of
>>     describing the corresponding portion of the exa= mple.  For the sake
>>     of brevity, certain parts of the OAuth dialog h= ave been eliminated.
>>     Implements should refer to [RFC6749] for detail= s on OAuth.
>>
>>     6.1.2.1 Initial Configuration
>>
>>        +-------------+    &n= bsp;+---------------+     +--------------+ >>        |  End-User   |  &n= bsp;  | VoIP Provider |     | CRS Provider |
>>        | Web Browser |     |&nb= sp;   Website    |     |      =         |
>>        +-------------+    &n= bsp;+---------------+     +--------------+ >>               |  &nbs= p;                 |    &= nbsp;                |
>>               | HTTP 1&nbs= p;            |        &n= bsp;            |
>>               | (Configure= CRS)    |               =      |
>>               |-----------= -------->|                 =    |
>>               |  &nbs= p;                 |    &= nbsp;                |
>>               | HTTP 2&nbs= p;            |        &n= bsp;            |
>>               | (OAuth Red= irect    |               =      |
>>               |  to C= RS Website)   |              &= nbsp;      |
>>               |<-------= ------------|                 =    |
>>               |  &nbs= p;                 |    &= nbsp;                |
>>               | HTTP 3&nbs= p;            |        &n= bsp;            |
>>               | (Authorize= SIP from VoIP provider        |
>>               |-----------= ------------------------------>|
>>               |  &nbs= p;                 |    &= nbsp;                |
>>               | HTTP 4&nbs= p;            |        &n= bsp;            |
>>               | (OAuth Red= irect back to VoIP portal)     |
>>               |<-------= ----------------------------------|
>>               |  &nbs= p;                 |    &= nbsp;                |
>>               | HTTP 5&nbs= p;            |        &n= bsp;            |
>>               |-----------= -------->|                 =    |
>>               |  &nbs= p;                 | HTTP 6  &= nbsp;           |
>>               |  &nbs= p;                 | (Request Acces= s and |
>>               |  &nbs= p;                 |  refresh = tokens)    |
>>               |  &nbs= p;                 |---------------= ----->|
>>               |  &nbs= p;                 |    &= nbsp;                |
>>
>>     Some time after having signed up for both servi= ces, but prior to
>>     attempting to record any calls, the end-user lo= gs into the web
>>     portal of the hosted VoIP provider with a web b= rowser and configures
>>     their call recording service (HTTP 1).  Th= is configuration includes
>>     providing a URI where the call recording servic= e may be reached,
>>     along with a set of API credentials, provided b= y the call recording
>>     service, which will allow the client to initiat= e an OAuth exchange.
>>     The end-user also configures the conditions und= er which call
>>     recordings should take place.  For example= , the end-user may request
>>     to record every multi-party (conference) call, = or every call
>>     involving a specific set of users.  The en= d-user may also specify
>>     other restrictions, such as restricting codec n= egotiation to G.711u
>>     for audio and H.264 for video in order to recor= d the RTP streams.
>>     Once the end-user saves the configuration, the = hosted VoIP provider
>>     web portal redirects the end-user's web browser= to the call
>>     recording service website and a standard HTTP O= Auth dialog begins
>>     (HTTP 2).  The end-user authorizes the hos= ted VoIP provider to
>>     access (i.e. send SIP and RTP traffic to) the c= all recording
>>     service, for the purpose of recording calls, so= long as the
>>     configured conditions are met (HTTP 3).  T= he result of this
>>     interaction is that the hosted VoIP provider en= ds up receiving an
>>     OAuth access token and refresh token from the c= all recording service
>>     (HTTP 4, HTTP 5, HTTP 6).  These tokens ar= e saved in the end-user's
>>     hosted VoIP account database.
>>
>>     6.1.2.2 Real-time Recording Authorization
>>
>>        +-------------+    &n= bsp;+---------------+      +--------------+<= br> >>        |  End-User   |  &n= bsp;  | VoIP Provider |      | CRS Provider |
>>        |  SIP Phone  |    =  |    Website    |      |  &nb= sp;           |
>>        +-------------+    &n= bsp;+---------------+      +--------------+<= br> >>               |  &nbs= p;                 |    &= nbsp;                 |
>>               | SIP INVITE= 1       |            &nb= sp;         |
>>               |-----------= -------->|                 =     |
>>               |  &nbs= p;                 | SIP INVITE 2&n= bsp;        |
>>               |  &nbs= p;                 | (with access t= oken)  |
>>               |  &nbs= p;                 |---------------= ------>|
>>               |  &nbs= p;                 |    &= nbsp;                 |
>>               |  &nbs= p;                 | SIP 401 Unauth= orized |
>>               |  &nbs= p;                 |<-----------= ----------|
>>               |  &nbs= p;                 |    &= nbsp;                 |
>>               |  &nbs= p;                 | SIP INVITE 3&n= bsp;        |
>>               |  &nbs= p;                 | (with refresh = token) |
>>               |  &nbs= p;                 |---------------= ------>|
>>               |  &nbs= p;                 |    &= nbsp;                 |
>>               |  &nbs= p;                 | SIP 200 1 = ;           |
>>               |  &nbs= p;                 | (new access to= ken)   |
>>               |  &nbs= p;                 |<-----------= ----------|
>>               |  &nbs= p;                 |    &= nbsp;                 |
>>               |  &nbs= p;                 | SIP INVITE 4&n= bsp;        |
>>               |  &nbs= p;                 | (with access t= oken)  |
>>               |  &nbs= p;                 |---------------= ------>|
>>               |  &nbs= p;                 |    &= nbsp;                 |
>>               |  &nbs= p;                 | SIP 200 2 = ;           |
>>               |  &nbs= p;                 |<-----------= ----------|
>>               |  &nbs= p;                 |    &= nbsp;                 |
>>
>>     Independently of and after the initial configur= ation phase, the
>>     end-user makes a telephone call using the hoste= d VoIP provider (SIP
>>     INVITE 1).  When this call takes place, th= e hosted VoIP provider
>>     looks to see whether it believes this call shou= ld be recorded.  If
>>     so, at this point it would branch the call sess= ion to the call
>>     recording service, using SIP OAuth to pass the = previously provided
>>     access token for authorization (SIP INVITE 2).&= nbsp; Once the access
>>     token is validated by the call recording servic= e (perhaps after
>>     first providing a new access token based on rec= eipt of a valid
>>     refresh token), the call recording service will= check the rights
>>     that were previously authorized and examine the= SIP to determine
>>     whether it can accept the call.  If so, it= completes the
>>     establishment of the session and begins receivi= ng and recording the
>>     RTP stream(s) (SIP 200 OK).  The call reco= rding service provider
>>     could also deny the request, either because the= tokens are invalid
>>     or because the content of
>>       the SIP invite does not match the previo= usly authorized
>>     conditions, in which case a SIP 403 would be re= turned by the call
>>     recording service provider and the call would n= ot be recorded -
>>     however, the initial call branch would continue= without
>>interruption.
>>
>>     Note:
>>     [RFC6749] specifies that when a client uses a r= efresh token to
>>     request a new access token, the response is HTT= P 200 with the new
>>     access token and optionally a new refresh token= included in the
>>     payload.  In this example, a SIP 200 respo= nse (SIP 200 1) is sent
>>     which contains the new token(s).  However,= this could be confusing
>>     as SIP 200 is generally viewed as the acceptanc= e of the INVITE,
>>     which is not what is happening in this case.&nb= sp; Should SIP 200 be used
>>     for consistency, or should another mechanism be= used?
>>
>>     6.1.3. Justification
>>
>>     6.1.3.1. Hosted VoIP Service Provider
>>
>>     In this example, the hosted VoIP service provid= er can allow their
>>     customers to enable call recording in their VoI= P service by
>>     selecting from any of a number of supported cal= l recording service
>>     providers.  This allows the hosted VoIP se= rvice provider to offer
>>     this feature to customers without requiring tha= t the hosted VoIP
>>     service provider implement and support this fea= ture themselves.
>>
>>     6.1.3.2. Call Recording Service Provider
>>
>>     In this example, the Call Recording Service pro= vider can focus on
>>     value and innovation in the area of recording c= alls and managing
>>     recorded calls without having to build a full-f= eatured telephony
>>     offering.
>>
>>     6.1.3.3. Customer
>>
>>     In this example, the customer has more flexibil= ity in choosing a
>>     complete solution that meets all of the custome= r needs.  The
>>     customer does not have to settle for a substand= ard call recording
>>     service offering in order to obtain other featu= res they seek in a
>>     hosted VoIP provider, and vice versa.
>>
>>     6.1.4. Variants
>>
>>     A simple variant of this example is one wherein= one of the services
>>     (either the VoIP service or the call recording = service) is managed
>>     directly by the end-user, but the other is not.=   For example, the
>>     end-user may wish to make use of an external ho= sted VoIP service
>>     provider, but may have business or legal reason= s that forbid the
>>     end-user from allowing a third party to store a= nd manage recorded
>>     calls.  The end-user could choose to set u= p their own call recording
>>     service as described in this example, and use S= IP OAuth to
>>     facilitate interaction between the hosted VoIP = service and the
>>     end-user's own call recording service.
>>
>>     6.2. Other SIP OAuth examples
>>
>>     Many other SIP-based services could leverage SI= P OAuth to provide
>>     value-added service to an end-user of a hosted = VoIP service
>>     provider.  Some examples of these types of= services are listed
>>below.
>>
>>     Voicemail service provider:  The end-user = configures their hosted
>>     VoIP service provider to manage voicemail throu= gh a separate
>>     voicemail service provider, which chooses wheth= er to store voicemail
>>     based on existing quotas, Caller ID, etc.
>>
>>     Conferencing service provider:  A conferen= cing service may wish to
>>     bill customers in a more granular fashion, for = example, based on the
>>     number of participants and attendees in a confe= rence, the duration
>>     of conference, whether video was also included,= which codecs were
>>     being used, etc. instead of a flat monthly rate= .  SIP OAuth would
>>     facilitate metered authorization for a client's= use of the service,
>>     instead of all-or-nothing access.
>>
>>     Call center service provider:  A third par= ty may provide ring groups
>>     or call queues for a hosted VoIP provider along= with detailed
>>     reports and dashboards.  The end-user uses= OAuth over SIP to control
>>     who can log into which queues or ring groups, e= tc.
>>
>>
>>
>>     --
>>     Matt Ryan
>>     code slinger | zoomulus.com <http://zoomulus.com>
>>     ietf at mvryan dot org
>>
>>
>>
>>
>>     _______________________________________________=
>>     sipcore mailing list
>>     sipcore@ietf.org <mailto:sipcore@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/sipcore<= /a>
>>
>>
>>
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf= .org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>
>_______________________________________________
>sipcore mailing list
>sipcore@ietf.org<= /a>
>https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

 --_000_D02E41DF131993jonpetersonneustarbiz_-- From nobody Mon Sep 8 13:40:41 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D831A0378 for ; Mon, 8 Sep 2014 13:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caudokqVfrwu for ; Mon, 8 Sep 2014 13:40:37 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5241A0376 for ; Mon, 8 Sep 2014 13:40:37 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s88KeaXK082931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Mon, 8 Sep 2014 15:40:36 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <540E1444.4020205@nostrum.com> Date: Mon, 08 Sep 2014 15:40:36 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "sipcore@ietf.org" References: <20140908203132.10649.77126.idtracker@ietfa.amsl.com> In-Reply-To: <20140908203132.10649.77126.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140908203132.10649.77126.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010206030800070107010006" Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/BwBqSFZkyEOQdayPMznxUlqgEWU Subject: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 20:40:39 -0000 This is a multi-part message in MIME format. --------------010206030800070107010006 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit -------- Forwarded Message -------- Subject: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01.txt Date: Mon, 08 Sep 2014 13:31:32 -0700 From: internet-drafts@ietf.org To: Robert Sparks , Robert Sparks A new version of I-D, draft-sparks-sipcore-refer-explicit-subscription-01.txt has been successfully submitted by Robert Sparks and posted to the IETF repository. Name: draft-sparks-sipcore-refer-explicit-subscription Revision: 01 Title: Explicit Subscriptions for the REFER Method Document date: 2014-09-08 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-explicit-subscription-01.txt Status: https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-explicit-subscription/ Htmlized: http://tools.ietf.org/html/draft-sparks-sipcore-refer-explicit-subscription-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-explicit-subscription-01 Abstract: The SIP REFER request, as defined by RFC3515, triggers an implicit SIP-Specific Event Notification framework subscription. Conflating the start of the subscription with handling the REFER request makes negotiating SUBSCRIBE extensions impossible, and complicates avoiding SIP dialog sharing. This document defines an extension to REFER to remove the implicit subscription and replace it with an explicit one. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------010206030800070107010006 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


-------- Forwarded Message --------
Subject: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01.txt
Date: Mon, 08 Sep 2014 13:31:32 -0700
From: internet-drafts@ietf.org
To: Robert Sparks <rjsparks@nostrum.com>, Robert Sparks <rjsparks@nostrum.com> 


A new version of I-D, draft-sparks-sipcore-refer-explicit-subscription-01.txt
has been successfully submitted by Robert Sparks and posted to the
IETF repository.

Name:		draft-sparks-sipcore-refer-explicit-subscription
Revision:	01
Title:		Explicit Subscriptions for the REFER Method
Document date:	2014-09-08
Group:		Individual Submission
Pages:		11
URL:            http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-explicit-subscription-01.txt
Status:         https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-explicit-subscription/
Htmlized:       http://tools.ietf.org/html/draft-sparks-sipcore-refer-explicit-subscription-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-explicit-subscription-01

Abstract:
   The SIP REFER request, as defined by RFC3515, triggers an implicit
   SIP-Specific Event Notification framework subscription.  Conflating
   the start of the subscription with handling the REFER request makes
   negotiating SUBSCRIBE extensions impossible, and complicates avoiding
   SIP dialog sharing.  This document defines an extension to REFER to
   remove the implicit subscription and replace it with an explicit one.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--------------010206030800070107010006-- From nobody Tue Sep 9 01:41:48 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597381A8960 for ; Tue, 9 Sep 2014 01:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEZo7l2ZDz6m for ; Tue, 9 Sep 2014 01:41:44 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1A081A8884 for ; Tue, 9 Sep 2014 01:41:42 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-6c-540ebd443fae Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2F.34.21432.44DBE045; Tue, 9 Sep 2014 10:41:40 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.77]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0174.001; Tue, 9 Sep 2014 10:41:40 +0200 From: Ivo Sedlacek To: Robert Sparks , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01.txt Thread-Index: AQHPy6UpGEPDOphAW0m9JlEsn2rgiJv4e3OA Date: Tue, 9 Sep 2014 08:41:39 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061011272E59C@ESESSMB301.ericsson.se> References: <20140908203132.10649.77126.idtracker@ietfa.amsl.com> <540E1444.4020205@nostrum.com> In-Reply-To: <540E1444.4020205@nostrum.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B310790061011272E59CESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvja7LXr4Qg0PfjC2uzWlks/j6YxOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJWx/dYcloKexUwV+37tYmlg3DObqYuRk0NC wETi/fxuKFtM4sK99WxdjFwcQgJHGSW+vfgM5SxilNi7fxorSBWbgJ7ExC1HwGwRgUCJhZOW sIDYwgJFEh8726DixRJ79s9l7mLkALKNJF6t8gMxWQRUJO6fygWp4BXwlfj8cw0ziC0kkCTx tK8ZrJNTQFviWtsRdhCbUUBW4uqfXkYQm1lAXOLWk/lQdwpILNlznhnCFpV4+fgfK4StKHF1 +nImiPp8iVt35jBB7BKUODnzCcsERpFZSEbNQlI2C0nZLKBLmQU0Jdbv0ocoUZSY0v2QHcLW kGidM5cdWXwBI/sqRtHi1OKk3HQjI73Uoszk4uL8PL281JJNjMC4Orjlt8EOxpfPHQ8xCnAw KvHwKsTzhQixJpYVV+YeYpTmYFES5114bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkbl A10rc984Pd2+fa3ertYE3xC+KUteHY2Z+kroVcuiWy28pS/3Tck0+JOnZXLmKG/45R+uptqd cl3eBTIfr7NcEXq7LPVZCx+3zxPtk/cULnHILQoveblkiqzkBtfTckoJThNj7SYe49/GaNd8 ZGnfrzMRUevExOaemFG81sXs0rcMZum1pYuVWIozEg21mIuKEwE1lmjEjAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/luD5BNcdCdA4d7FjRUqWkxZdkrs Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 08:41:46 -0000 --_000_39B5E4D390E9BD4890E2B310790061011272E59CESESSMB301erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gUm9iZXJ0LA0KDQpJIHJldmlld2VkIHRoZSBwYXBlciBhbmQgZm91bmQgdGhlIGZvbGxv d2luZzoNCg0KSVNTVUUgMTogdGhlIGRyYWZ0IHN0YXRlczoNCi0tLS0tLS0tLS0tLS0tLS0tLS0N ClNlbmRpbmcgYSBSRUZFUiB3aXRoaW4gYSBkaWFsb2cgZXN0YWJsaXNoZWQNCiAgIGJ5IGFuIElO VklURSByZXN1bHRzIGluIGRpYWxvZyByZXVzZSBhbmQgdGhlIGFzc29jaWF0ZWQgcHJvYmxlbXMN CiAgIGRlc2NyaWJlZCBpbiBbUkZDNTA1NzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1 MDU3Pl0uDQotLS0tLS0tLS0tLS0tLS0tLS0tDQpIb3dldmVyLCBzZW5kaW5nIG9mIHRoZSBSRUZF UiBhbG9uZSBkb2VzIG5vdCByZXN1bHQgdG8gZGlhbG9nIHJldXNlLiBUaGUgcmV1c2UgaGFwcGVu cyBvbmx5IGlmIHRoZSByZWZlciBzdWJzY3JpcHRpb24gaXMgY3JlYXRlZCAod2hpY2ggaXMgbm90 IGFsd2F5cyB0aGUgY2FzZSkuDQoNClBST1BPU0FMIDE6IHVzZSB0aGUgZm9sbG93aW5nIHdvcmRp bmc6DQotLS0tLS0tLS0tLS0tLS0tLS0tDQpBY2NlcHRhbmNlIG9mIGEgUkVGRVIgcmVxdWVzdCBy ZWNlaXZlZCB3aXRoaW4gYSBkaWFsb2cgZXN0YWJsaXNoZWQNCiAgIGJ5IGFuIElOVklURSBhbmQg Y3JlYXRpb24gb2YgcmVmZXIgc3Vic2NyaXB0aW9uIHJlc3VsdHMgaW4gZGlhbG9nIHJldXNlIGFu ZCB0aGUgYXNzb2NpYXRlZCBwcm9ibGVtcw0KICAgZGVzY3JpYmVkIGluIFtSRkM1MDU3PGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUwNTc+XS4NCi0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K DQpJU1NVRSAyOiB0aGUgZHJhZnQgc3RhdGVzOg0KLS0tLS0tLS0tLS0NCkNhbGwNCiAgIHRyYW5z ZmVyLCBhcyBkZWZpbmVkIGluIFtSRkM1NTg5PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzU1ODk+XSwgdGh1cyByZXF1aXJlcyBzZW5kaW5nIGEgUkVGRVINCiAgIHJlcXVlc3Qgb24gYSBu ZXcgZGlhbG9nLCBhc3NvY2lhdGluZyBpdCB3aXRoIGFuIGV4aXN0aW5nIGRpYWxvZyB1c2luZw0K ICAgdGhlICdUYXJnZXQtRGlhbG9nJyBtZWNoYW5pc20gZGVmaW5lZCBpbiBbUkZDNDUzODxodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NTM4Pl0uDQotLS0tLS0tLS0tLQ0KSG93ZXZlciwg UkZDNTU4OSBvbmx5IHJlY29tbWVuZHMgaXQsIG5vdCByZXF1aXJlcyBpdC4gUkZDNTU4OSBzdGF0 ZXM6DQotLS0tLS0tLS0tLQ0KICAgQXMgYSByZXN1bHQsIGlmIHRoZSBUcmFuc2ZlcmVlIHN1cHBv cnRzIHRoZSB0YXJnZXQtZGlhbG9nIGV4dGVuc2lvbg0KICAgYW5kIHRoZSBUcmFuc2Zlcm9yIGtu b3dzIHRoZSBDb250YWN0IFVSSSBpcyByb3V0YWJsZSBvdXRzaWRlIHRoZQ0KICAgZGlhbG9nLCB0 aGUgUkVGRVIgU0hPVUxEIGJlIHNlbnQgaW4gYSBuZXcgZGlhbG9nLg0KLS0tLS0tLS0tLS0NCg0K UFJPUE9TQUwgMjogdXNlIHRoZSBmb2xsb3dpbmcgd29yZGluZzoNCi0tLS0tLS0tLS0tLS0tLS0t LS0NCkNhbGwNCiAgIHRyYW5zZmVyLCBhcyBkZWZpbmVkIGluIFtSRkM1NTg5PGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzU1ODk+XSwgdGh1cyByZWNvbW1lbmRzIHNlbmRpbmcgYSBSRUZF Ug0KICAgcmVxdWVzdCBvbiBhIG5ldyBkaWFsb2csIGFzc29jaWF0aW5nIGl0IHdpdGggYW4gZXhp c3RpbmcgZGlhbG9nIHVzaW5nDQogICB0aGUgJ1RhcmdldC1EaWFsb2cnIG1lY2hhbmlzbSBkZWZp bmVkIGluIFtSRkM0NTM4PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ1Mzg+XS4NCi0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KSVNTVUUgMzogVGhlcmUgYXJlIHNpdHVhdGlvbnMgd2hlbiBu ZWl0aGVyIFVBUyBub3IgVUFDIHdhbnQgdGhlIHJlZmVyIHN1YnNjcmlwdGlvbiAtIHNlZSBSRkM0 NDg4LiBIb3dldmVyLCB0aGUgZHJhZnQgbWFuZGF0ZXMgdGhlIFVBUyB0byBiZSByZWFkeSB0byBj cmVhdGUgdGhlIHN1YnNjcmlwdGlvbiBldmVuIGlmIG5laXRoZXIgVUFDIG5vciBVQVMgYXJlIGlu dGVyZXN0ZWQgaW4gaXQuIFRoYXQncyB1bm5lY2Vzc2FyeS4NCg0KUFJPUE9TQUwgMzogSWYgU3Vw cG9ydGVkIG9yIFJlcXVpcmUgaGVhZGVyIGZpZWxkIHdpdGggbm9yZWZlcnN1YiBvcHRpb24gdGFn IGlzIGluZGljYXRlZCBpbiB0aGUgUkVGRVIgcmVxdWVzdCwgdGhlIFVBUyBkb2VzIG5vdCBpbmNs dWRlIHRoZSBSZWZlci1FdmVudHMtQXQgaW4gMnh4IHJlc3BvbnNlIHRvIFJFRkVSIHJlcXVlc3Qu DQoNCklTU1VFIDQ6IHRoZSBkcmFmdCBzdGF0ZXM6DQotLS0tLS0tLS0tLQ0KDQpBIFVBIE1VU1Qg Tk9UIGluY2x1ZGUgdGhlICdleHBsaWNpdHN1Yicgb3B0aW9uIHRhZw0KDQogICBpbiB0aGUgUmVx dWlyZSBoZWFkZXIgZmllbGQgb2YgYW55IFNJUCByZXNwb25zZSBvdGhlciB0aGFuIGEgNDIxDQoN CiAgIHJlc3BvbnNlIHRvIGEgUkVGRVIgcmVxdWVzdC4NCi0tLS0tLS0tLS0tDQotIHRoaXMgY29u ZmxpY3RzIHdpdGggUkZDMzI2MSBzdGF0aW5nOg0KLS0tLS0tLS0tLS0NCiAgIEFueSBleHRlbnNp b25zIGFwcGxpZWQgdG8gYSBub24tNDIxIHJlc3BvbnNlIE1VU1QgYmUgbGlzdGVkIGluIGENCiAg IFJlcXVpcmUgaGVhZGVyIGZpZWxkIGluY2x1ZGVkIGluIHRoZSByZXNwb25zZS4NCi0tLS0tLS0t LS0tDQpJLmUuIFJlcXVpcmU6IGV4cGxpY2l0c3ViIHNob3VsZCBiZSBhbHNvIGFsbG93ZWQgYXQg bGVhc3QgaW4gMnh4IHJlc3BvbnNlcyB0byBSRUZFUiByZXF1ZXN0Lg0KDQpQUk9QT1NBTCA0OiB1 c2UgdGhlIGZvbGxvd2luZyB3b3JkaW5nOg0KLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpBIFVBIE1V U1QgTk9UIGluY2x1ZGUgdGhlICdleHBsaWNpdHN1Yicgb3B0aW9uIHRhZw0KDQogICBpbiB0aGUg UmVxdWlyZSBoZWFkZXIgZmllbGQgb2YgYW55IFNJUCByZXNwb25zZSBvdGhlciB0aGFuIGENCg0K ICAgcmVzcG9uc2UgdG8gYSBSRUZFUiByZXF1ZXN0Lg0KLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpL aW5kIHJlZ2FyZHMNCg0KSXZvIFNlZGxhY2VrDQoNClRoaXMgQ29tbXVuaWNhdGlvbiBpcyBDb25m aWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2Yg dGhlIHRlcm1zIHNldCBvdXQgYXQgd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyPGh0 dHA6Ly93d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXI+DQpGcm9tOiBzaXBjb3JlIFtt YWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFNwYXJr cw0KU2VudDogOC4gesOhxZnDrSAyMDE0IDIyOjQxDQpUbzogc2lwY29yZUBpZXRmLm9yZw0KU3Vi amVjdDogW3NpcGNvcmVdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1z cGFya3Mtc2lwY29yZS1yZWZlci1leHBsaWNpdC1zdWJzY3JpcHRpb24tMDEudHh0DQoNCg0KDQoN Ci0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQpTdWJqZWN0Og0KDQpOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWV4cGxpY2l0 LXN1YnNjcmlwdGlvbi0wMS50eHQNCg0KRGF0ZToNCg0KTW9uLCAwOCBTZXAgMjAxNCAxMzozMToz MiAtMDcwMA0KDQpGcm9tOg0KDQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZz4NCg0KVG86DQoNClJvYmVydCBTcGFya3MgPHJqc3BhcmtzQG5v c3RydW0uY29tPjxtYWlsdG86cmpzcGFya3NAbm9zdHJ1bS5jb20+LCBSb2JlcnQgU3BhcmtzIDxy anNwYXJrc0Bub3N0cnVtLmNvbT48bWFpbHRvOnJqc3BhcmtzQG5vc3RydW0uY29tPg0KDQoNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWV4cGxpY2l0 LXN1YnNjcmlwdGlvbi0wMS50eHQNCg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBSb2JlcnQgU3BhcmtzIGFuZCBwb3N0ZWQgdG8gdGhlDQoNCklFVEYgcmVwb3NpdG9yeS4NCg0K DQoNCk5hbWU6ICAgICAgICAgIGRyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWV4cGxpY2l0LXN1 YnNjcmlwdGlvbg0KDQpSZXZpc2lvbjogICAgICAwMQ0KDQpUaXRsZTogICAgICAgICBFeHBsaWNp dCBTdWJzY3JpcHRpb25zIGZvciB0aGUgUkVGRVIgTWV0aG9kDQoNCkRvY3VtZW50IGRhdGU6IDIw MTQtMDktMDgNCg0KR3JvdXA6ICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQoNClBhZ2Vz OiAgICAgICAgIDExDQoNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1zcGFya3Mtc2lwY29yZS1yZWZlci1leHBsaWNpdC1zdWJzY3JpcHRp b24tMDEudHh0DQoNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1zcGFya3Mtc2lwY29yZS1yZWZlci1leHBsaWNpdC1zdWJzY3JpcHRpb24vDQoN Ckh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zcGFya3Mt c2lwY29yZS1yZWZlci1leHBsaWNpdC1zdWJzY3JpcHRpb24tMDENCg0KRGlmZjogICAgICAgICAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXNwYXJrcy1zaXBjb3JlLXJl ZmVyLWV4cGxpY2l0LXN1YnNjcmlwdGlvbi0wMQ0KDQoNCg0KQWJzdHJhY3Q6DQoNCiAgIFRoZSBT SVAgUkVGRVIgcmVxdWVzdCwgYXMgZGVmaW5lZCBieSBSRkMzNTE1LCB0cmlnZ2VycyBhbiBpbXBs aWNpdA0KDQogICBTSVAtU3BlY2lmaWMgRXZlbnQgTm90aWZpY2F0aW9uIGZyYW1ld29yayBzdWJz Y3JpcHRpb24uICBDb25mbGF0aW5nDQoNCiAgIHRoZSBzdGFydCBvZiB0aGUgc3Vic2NyaXB0aW9u IHdpdGggaGFuZGxpbmcgdGhlIFJFRkVSIHJlcXVlc3QgbWFrZXMNCg0KICAgbmVnb3RpYXRpbmcg U1VCU0NSSUJFIGV4dGVuc2lvbnMgaW1wb3NzaWJsZSwgYW5kIGNvbXBsaWNhdGVzIGF2b2lkaW5n DQoNCiAgIFNJUCBkaWFsb2cgc2hhcmluZy4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiBleHRl bnNpb24gdG8gUkVGRVIgdG8NCg0KICAgcmVtb3ZlIHRoZSBpbXBsaWNpdCBzdWJzY3JpcHRpb24g YW5kIHJlcGxhY2UgaXQgd2l0aCBhbiBleHBsaWNpdCBvbmUuDQoNCg0KDQoNCg0KDQoNCg0KDQpQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZiBzdWJtaXNzaW9uDQoNCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRh cmlhdA0KDQoNCg0KDQo= --_000_39B5E4D390E9BD4890E2B310790061011272E59CESESSMB301erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s b3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6I0Mw NTA0RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0i d2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPkhlbGxvIFJvYmVydCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiNDMDUwNEQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+SSByZXZpZXdlZCB0 aGUgcGFwZXIgYW5kIGZvdW5kIHRoZSBmb2xsb3dpbmc6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1 MDREIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPklTU1VFIDE6IHRoZSBkcmFm dCBzdGF0ZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj4tLS0tLS0tLS0tLS0tLS0tLS0t PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6I0MwNTA0RCI+U2VuZGluZyBhIFJFRkVSIHdpdGhpbiBhIGRpYWxvZyBlc3RhYmxpc2hlZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiNDMDUwNEQiPiZuYnNwOyZuYnNwOyBieSBhbiBJTlZJVEUgcmVzdWx0cyBpbiBkaWFsb2cgcmV1 c2UgYW5kIHRoZSBhc3NvY2lhdGVkIHByb2JsZW1zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6I0MwNTA0RCI+Jm5ic3A7Jm5ic3A7IGRl c2NyaWJlZCBpbiBbPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTA1NyIg dGl0bGU9IiZxdW90O011bHRpcGxlIERpYWxvZyBVc2FnZXMgaW4gdGhlIFNlc3Npb24gSW5pdGlh dGlvbiBQcm90b2NvbCZxdW90OyI+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMDUwNEQiPlJGQzUwNTc8 L3NwYW4+PC9hPl0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj4tLS0tLS0tLS0tLS0tLS0t LS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj5Ib3dldmVyLCBzZW5kaW5nIG9mIHRoZSBS RUZFUiBhbG9uZSBkb2VzIG5vdCByZXN1bHQgdG8gZGlhbG9nIHJldXNlLiBUaGUgcmV1c2UgaGFw cGVucyBvbmx5IGlmIHRoZSByZWZlciBzdWJzY3JpcHRpb24gaXMgY3JlYXRlZCAod2hpY2ggaXMg bm90IGFsd2F5cyB0aGUgY2FzZSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPlBST1BPU0FMIDE6IHVzZSB0aGUgZm9sbG93aW5n IHdvcmRpbmc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj4tLS0tLS0tLS0tLS0tLS0tLS0t PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6I0MwNTA0RCI+QWNjZXB0YW5jZSBvZiBhIFJFRkVSIHJlcXVlc3QgcmVjZWl2ZWQgd2l0aGlu IGEgZGlhbG9nIGVzdGFibGlzaGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6I0MwNTA0RCI+Jm5ic3A7Jm5ic3A7IGJ5IGFuIElOVklU RSBhbmQgY3JlYXRpb24gb2YgcmVmZXIgc3Vic2NyaXB0aW9uIHJlc3VsdHMgaW4gZGlhbG9nIHJl dXNlIGFuZCB0aGUgYXNzb2NpYXRlZCBwcm9ibGVtczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiNDMDUwNEQiPiZuYnNwOyZuYnNwOyBk ZXNjcmliZWQgaW4gWzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUwNTci IHRpdGxlPSImcXVvdDtNdWx0aXBsZSBEaWFsb2cgVXNhZ2VzIGluIHRoZSBTZXNzaW9uIEluaXRp YXRpb24gUHJvdG9jb2wmcXVvdDsiPjxzcGFuIHN0eWxlPSJjb2xvcjojQzA1MDREIj5SRkM1MDU3 PC9zcGFuPjwvYT5dLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+LS0tLS0tLS0tLS0tLS0t LS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojQzA1MDREIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPklTU1VFIDI6IHRo ZSBkcmFmdCBzdGF0ZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj4tLS0tLS0tLS0tLTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiNDMDUwNEQiPkNhbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojQzA1MDREIj4mbmJzcDsmbmJzcDsgdHJhbnNmZXIsIGFzIGRlZmlu ZWQgaW4gWzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU1ODkiIHRpdGxl PSImcXVvdDtTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkgQ2FsbCBDb250cm9sIC0g VHJhbnNmZXImcXVvdDsiPjxzcGFuIHN0eWxlPSJjb2xvcjojQzA1MDREIj5SRkM1NTg5PC9zcGFu PjwvYT5dLA0KIHRodXMgcmVxdWlyZXMgc2VuZGluZyBhIFJFRkVSPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6I0MwNTA0RCI+Jm5ic3A7 Jm5ic3A7IHJlcXVlc3Qgb24gYSBuZXcgZGlhbG9nLCBhc3NvY2lhdGluZyBpdCB3aXRoIGFuIGV4 aXN0aW5nIGRpYWxvZyB1c2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiNDMDUwNEQiPiZuYnNwOyZuYnNwOyB0aGUgJ1RhcmdldC1E aWFsb2cnIG1lY2hhbmlzbSBkZWZpbmVkIGluIFs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM0NTM4IiB0aXRsZT0iJnF1b3Q7UmVxdWVzdCBBdXRob3JpemF0aW9uIHRocm91 Z2ggRGlhbG9nIElkZW50aWZpY2F0aW9uIGluIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9j b2wgKFNJUCkmcXVvdDsiPjxzcGFuIHN0eWxlPSJjb2xvcjojQzA1MDREIj5SRkM0NTM4PC9zcGFu PjwvYT5dLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+LS0tLS0tLS0tLS08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiNDMDUwNEQiPkhvd2V2ZXIsIFJGQzU1ODkgb25seSByZWNvbW1lbmRzIGl0LCBu b3QgcmVxdWlyZXMgaXQuIFJGQzU1ODkgc3RhdGVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0 RCI+LS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojQzA1MDREIj4mbmJzcDsmbmJzcDsgQXMgYSByZXN1bHQsIGlmIHRo ZSBUcmFuc2ZlcmVlIHN1cHBvcnRzIHRoZSB0YXJnZXQtZGlhbG9nIGV4dGVuc2lvbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiNDMDUw NEQiPiZuYnNwOyAmbmJzcDthbmQgdGhlIFRyYW5zZmVyb3Iga25vd3MgdGhlIENvbnRhY3QgVVJJ IGlzIHJvdXRhYmxlIG91dHNpZGUgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6I0MwNTA0RCI+Jm5ic3A7Jm5ic3A7IGRpYWxvZywg dGhlIFJFRkVSIFNIT1VMRCBiZSBzZW50IGluIGEgbmV3IGRpYWxvZy48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUw NEQiPi0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiNDMDUwNEQiPlBST1BPU0FMIDI6IHVzZSB0aGUgZm9sbG93aW5nIHdvcmRp bmc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj4tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6I0Mw NTA0RCI+Q2FsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiNDMDUwNEQiPiZuYnNwOyZuYnNwOyB0cmFuc2ZlciwgYXMgZGVmaW5lZCBp biBbPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTU4OSIgdGl0bGU9IiZx dW90O1Nlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBDYWxsIENvbnRyb2wgLSBUcmFu c2ZlciZxdW90OyI+PHNwYW4gc3R5bGU9ImNvbG9yOiNDMDUwNEQiPlJGQzU1ODk8L3NwYW4+PC9h Pl0sDQogdGh1cyByZWNvbW1lbmRzIHNlbmRpbmcgYSBSRUZFUjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiNDMDUwNEQiPiZuYnNwOyZu YnNwOyByZXF1ZXN0IG9uIGEgbmV3IGRpYWxvZywgYXNzb2NpYXRpbmcgaXQgd2l0aCBhbiBleGlz dGluZyBkaWFsb2cgdXNpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojQzA1MDREIj4mbmJzcDsmbmJzcDsgdGhlICdUYXJnZXQtRGlh bG9nJyBtZWNoYW5pc20gZGVmaW5lZCBpbiBbPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNDUzOCIgdGl0bGU9IiZxdW90O1JlcXVlc3QgQXV0aG9yaXphdGlvbiB0aHJvdWdo IERpYWxvZyBJZGVudGlmaWNhdGlvbiBpbiB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29s IChTSVApJnF1b3Q7Ij48c3BhbiBzdHlsZT0iY29sb3I6I0MwNTA0RCI+UkZDNDUzODwvc3Bhbj48 L2E+XS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPi0tLS0tLS0tLS0tLS0tLS0tLS08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0 RCI+SVNTVUUgMzogVGhlcmUgYXJlIHNpdHVhdGlvbnMgd2hlbiBuZWl0aGVyIFVBUyBub3IgVUFD IHdhbnQgdGhlIHJlZmVyIHN1YnNjcmlwdGlvbiAtIHNlZSBSRkM0NDg4LiBIb3dldmVyLCB0aGUg ZHJhZnQgbWFuZGF0ZXMgdGhlIFVBUyB0byBiZSByZWFkeSB0byBjcmVhdGUgdGhlDQogc3Vic2Ny aXB0aW9uIGV2ZW4gaWYgbmVpdGhlciBVQUMgbm9yIFVBUyBhcmUgaW50ZXJlc3RlZCBpbiBpdC4g VGhhdCdzIHVubmVjZXNzYXJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj5QUk9QT1NBTCAzOiBJZiBTdXBwb3J0ZWQgb3IgUmVx dWlyZSBoZWFkZXIgZmllbGQgd2l0aCBub3JlZmVyc3ViIG9wdGlvbiB0YWcgaXMgaW5kaWNhdGVk IGluIHRoZSBSRUZFUiByZXF1ZXN0LCB0aGUgVUFTIGRvZXMgbm90IGluY2x1ZGUgdGhlIFJlZmVy LUV2ZW50cy1BdCBpbg0KIDJ4eCByZXNwb25zZSB0byBSRUZFUiByZXF1ZXN0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6I0MwNTA0RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj5JU1NV RSA0OiB0aGUgZHJhZnQgc3RhdGVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+LS0tLS0t LS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojQzA1 MDREIj5BIFVBIE1VU1QgTk9UIGluY2x1ZGUgdGhlICdleHBsaWNpdHN1Yicgb3B0aW9uIHRhZzxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6I0MwNTA0RCI+ Jm5ic3A7Jm5ic3A7IGluIHRoZSBSZXF1aXJlIGhlYWRlciBmaWVsZCBvZiBhbnkgU0lQIHJlc3Bv bnNlIG90aGVyIHRoYW4gYSA0MjE8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImNvbG9yOiNDMDUwNEQiPiZuYnNwOyZuYnNwOyByZXNwb25zZSB0byBhIFJFRkVSIHJl cXVlc3QuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPi0tLS0tLS0tLS0tPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojQzA1MDREIj4tIHRoaXMgY29uZmxpY3RzIHdpdGggUkZDMzI2MSBzdGF0aW5n OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+LS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiNDMDUwNEQiPiZuYnNwOyZuYnNwOyBBbnkgZXh0ZW5zaW9ucyBhcHBsaWVkIHRvIGEgbm9u LTQyMSByZXNwb25zZSBNVVNUIGJlIGxpc3RlZCBpbiBhPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1 MDREIj4mbmJzcDsmbmJzcDsgUmVxdWlyZSBoZWFkZXIgZmllbGQgaW5jbHVkZWQgaW4gdGhlIHJl c3BvbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+LS0tLS0tLS0tLS08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiNDMDUwNEQiPkkuZS4gUmVxdWlyZTogZXhwbGljaXRzdWIgc2hvdWxkIGJlIGFs c28gYWxsb3dlZCBhdCBsZWFzdCBpbiAyeHggcmVzcG9uc2VzIHRvIFJFRkVSIHJlcXVlc3QuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUw NEQiPlBST1BPU0FMIDQ6IHVzZSB0aGUgZm9sbG93aW5nIHdvcmRpbmc6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojQzA1MDREIj4tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0K PHByZT48c3BhbiBzdHlsZT0iY29sb3I6I0MwNTA0RCI+QSBVQSBNVVNUIE5PVCBpbmNsdWRlIHRo ZSAnZXhwbGljaXRzdWInIG9wdGlvbiB0YWc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOiNDMDUwNEQiPiZuYnNwOyZuYnNwOyBpbiB0aGUgUmVxdWlyZSBo ZWFkZXIgZmllbGQgb2YgYW55IFNJUCByZXNwb25zZSBvdGhlciB0aGFuIGEgPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojQzA1MDREIj4mbmJzcDsmbmJz cDsmbmJzcDtyZXNwb25zZSB0byBhIFJFRkVSIHJlcXVlc3QuPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiNDMDUwNEQiPi0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+S2luZCByZWdhcmRzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojQzA1MDREIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPkl2 byBTZWRsYWNlazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMzMzMzMzMiPlRoaXMgQ29tbXVuaWNhdGlvbiBpcyBDb25maWRlbnRpYWwuIFdlIG9u bHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBv dXQgYXQNCjxhIGhyZWY9Imh0dHA6Ly93d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXIi IHRpdGxlPSJodHRwOi8vd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyIj4NCnd3dy5l cmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lcjwvYT4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gc2lwY29y ZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ Um9iZXJ0IFNwYXJrczxicj4NCjxiPlNlbnQ6PC9iPiA4LiB6w6HFmcOtIDIwMTQgMjI6NDE8YnI+ DQo8Yj5Ubzo8L2I+IHNpcGNvcmVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3NpcGNv cmVdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zcGFya3Mtc2lwY29y ZS1yZWZlci1leHBsaWNpdC1zdWJzY3JpcHRpb24tMDEudHh0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3Nh Z2UgLS0tLS0tLS0gPG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxl IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8 dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1h bGlnbjpyaWdodCI+PGI+U3ViamVjdDogPG86cD48L286cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBz dHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zcGFya3Mtc2lwY29yZS1yZWZlci1leHBs aWNpdC1zdWJzY3JpcHRpb24tMDEudHh0PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0 cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFs aWduOnJpZ2h0Ij48Yj5EYXRlOiA8bzpwPjwvbzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxl PSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Nb24sIDA4 IFNlcCAyMDE0IDEzOjMxOjMyIC0wNzAwPG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0 cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFs aWduOnJpZ2h0Ij48Yj5Gcm9tOiA8bzpwPjwvbzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxl PSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVm PSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc8L2E+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIg dmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5Ubzog PG86cD48L286cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Um9iZXJ0IFNwYXJrcyA8YSBocmVmPSJtYWls dG86cmpzcGFya3NAbm9zdHJ1bS5jb20iPiZsdDtyanNwYXJrc0Bub3N0cnVtLmNvbSZndDs8L2E+ LCBSb2JlcnQgU3BhcmtzDQo8YSBocmVmPSJtYWlsdG86cmpzcGFya3NAbm9zdHJ1bS5jb20iPiZs dDtyanNwYXJrc0Bub3N0cnVtLmNvbSZndDs8L2E+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90 cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwcmU+QSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWV4cGxpY2l0LXN1YnNjcmlwdGlv bi0wMS50eHQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IFJvYmVydCBTcGFya3MgYW5kIHBvc3RlZCB0byB0aGU8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5JRVRGIHJlcG9zaXRvcnkuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmU+TmFtZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtc3BhcmtzLXNpcGNvcmUtcmVmZXItZXhwbGlj aXQtc3Vic2NyaXB0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+UmV2aXNpb246Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAxPG86cD48L286cD48L3ByZT4NCjxwcmU+VGl0bGU6Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEV4cGxpY2l0IFN1 YnNjcmlwdGlvbnMgZm9yIHRoZSBSRUZFUiBNZXRob2Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5E b2N1bWVudCBkYXRlOiAyMDE0LTA5LTA4PG86cD48L286cD48L3ByZT4NCjxwcmU+R3JvdXA6Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluZGl2aWR1YWwg U3VibWlzc2lvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlBhZ2VzOiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxMTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PlVSTDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtc3BhcmtzLXNpcGNvcmUtcmVmZXItZXhwbGljaXQtc3Vic2NyaXB0aW9uLTAxLnR4 dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc3BhcmtzLXNpcGNv cmUtcmVmZXItZXhwbGljaXQtc3Vic2NyaXB0aW9uLTAxLnR4dDwvYT48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5TdGF0dXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNw YXJrcy1zaXBjb3JlLXJlZmVyLWV4cGxpY2l0LXN1YnNjcmlwdGlvbi8iPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWV4cGxpY2l0LXN1 YnNjcmlwdGlvbi88L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+SHRtbGl6ZWQ6Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWV4cGxpY2l0LXN1YnNjcmlwdGlvbi0w MSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc3BhcmtzLXNpcGNvcmUtcmVmZXIt ZXhwbGljaXQtc3Vic2NyaXB0aW9uLTAxPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkRpZmY6 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXNwYXJr cy1zaXBjb3JlLXJlZmVyLWV4cGxpY2l0LXN1YnNjcmlwdGlvbi0wMSI+aHR0cDovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtc3BhcmtzLXNpcGNvcmUtcmVmZXItZXhwbGljaXQtc3Vi c2NyaXB0aW9uLTAxPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlPkFic3RyYWN0OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyBUaGUgU0lQIFJFRkVSIHJlcXVlc3QsIGFzIGRlZmluZWQgYnkgUkZDMzUxNSwgdHJpZ2dlcnMg YW4gaW1wbGljaXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgU0lQLVNwZWNp ZmljIEV2ZW50IE5vdGlmaWNhdGlvbiBmcmFtZXdvcmsgc3Vic2NyaXB0aW9uLiZuYnNwOyBDb25m bGF0aW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHRoZSBzdGFydCBvZiB0 aGUgc3Vic2NyaXB0aW9uIHdpdGggaGFuZGxpbmcgdGhlIFJFRkVSIHJlcXVlc3QgbWFrZXM8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgbmVnb3RpYXRpbmcgU1VCU0NSSUJFIGV4 dGVuc2lvbnMgaW1wb3NzaWJsZSwgYW5kIGNvbXBsaWNhdGVzIGF2b2lkaW5nPG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFNJUCBkaWFsb2cgc2hhcmluZy4mbmJzcDsgVGhpcyBk b2N1bWVudCBkZWZpbmVzIGFuIGV4dGVuc2lvbiB0byBSRUZFUiB0bzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyByZW1vdmUgdGhlIGltcGxpY2l0IHN1YnNjcmlwdGlvbiBhbmQg cmVwbGFjZSBpdCB3aXRoIGFuIGV4cGxpY2l0IG9uZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_39B5E4D390E9BD4890E2B310790061011272E59CESESSMB301erics_-- From nobody Tue Sep 9 06:56:57 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C9E1A6FB6 for ; Tue, 9 Sep 2014 06:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0ZIBhaoIbYQ for ; Tue, 9 Sep 2014 06:56:48 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A211A0410 for ; Tue, 9 Sep 2014 06:56:48 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s89Duhaq087685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Tue, 9 Sep 2014 08:56:43 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <540F071B.1020409@nostrum.com> Date: Tue, 09 Sep 2014 08:56:43 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Ivo Sedlacek , "sipcore@ietf.org" References: <20140908203132.10649.77126.idtracker@ietfa.amsl.com> <540E1444.4020205@nostrum.com> <39B5E4D390E9BD4890E2B310790061011272E59C@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B310790061011272E59C@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------080407070808060803090803" Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/7yuBBV5RgM8PGim7Be701fGdSu0 Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 13:56:52 -0000 This is a multi-part message in MIME format. --------------080407070808060803090803 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks for the comments! On 9/9/14 3:41 AM, Ivo Sedlacek wrote: > > Hello Robert, > > I reviewed the paper and found the following: > > ISSUE 1: the draft states: > > ------------------- > > Sending a REFER within a dialog established > > by an INVITE results in dialog reuse and the associated problems > > described in [RFC5057 ]. > > ------------------- > > However, sending of the REFER alone does not result to dialog reuse. > The reuse happens only if the refer subscription is created (which is > not always the case). > > PROPOSAL 1: use the following wording: > > ------------------- > > Acceptance of a REFER request received within a dialog established > > by an INVITE and creation of refer subscription results in dialog > reuse and the associated problems > > described in [RFC5057 ]. > This bit of wordsmithing is not helping with clarity here. Accounting for the one case were you can ask (but not be guaranteed) to suppress the subscription doesn't help this document. > > ------------------- > > ISSUE 2: the draft states: > > ----------- > > Call > > transfer, as defined in [RFC5589 > ], thus requires sending a REFER > > request on a new dialog, associating it with an existing dialog using > > the 'Target-Dialog' mechanism defined in [RFC4538 > ]. > > ----------- > > However, RFC5589 only recommends it, not requires it. RFC5589 states: > > ----------- > > As a result, if the Transferee supports the target-dialog extension > > and the Transferor knows the Contact URI is routable outside the > > dialog, the REFER SHOULD be sent in a new dialog. > > ----------- > > PROPOSAL 2: use the following wording: > > ------------------- > > Call > > transfer, as defined in [RFC5589 > ], thus recommends sending a REFER > > request on a new dialog, associating it with an existing dialog using > > the 'Target-Dialog' mechanism defined in [RFC4538 > ]. > > ------------------- > > ISSUE 3: There are situations when neither UAS nor UAC want the refer > subscription - see RFC4488. However, the draft mandates the UAS to be > ready to create the subscription even if neither UAC nor UAS are > interested in it. That's unnecessary. > We talked about providing a way for the UAC to say "and I'm never going to subscribe" at IETF90 (see slide 6 from the deck on this topic). The mechanism discussed there was adding an additional "nosub" tag for the client to use instead of "explicitsub" when it knows it doesn't care about the subscription. I didn't get the proposal there into this version of the draft - I'll get it into the next. > > PROPOSAL 3: If Supported or Require header field with norefersub > option tag is indicated in the REFER request, the UAS does not include > the Refer-Events-At in 2xx response to REFER request. > Conflating this mechanism with 4488 is an anti-goal for me. > > ISSUE 4: the draft states: > > ----------- > > A UA MUST NOT include the 'explicitsub' option tag > in the Require header field of any SIP response other than a 421 > response to a REFER request. > > ----------- > > - this conflicts with RFC3261 stating: > > ----------- > > Any extensions applied to a non-421 response MUST be listed in a > > Require header field included in the response. > > ----------- > > I.e. Require: explicitsub should be also allowed at least in 2xx > responses to REFER request. > I'll reply to this one separately. > > PROPOSAL 4: use the following wording: > > ------------------- > > A UA MUST NOT include the 'explicitsub' option tag > in the Require header field of any SIP response other than a > response to a REFER request. > > ------------------- > > Kind regards > > Ivo Sedlacek > > This Communication is Confidential. We only send and receive email on > the basis of the terms set out at www.ericsson.com/email_disclaimer > > > *From:*sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf Of *Robert > Sparks > *Sent:* 8. září 2014 22:41 > *To:* sipcore@ietf.org > *Subject:* [sipcore] Fwd: New Version Notification for > draft-sparks-sipcore-refer-explicit-subscription-01.txt > > > > -------- Forwarded Message -------- > > *Subject: * > > > > New Version Notification for > draft-sparks-sipcore-refer-explicit-subscription-01.txt > > *Date: * > > > > Mon, 08 Sep 2014 13:31:32 -0700 > > *From: * > > > > internet-drafts@ietf.org > > *To: * > > > > Robert Sparks , > Robert Sparks > > A new version of I-D, draft-sparks-sipcore-refer-explicit-subscription-01.txt > has been successfully submitted by Robert Sparks and posted to the > IETF repository. > > Name: draft-sparks-sipcore-refer-explicit-subscription > Revision: 01 > Title: Explicit Subscriptions for the REFER Method > Document date: 2014-09-08 > Group: Individual Submission > Pages: 11 > URL:http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-explicit-subscription-01.txt > Status:https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-explicit-subscription/ > Htmlized:http://tools.ietf.org/html/draft-sparks-sipcore-refer-explicit-subscription-01 > Diff:http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-explicit-subscription-01 > > Abstract: > The SIP REFER request, as defined by RFC3515, triggers an implicit > SIP-Specific Event Notification framework subscription. Conflating > the start of the subscription with handling the REFER request makes > negotiating SUBSCRIBE extensions impossible, and complicates avoiding > SIP dialog sharing. This document defines an extension to REFER to > remove the implicit subscription and replace it with an explicit one. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > --------------080407070808060803090803 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Thanks for the comments!

On 9/9/14 3:41 AM, Ivo Sedlacek wrote:

Hello Robert,

 

I reviewed the paper and found the following:

 

ISSUE 1: the draft states:

-------------------

Sending a REFER within a dialog established

   by an INVITE results in dialog reuse and the associated problems

   described in [RFC5057].

-------------------

However, sending of the REFER alone does not result to dialog reuse. The reuse happens only if the refer subscription is created (which is not always the case).

 

PROPOSAL 1: use the following wording:

-------------------

Acceptance of a REFER request received within a dialog established

   by an INVITE and creation of refer subscription results in dialog reuse and the associated problems

   described in [RFC5057].

This bit of wordsmithing is not helping with clarity here. Accounting for the one case were you can ask (but not be guaranteed) to suppress the subscription doesn't help this document.

-------------------

 

 

ISSUE 2: the draft states:

-----------

Call

   transfer, as defined in [RFC5589], thus requires sending a REFER

   request on a new dialog, associating it with an existing dialog using

   the 'Target-Dialog' mechanism defined in [RFC4538].

-----------

However, RFC5589 only recommends it, not requires it. RFC5589 states:

-----------

   As a result, if the Transferee supports the target-dialog extension

   and the Transferor knows the Contact URI is routable outside the

   dialog, the REFER SHOULD be sent in a new dialog.

-----------

 

PROPOSAL 2: use the following wording:

-------------------

Call

   transfer, as defined in [RFC5589], thus recommends sending a REFER

   request on a new dialog, associating it with an existing dialog using

   the 'Target-Dialog' mechanism defined in [RFC4538].

-------------------

 

ISSUE 3: There are situations when neither UAS nor UAC want the refer subscription - see RFC4488. However, the draft mandates the UAS to be ready to create the subscription even if neither UAC nor UAS are interested in it. That's unnecessary.

We talked about providing a way for the UAC to say "and I'm never going to subscribe" at IETF90 (see slide 6 from the deck on this topic).
The mechanism discussed there was adding an additional "nosub" tag for the client to use instead of "explicitsub" when it knows it doesn't care about the subscription. I didn't get the proposal there into this version of the draft - I'll get it into the next.

 

PROPOSAL 3: If Supported or Require header field with norefersub option tag is indicated in the REFER request, the UAS does not include the Refer-Events-At in 2xx response to REFER request.

Conflating this mechanism with 4488 is an anti-goal for me.

 

ISSUE 4: the draft states:

-----------

A UA MUST NOT include the 'explicitsub' option tag
   in the Require header field of any SIP response other than a 421
   response to a REFER request.

-----------

- this conflicts with RFC3261 stating:

-----------

   Any extensions applied to a non-421 response MUST be listed in a

   Require header field included in the response.

-----------

I.e. Require: explicitsub should be also allowed at least in 2xx responses to REFER request.

I'll reply to this one separately.

 

PROPOSAL 4: use the following wording:

-------------------

A UA MUST NOT include the 'explicitsub' option tag
   in the Require header field of any SIP response other than a 
   response to a REFER request.

-------------------

 

Kind regards

 

Ivo Sedlacek

 

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert Sparks
Sent: 8. září 2014 22:41
To: sipcore@ietf.org
Subject: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01.txt

 

 



-------- Forwarded Message --------

Subject:

New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01.txt

Date:

Mon, 08 Sep 2014 13:31:32 -0700

From:

internet-drafts@ietf.org

To:

Robert Sparks <rjsparks@nostrum.com>, Robert Sparks <rjsparks@nostrum.com>

 

A new version of I-D, draft-sparks-sipcore-refer-explicit-subscription-01.txt
has been successfully submitted by Robert Sparks and posted to the
IETF repository.
 
Name:          draft-sparks-sipcore-refer-explicit-subscription
Revision:      01
Title:         Explicit Subscriptions for the REFER Method
Document date: 2014-09-08
Group:         Individual Submission
Pages:         11
URL:            http://www.ietf.org/internet-drafts/draft-sparks-sipcore-refer-explicit-subscription-01.txt
Status:         https://datatracker.ietf.org/doc/draft-sparks-sipcore-refer-explicit-subscription/
Htmlized:       http://tools.ietf.org/html/draft-sparks-sipcore-refer-explicit-subscription-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-refer-explicit-subscription-01
 
Abstract:
   The SIP REFER request, as defined by RFC3515, triggers an implicit
   SIP-Specific Event Notification framework subscription.  Conflating
   the start of the subscription with handling the REFER request makes
   negotiating SUBSCRIBE extensions impossible, and complicates avoiding
   SIP dialog sharing.  This document defines an extension to REFER to
   remove the implicit subscription and replace it with an explicit one.
 
                                                                                  
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
The IETF Secretariat
 

 

 


--------------080407070808060803090803-- From nobody Tue Sep 9 13:37:48 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EA81A0174 for ; Tue, 9 Sep 2014 13:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9GqoE61jW1R for ; Tue, 9 Sep 2014 13:37:45 -0700 (PDT) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1C11A0149 for ; Tue, 9 Sep 2014 13:37:45 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id v10so9641885pde.5 for ; Tue, 09 Sep 2014 13:37:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=mB3Ushx0zHz+59QdDu2bxN8uVNXChN7slZPz1dRAYx0=; b=lsQw8z0mFMQJbdGTDHNAbXSXlEy5YcgdWvt2ifSP6LMJXCbdB713dkbGbUW+Mbyolx HJNK1YU9Oz8AlKYcOa0yYQkMiEaMi1DcdaMNXzbWIkJMhNZDObaV5oKQhdLcfyouoqV7 Sc13aRL94GW9V+SF2Ih+5/wVRMdONG/CpgurcuKWbZpvDXavFyhflW5cbcdjwlcK/e2D etDMjqTv78HpA+LOxKnHNRfQ18wY4NDsFHAL8bwKVoo/xr0D5rhMQFiUNYXn/ymAjyAa 3isX0sVX5lf4cmzaDw/3p7jjnpfGxdzqlmQCRQ6nkDqEQlHcINbB31ySa7WkLfk3/5ac VK7A== X-Gm-Message-State: ALoCoQm2h5htXRBhQ8tUYe2CHs0sEJkbQlwOFZFUJhkXi8ejXzUMrKldWFJ1dtQea8yGV6fXGrWV X-Received: by 10.68.106.97 with SMTP id gt1mr32888074pbb.117.1410295065476; Tue, 09 Sep 2014 13:37:45 -0700 (PDT) Received: from [192.168.1.120] (202.250.sfcn.org. [160.7.250.202]) by mx.google.com with ESMTPSA id zf5sm12419794pbc.44.2014.09.09.13.37.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Sep 2014 13:37:44 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Matt Ryan In-Reply-To: <201409042210.s84MAbSV001101@hobgoblin.ariadne.com> Date: Tue, 9 Sep 2014 14:37:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> <201409042210.s84MAbSV001101@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/zpNujmyoK35-pZaJORMnxgKpyv4 Cc: sipcore@ietf.org Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 20:37:47 -0000 One comment inline below: On Sep 4, 2014, at 4:10 PM, Dale R. Worley wrote: (snip) >> In this example, a SIP 200 response (SIP 200 1) is sent >> which contains the new token(s). However, this could be confusing >> as SIP 200 is generally viewed as the acceptance of the INVITE, >> which is not what is happening in this case. Should SIP 200 be used >> for consistency, or should another mechanism be used? >=20 > I would say that the answer depends on whether response "SIP 200 1" > establishes a dialog or not. If it does, then 200 (or 2xx) is > correct. If it does not establish a dialog, and "VoIP Provider" must > send another INVITE to establish a dialog, then a 4xx response is > needed. >=20 > Naively, it's not clear why there would be a requirement for "VoIP > Provider" to send another INVITE containing the access token that it > just received in a SIP response. But I suppose if that worked, "VoIP > Provider" would just send the refresh token every time. >=20 The reason I proposed it that way is because that is how OAuth works = (or, more specifically, at least that is how OAuth used to work the last = time I did an OAuth implementation 2 years ago): IIRC, the client = initially sends a request to the resource server using the previously = obtained access token as authorization. If that access token is = expired, the client will request a new access token using the refresh = token for authorization, then try again. I am not familiar enough with the =93whys=94 of OAuth to know why it = does things that way. So, this proposal was based on trying to be like OAuth as much as = possible. SIP is not HTTP though, so it may be that slight = modifications to the HTTP way would be better for SIP OAuth. (snip) > Dale -- Matt Ryan code slinger | zoomulus.com ietf at mvryan dot org From nobody Thu Sep 11 00:53:42 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AB11A0645 for ; Thu, 11 Sep 2014 00:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e79fbmuFvio2 for ; Thu, 11 Sep 2014 00:53:38 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F4F61A6F68 for ; Thu, 11 Sep 2014 00:53:38 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-8e-5411550098fe Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F2.59.21334.00551145; Thu, 11 Sep 2014 09:53:36 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.77]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Thu, 11 Sep 2014 09:53:35 +0200 From: Ivo Sedlacek To: Robert Sparks , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01.txt Thread-Index: AQHPzDXm+7iwIaANlkC9j8uX0LLhuJv7kDIA Date: Thu, 11 Sep 2014 07:53:35 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061011272F9BE@ESESSMB301.ericsson.se> References: <20140908203132.10649.77126.idtracker@ietfa.amsl.com> <540E1444.4020205@nostrum.com> <39B5E4D390E9BD4890E2B310790061011272E59C@ESESSMB301.ericsson.se> <540F071B.1020409@nostrum.com> In-Reply-To: <540F071B.1020409@nostrum.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+JvjS5DqGCIwecn0hbX5jSyWXz9sYnN gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4Mr4PO8/W8EF1Ypz0w+xNzBeUeli5OCQEDCR aHxW3MXICWSKSVy4t56ti5GLQ0jgKKPEzPfboJzFjBJ7li1mBKliE9CTmLjlCCuILSIQKLFw 0hIWEFtYoEjiY2cbVLxYYs/+ucwQtpHEoovzmUGWsQioSjR0VICEeQV8JaZOO8oKMf84o8Tr ZxeZQBKcAtoSM/Z2ge1iFJCVuPqnF8xmFhCXuPVkPhPEpQISS/acZ4awRSVePv7HCvGMosTy fjkQk1lAU2L9Ln2ITkWJKd0P2SHWCkqcnPmEZQKj6CwkQ2chdMxC0jELSccCRpZVjKLFqcXF uelGxnqpRZnJxcX5eXp5qSWbGIERcnDLb90djKtfOx5iFOBgVOLhTbASDBFiTSwrrsw9xCjN waIkzrvo3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxph2NzdjBNFDgZIMDfz5mXvd9w imurn9cO2dCNtiWu9fr3lEWXLt9uILmVW357psCJZTZTQ/x+9n2Yt0T3k6576J0D4ReOvF87 tZVr9ofDQs6343gW7jgQulTlynLdD7en60oIsrfOC1EP/L/aYuVjJUX+XzvXTAqx1bBXunsp XOz8m7vFt4yVWIozEg21mIuKEwE1a0DFcQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/4uz7dPhbrE5YihshTdc1OgNIpYQ Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 07:53:40 -0000 SGVsbG8sDQoNCj4gPiBJU1NVRSAxOiB0aGUgZHJhZnQgc3RhdGVzOg0KPiA+IC0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPiBTZW5kaW5nIGEgUkVGRVIgd2l0aGluIGEgZGlhbG9nIGVzdGFibGlzaGVk DQo+ID4gwqDCoCBieSBhbiBJTlZJVEUgcmVzdWx0cyBpbiBkaWFsb2cgcmV1c2UgYW5kIHRoZSBh c3NvY2lhdGVkIHByb2JsZW1zDQo+ID4gwqDCoCBkZXNjcmliZWQgaW4gW1JGQzUwNTddLg0KPiA+ IC0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBIb3dldmVyLCBzZW5kaW5nIG9mIHRoZSBSRUZFUiBh bG9uZSBkb2VzIG5vdCByZXN1bHQgdG8gZGlhbG9nIHJldXNlLiBUaGUgcmV1c2UgaGFwcGVucyBv bmx5IGlmIHRoZSByZWZlciBzdWJzY3JpcHRpb24gaXMgY3JlYXRlZCAod2hpY2ggaXMgbm90IGFs d2F5cyB0aGUgY2FzZSkuDQrCoD4gPiANCj4gPiBQUk9QT1NBTCAxOiB1c2UgdGhlIGZvbGxvd2lu ZyB3b3JkaW5nOg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBBY2NlcHRhbmNlIG9mIGEg UkVGRVIgcmVxdWVzdCByZWNlaXZlZCB3aXRoaW4gYSBkaWFsb2cgZXN0YWJsaXNoZWQNCj4gPiDC oMKgIGJ5IGFuIElOVklURSBhbmQgY3JlYXRpb24gb2YgcmVmZXIgc3Vic2NyaXB0aW9uIHJlc3Vs dHMgaW4gZGlhbG9nIHJldXNlIGFuZCB0aGUgYXNzb2NpYXRlZCBwcm9ibGVtcw0KPiA+IMKgwqAg ZGVzY3JpYmVkIGluIFtSRkM1MDU3XS4NCg0KPiBUaGlzIGJpdCBvZiB3b3Jkc21pdGhpbmcgaXMg bm90IGhlbHBpbmcgd2l0aCBjbGFyaXR5IGhlcmUuIEFjY291bnRpbmcgZm9yIHRoZSBvbmUgY2Fz ZSB3ZXJlIHlvdSBjYW4gYXNrIChidXQgbm90IGJlIGd1YXJhbnRlZWQpIHRvIHN1cHByZXNzIHRo ZSBzdWJzY3JpcHRpb24gZG9lc24ndCBoZWxwIHRoaXMgZG9jdW1lbnQuDQoNCk90aGVyIHBvc3Np YmxlIHdvcmRpbmcgb2YgUFJPUE9TQUwgIDEgaXM6DQotLS0tLS0tLS0tLS0tLS0tLS0tDQpTZW5k aW5nIGEgUkVGRVIgd2l0aGluIGEgZGlhbG9nIGVzdGFibGlzaGVkDQrCoMKgIGJ5IGFuIElOVklU RSAqbWlnaHQqIHJlc3VsdCBpbiBkaWFsb2cgcmV1c2UgYW5kIHRoZSBhc3NvY2lhdGVkIHByb2Js ZW1zDQrCoMKgIGRlc2NyaWJlZCBpbiBbUkZDNTA1N10uDQotLS0tLS0tLS0tLS0tLS0tLS0tDQoN CldvdWxkIHRoYXQgYmUgYmV0dGVyPw0KDQo+ID4gSVNTVUUgMjogdGhlIGRyYWZ0IHN0YXRlczoN Cj4gPiAtLS0tLS0tLS0tLQ0KPiA+IENhbGwNCj4gPiDCoMKgIHRyYW5zZmVyLCBhcyBkZWZpbmVk IGluIFtSRkM1NTg5XSwgdGh1cyByZXF1aXJlcyBzZW5kaW5nIGEgUkVGRVINCj4gPiDCoMKgIHJl cXVlc3Qgb24gYSBuZXcgZGlhbG9nLCBhc3NvY2lhdGluZyBpdCB3aXRoIGFuIGV4aXN0aW5nIGRp YWxvZyB1c2luZw0KPiA+IMKgwqAgdGhlICdUYXJnZXQtRGlhbG9nJyBtZWNoYW5pc20gZGVmaW5l ZCBpbiBbUkZDNDUzOF0uDQo+ID4gLS0tLS0tLS0tLS0NCj4gPiBIb3dldmVyLCBSRkM1NTg5IG9u bHkgcmVjb21tZW5kcyBpdCwgbm90IHJlcXVpcmVzIGl0LiBSRkM1NTg5IHN0YXRlczoNCj4gPiAt LS0tLS0tLS0tLQ0KPiA+IMKgwqAgQXMgYSByZXN1bHQsIGlmIHRoZSBUcmFuc2ZlcmVlIHN1cHBv cnRzIHRoZSB0YXJnZXQtZGlhbG9nIGV4dGVuc2lvbg0KPiA+IMKgIMKgYW5kIHRoZSBUcmFuc2Zl cm9yIGtub3dzIHRoZSBDb250YWN0IFVSSSBpcyByb3V0YWJsZSBvdXRzaWRlIHRoZQ0KPiA+IMKg wqAgZGlhbG9nLCB0aGUgUkVGRVIgU0hPVUxEIGJlIHNlbnQgaW4gYSBuZXcgZGlhbG9nLg0KPiA+ IC0tLS0tLS0tLS0tDQrCoD4gPiANCj4gPiBQUk9QT1NBTCAyOiB1c2UgdGhlIGZvbGxvd2luZyB3 b3JkaW5nOg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBDYWxsDQo+ID4gwqDCoCB0cmFu c2ZlciwgYXMgZGVmaW5lZCBpbiBbUkZDNTU4OV0sIHRodXMgcmVjb21tZW5kcyBzZW5kaW5nIGEg UkVGRVINCj4gPiDCoMKgIHJlcXVlc3Qgb24gYSBuZXcgZGlhbG9nLCBhc3NvY2lhdGluZyBpdCB3 aXRoIGFuIGV4aXN0aW5nIGRpYWxvZyB1c2luZw0KPiA+IMKgwqAgdGhlICdUYXJnZXQtRGlhbG9n JyBtZWNoYW5pc20gZGVmaW5lZCBpbiBbUkZDNDUzOF0uDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0t LQ0KwqANCkFueSB2aWV3IG9uIHRoaXMgaXNzdWUgYW5kIHByb3Bvc2FsPw0KDQo+ID4gSVNTVUUg MzogVGhlcmUgYXJlIHNpdHVhdGlvbnMgd2hlbiBuZWl0aGVyIFVBUyBub3IgVUFDIHdhbnQgdGhl IHJlZmVyIHN1YnNjcmlwdGlvbiAtIHNlZSBSRkM0NDg4LiBIb3dldmVyLCB0aGUgZHJhZnQgbWFu ZGF0ZXMgdGhlIFVBUyB0byBiZSByZWFkeSB0byBjcmVhdGUgdGhlIHN1YnNjcmlwdGlvbiBldmVu IGlmIG5laXRoZXIgVUFDIG5vciBVQVMgYXJlIGludGVyZXN0ZWQgaW4gaXQuIFRoYXQncyB1bm5l Y2Vzc2FyeS4NCg0KPiBXZSB0YWxrZWQgYWJvdXQgcHJvdmlkaW5nIGEgd2F5IGZvciB0aGUgVUFD IHRvIHNheSAiYW5kIEknbSBuZXZlciBnb2luZyB0byBzdWJzY3JpYmUiIGF0IElFVEY5MCAoc2Vl IHNsaWRlIDYgZnJvbSB0aGUgZGVjayBvbiB0aGlzIHRvcGljKS4NCj4gVGhlIG1lY2hhbmlzbSBk aXNjdXNzZWQgdGhlcmUgd2FzIGFkZGluZyBhbiBhZGRpdGlvbmFsICJub3N1YiIgdGFnIGZvciB0 aGUgY2xpZW50IHRvIHVzZSBpbnN0ZWFkIG9mICJleHBsaWNpdHN1YiIgd2hlbiBpdCBrbm93cyBp dCBkb2Vzbid0IGNhcmUgYWJvdXQgdGhlIHN1YnNjcmlwdGlvbi4gSSBkaWRuJ3QgZ2V0IHRoZSBw cm9wb3NhbCB0aGVyZSBpbnRvIHRoaXMgdmVyc2lvbiBvZiB0aGUgZHJhZnQgLSBJJ2xsIGdldCBp dCBpbnRvIHRoZSBuZXh0Lg0KDQpUaGFua3MsIEkgYW0gbG9va2luZyBmb3J3YXJkIHRvIHNlZWlu ZyBuZXh0IHZlcnNpb24gd2l0aCB0aGUgIm5vc3ViIiB0YWcuDQoNCj4gPiBJU1NVRSA0OiB0aGUg ZHJhZnQgc3RhdGVzOg0KPiA+IC0tLS0tLS0tLS0tDQo+ID4gQSBVQSBNVVNUIE5PVCBpbmNsdWRl IHRoZSAnZXhwbGljaXRzdWInIG9wdGlvbiB0YWcNCj4gPiDCoMKgIGluIHRoZSBSZXF1aXJlIGhl YWRlciBmaWVsZCBvZiBhbnkgU0lQIHJlc3BvbnNlIG90aGVyIHRoYW4gYSA0MjENCj4gPiDCoMKg IHJlc3BvbnNlIHRvIGEgUkVGRVIgcmVxdWVzdC4NCj4gPiAtLS0tLS0tLS0tLQ0KPiA+IC0gdGhp cyBjb25mbGljdHMgd2l0aCBSRkMzMjYxIHN0YXRpbmc6DQo+ID4gLS0tLS0tLS0tLS0NCj4gPiDC oMKgIEFueSBleHRlbnNpb25zIGFwcGxpZWQgdG8gYSBub24tNDIxIHJlc3BvbnNlIE1VU1QgYmUg bGlzdGVkIGluIGENCj4gPiDCoMKgIFJlcXVpcmUgaGVhZGVyIGZpZWxkIGluY2x1ZGVkIGluIHRo ZSByZXNwb25zZS4NCj4gPiAtLS0tLS0tLS0tLQ0KPiA+IEkuZS4gUmVxdWlyZTogZXhwbGljaXRz dWIgc2hvdWxkIGJlIGFsc28gYWxsb3dlZCBhdCBsZWFzdCBpbiAyeHggcmVzcG9uc2VzIHRvIFJF RkVSIHJlcXVlc3QuDQoNCj4gSSdsbCByZXBseSB0byB0aGlzIG9uZSBzZXBhcmF0ZWx5Lg0KDQpP Sw0KDQpLaW5kIHJlZ2FyZHMNCsKgDQpJdm8gU2VkbGFjZWsNCsKgDQo= From nobody Fri Sep 12 04:25:30 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20781A06E3 for ; Fri, 12 Sep 2014 04:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cytvL6IE7VpJ for ; Fri, 12 Sep 2014 04:25:24 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0591A06E8 for ; Fri, 12 Sep 2014 04:25:23 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-ad-5412d8211e81 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 84.86.21432.128D2145; Fri, 12 Sep 2014 13:25:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Fri, 12 Sep 2014 13:25:20 +0200 From: Christer Holmberg To: Ivo Sedlacek , Robert Sparks , "sipcore@ietf.org" Thread-Topic: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01.txt Thread-Index: AQHPy6UpHadQSpJb2kS6+e2U5Iuyd5v4Wu2AgABYB4CAAr80gIAB7l5Q Date: Fri, 12 Sep 2014 11:25:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D447080@ESESSMB209.ericsson.se> References: <20140908203132.10649.77126.idtracker@ietfa.amsl.com> <540E1444.4020205@nostrum.com> <39B5E4D390E9BD4890E2B310790061011272E59C@ESESSMB301.ericsson.se> <540F071B.1020409@nostrum.com> <39B5E4D390E9BD4890E2B310790061011272F9BE@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B310790061011272F9BE@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvja7iDaEQg2W7VCyuzWlks/j6YxOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJXxZdo51oJ9uhUPD85jbGBcodPFyMkhIWAi 8fboDnYIW0ziwr31bCC2kMBRRolX3VxdjFxA9hJGiRMtXUBFHBxsAhYS3f+0QWpEBKol2rf+ ZgKxhQWKJD52trFCxIsl9uyfywxhu0l0TDsKFmcRUJVY8/kXI4jNK+Arser+BBaI+d1MEutv HmEBSXAK+El8frAN7AhGoIO+n1oDtoBZQFzi1pP5TBCHCkgs2XOeGcIWlXj5+B8rhK0k8WPD JRaQO5kFNCXW79KHaFWUmNL9kB1ir6DEyZlPWCYwis5CMnUWQscsJB2zkHQsYGRZxShanFqc lJtuZKSXWpSZXFycn6eXl1qyiREYIwe3/DbYwfjyueMhRgEORiUe3gQrwRAh1sSy4srcQ4zS HCxK4rwLz80LFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cC4/cYhv23tAedYa/e3727ym7/q RPZJTb2gbRskT/f2O2zhXKMQ5p7nOdlK9Gf680+tWhqrVLaHfpP8n2Iq9CvGfXJYsLR6/pcP BTzNYX+S6sS9Tl/xF0qbMk3xfdvaej5lrp/euxz+JFnIz9n44EpM2Y1XsWEmXdJbrn6fYtrP 826jSteHT9+UWIozEg21mIuKEwGNuJY7cgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/kFrAzcmZaVoEdwgxc_GO3XKzL70 Subject: Re: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 11:25:27 -0000 SGksDQoNCkV2ZW50aG91Z2ggdGhlcmUgYXJlIHN0aWxsIGNvbW1lbnRzIHRvIGJlIGFkZHJlc3Nl ZCwgbm9ib2R5IGhhcyBvYmplY3RlZCB0byB0aGUgbWVjaGFuaXNtIGFzIHN1Y2guIEkgdGhpbmsg d2Ugc2hvdWxkIGFkb3B0IHRoZSBkcmFmdCBhcyB0aGUgYmFzZSBmb3IgYSBXRyBkZWxpdmVyeS4g SSBzZWUgbm8gbmVlZCB0byB3YWl0IHVudGlsIEhhd2FpaSBmb3IgdGhhdC4gTGV0J3Mgc3BlbmQg dGhlIGZhY2UtdG8tZmFjZSB0aW1lIHRvIGRpc2N1c3MgaXNzdWVzIGV0YyBpbnN0ZWFkLg0KDQpS ZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBJdm8gU2VkbGFjZWsNClNlbnQ6IDExLiBzeXlza3V1dGEgMjAxNCAxMDo1NA0KVG86IFJvYmVy dCBTcGFya3M7IHNpcGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gRndkOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWV4 cGxpY2l0LXN1YnNjcmlwdGlvbi0wMS50eHQNCg0KSGVsbG8sDQoNCj4gPiBJU1NVRSAxOiB0aGUg ZHJhZnQgc3RhdGVzOg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBTZW5kaW5nIGEgUkVG RVIgd2l0aGluIGEgZGlhbG9nIGVzdGFibGlzaGVkDQo+ID4gwqDCoCBieSBhbiBJTlZJVEUgcmVz dWx0cyBpbiBkaWFsb2cgcmV1c2UgYW5kIHRoZSBhc3NvY2lhdGVkIHByb2JsZW1zDQo+ID4gwqDC oCBkZXNjcmliZWQgaW4gW1JGQzUwNTddLg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBI b3dldmVyLCBzZW5kaW5nIG9mIHRoZSBSRUZFUiBhbG9uZSBkb2VzIG5vdCByZXN1bHQgdG8gZGlh bG9nIHJldXNlLiBUaGUgcmV1c2UgaGFwcGVucyBvbmx5IGlmIHRoZSByZWZlciBzdWJzY3JpcHRp b24gaXMgY3JlYXRlZCAod2hpY2ggaXMgbm90IGFsd2F5cyB0aGUgY2FzZSkuDQrCoD4gPiANCj4g PiBQUk9QT1NBTCAxOiB1c2UgdGhlIGZvbGxvd2luZyB3b3JkaW5nOg0KPiA+IC0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPiBBY2NlcHRhbmNlIG9mIGEgUkVGRVIgcmVxdWVzdCByZWNlaXZlZCB3aXRo aW4gYSBkaWFsb2cgZXN0YWJsaXNoZWQNCj4gPiDCoMKgIGJ5IGFuIElOVklURSBhbmQgY3JlYXRp b24gb2YgcmVmZXIgc3Vic2NyaXB0aW9uIHJlc3VsdHMgaW4gZGlhbG9nIHJldXNlIGFuZCB0aGUg YXNzb2NpYXRlZCBwcm9ibGVtcw0KPiA+IMKgwqAgZGVzY3JpYmVkIGluIFtSRkM1MDU3XS4NCg0K PiBUaGlzIGJpdCBvZiB3b3Jkc21pdGhpbmcgaXMgbm90IGhlbHBpbmcgd2l0aCBjbGFyaXR5IGhl cmUuIEFjY291bnRpbmcgZm9yIHRoZSBvbmUgY2FzZSB3ZXJlIHlvdSBjYW4gYXNrIChidXQgbm90 IGJlIGd1YXJhbnRlZWQpIHRvIHN1cHByZXNzIHRoZSBzdWJzY3JpcHRpb24gZG9lc24ndCBoZWxw IHRoaXMgZG9jdW1lbnQuDQoNCk90aGVyIHBvc3NpYmxlIHdvcmRpbmcgb2YgUFJPUE9TQUwgIDEg aXM6DQotLS0tLS0tLS0tLS0tLS0tLS0tDQpTZW5kaW5nIGEgUkVGRVIgd2l0aGluIGEgZGlhbG9n IGVzdGFibGlzaGVkDQrCoMKgIGJ5IGFuIElOVklURSAqbWlnaHQqIHJlc3VsdCBpbiBkaWFsb2cg cmV1c2UgYW5kIHRoZSBhc3NvY2lhdGVkIHByb2JsZW1zDQrCoMKgIGRlc2NyaWJlZCBpbiBbUkZD NTA1N10uDQotLS0tLS0tLS0tLS0tLS0tLS0tDQoNCldvdWxkIHRoYXQgYmUgYmV0dGVyPw0KDQo+ ID4gSVNTVUUgMjogdGhlIGRyYWZ0IHN0YXRlczoNCj4gPiAtLS0tLS0tLS0tLQ0KPiA+IENhbGwN Cj4gPiDCoMKgIHRyYW5zZmVyLCBhcyBkZWZpbmVkIGluIFtSRkM1NTg5XSwgdGh1cyByZXF1aXJl cyBzZW5kaW5nIGEgUkVGRVINCj4gPiDCoMKgIHJlcXVlc3Qgb24gYSBuZXcgZGlhbG9nLCBhc3Nv Y2lhdGluZyBpdCB3aXRoIGFuIGV4aXN0aW5nIGRpYWxvZyB1c2luZw0KPiA+IMKgwqAgdGhlICdU YXJnZXQtRGlhbG9nJyBtZWNoYW5pc20gZGVmaW5lZCBpbiBbUkZDNDUzOF0uDQo+ID4gLS0tLS0t LS0tLS0NCj4gPiBIb3dldmVyLCBSRkM1NTg5IG9ubHkgcmVjb21tZW5kcyBpdCwgbm90IHJlcXVp cmVzIGl0LiBSRkM1NTg5IHN0YXRlczoNCj4gPiAtLS0tLS0tLS0tLQ0KPiA+IMKgwqAgQXMgYSBy ZXN1bHQsIGlmIHRoZSBUcmFuc2ZlcmVlIHN1cHBvcnRzIHRoZSB0YXJnZXQtZGlhbG9nIGV4dGVu c2lvbg0KPiA+IMKgIMKgYW5kIHRoZSBUcmFuc2Zlcm9yIGtub3dzIHRoZSBDb250YWN0IFVSSSBp cyByb3V0YWJsZSBvdXRzaWRlIHRoZQ0KPiA+IMKgwqAgZGlhbG9nLCB0aGUgUkVGRVIgU0hPVUxE IGJlIHNlbnQgaW4gYSBuZXcgZGlhbG9nLg0KPiA+IC0tLS0tLS0tLS0tDQrCoD4gPiANCj4gPiBQ Uk9QT1NBTCAyOiB1c2UgdGhlIGZvbGxvd2luZyB3b3JkaW5nOg0KPiA+IC0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gPiBDYWxsDQo+ID4gwqDCoCB0cmFuc2ZlciwgYXMgZGVmaW5lZCBpbiBbUkZDNTU4 OV0sIHRodXMgcmVjb21tZW5kcyBzZW5kaW5nIGEgUkVGRVINCj4gPiDCoMKgIHJlcXVlc3Qgb24g YSBuZXcgZGlhbG9nLCBhc3NvY2lhdGluZyBpdCB3aXRoIGFuIGV4aXN0aW5nIGRpYWxvZyB1c2lu Zw0KPiA+IMKgwqAgdGhlICdUYXJnZXQtRGlhbG9nJyBtZWNoYW5pc20gZGVmaW5lZCBpbiBbUkZD NDUzOF0uDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLQ0KwqANCkFueSB2aWV3IG9uIHRoaXMgaXNz dWUgYW5kIHByb3Bvc2FsPw0KDQo+ID4gSVNTVUUgMzogVGhlcmUgYXJlIHNpdHVhdGlvbnMgd2hl biBuZWl0aGVyIFVBUyBub3IgVUFDIHdhbnQgdGhlIHJlZmVyIHN1YnNjcmlwdGlvbiAtIHNlZSBS RkM0NDg4LiBIb3dldmVyLCB0aGUgZHJhZnQgbWFuZGF0ZXMgdGhlIFVBUyB0byBiZSByZWFkeSB0 byBjcmVhdGUgdGhlIHN1YnNjcmlwdGlvbiBldmVuIGlmIG5laXRoZXIgVUFDIG5vciBVQVMgYXJl IGludGVyZXN0ZWQgaW4gaXQuIFRoYXQncyB1bm5lY2Vzc2FyeS4NCg0KPiBXZSB0YWxrZWQgYWJv dXQgcHJvdmlkaW5nIGEgd2F5IGZvciB0aGUgVUFDIHRvIHNheSAiYW5kIEknbSBuZXZlciBnb2lu ZyB0byBzdWJzY3JpYmUiIGF0IElFVEY5MCAoc2VlIHNsaWRlIDYgZnJvbSB0aGUgZGVjayBvbiB0 aGlzIHRvcGljKS4NCj4gVGhlIG1lY2hhbmlzbSBkaXNjdXNzZWQgdGhlcmUgd2FzIGFkZGluZyBh biBhZGRpdGlvbmFsICJub3N1YiIgdGFnIGZvciB0aGUgY2xpZW50IHRvIHVzZSBpbnN0ZWFkIG9m ICJleHBsaWNpdHN1YiIgd2hlbiBpdCBrbm93cyBpdCBkb2Vzbid0IGNhcmUgYWJvdXQgdGhlIHN1 YnNjcmlwdGlvbi4gSSBkaWRuJ3QgZ2V0IHRoZSBwcm9wb3NhbCB0aGVyZSBpbnRvIHRoaXMgdmVy c2lvbiBvZiB0aGUgZHJhZnQgLSBJJ2xsIGdldCBpdCBpbnRvIHRoZSBuZXh0Lg0KDQpUaGFua3Ms IEkgYW0gbG9va2luZyBmb3J3YXJkIHRvIHNlZWluZyBuZXh0IHZlcnNpb24gd2l0aCB0aGUgIm5v c3ViIiB0YWcuDQoNCj4gPiBJU1NVRSA0OiB0aGUgZHJhZnQgc3RhdGVzOg0KPiA+IC0tLS0tLS0t LS0tDQo+ID4gQSBVQSBNVVNUIE5PVCBpbmNsdWRlIHRoZSAnZXhwbGljaXRzdWInIG9wdGlvbiB0 YWcNCj4gPiDCoMKgIGluIHRoZSBSZXF1aXJlIGhlYWRlciBmaWVsZCBvZiBhbnkgU0lQIHJlc3Bv bnNlIG90aGVyIHRoYW4gYSA0MjENCj4gPiDCoMKgIHJlc3BvbnNlIHRvIGEgUkVGRVIgcmVxdWVz dC4NCj4gPiAtLS0tLS0tLS0tLQ0KPiA+IC0gdGhpcyBjb25mbGljdHMgd2l0aCBSRkMzMjYxIHN0 YXRpbmc6DQo+ID4gLS0tLS0tLS0tLS0NCj4gPiDCoMKgIEFueSBleHRlbnNpb25zIGFwcGxpZWQg dG8gYSBub24tNDIxIHJlc3BvbnNlIE1VU1QgYmUgbGlzdGVkIGluIGENCj4gPiDCoMKgIFJlcXVp cmUgaGVhZGVyIGZpZWxkIGluY2x1ZGVkIGluIHRoZSByZXNwb25zZS4NCj4gPiAtLS0tLS0tLS0t LQ0KPiA+IEkuZS4gUmVxdWlyZTogZXhwbGljaXRzdWIgc2hvdWxkIGJlIGFsc28gYWxsb3dlZCBh dCBsZWFzdCBpbiAyeHggcmVzcG9uc2VzIHRvIFJFRkVSIHJlcXVlc3QuDQoNCj4gSSdsbCByZXBs eSB0byB0aGlzIG9uZSBzZXBhcmF0ZWx5Lg0KDQpPSw0KDQpLaW5kIHJlZ2FyZHMNCsKgDQpJdm8g U2VkbGFjZWsNCsKgDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K From nobody Sat Sep 13 12:32:48 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8463F1A0086 for ; Sat, 13 Sep 2014 12:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZ-LR7FAWlgX for ; Sat, 13 Sep 2014 12:32:39 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D9D1A0027 for ; Sat, 13 Sep 2014 12:32:38 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id l4so2548043lbv.8 for ; Sat, 13 Sep 2014 12:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KxfKb71znn8sJ9dW2NH7iISJXolD83/0fzd2Pf/XuPY=; b=AeAUG0r6cqTCqDmEK3aOgujBnntoA3MteQrfOatASO1EHleAUk/sTFAXGKvwSLvLxa nx5F+5rrnoBCSoDjgs0HdfG7ZLaIyBZWXFpCa3EIugo7iIdB9agDe4fsA1a8SPXRfxGu FVazfH+aNlnIhtuNY+47edcQWJ7hUSqNqP9Prk4R34jELH2HXX+ftm8rIjHTnGbQ0lbd JDz75EteFvVwN9PQFFu5i3yZCz8pVGP6NR7wuPhs1cd2s16QlEyK8vgL1vcJHxg4udOj WATSfAb47YpNjE6brezlc9FelsoUj7KO4218R3ldmjPqliEZt1c7z0wX0/z3cQuNwHKj k0sQ== MIME-Version: 1.0 X-Received: by 10.152.4.39 with SMTP id h7mr17899328lah.49.1410636756932; Sat, 13 Sep 2014 12:32:36 -0700 (PDT) Received: by 10.114.2.34 with HTTP; Sat, 13 Sep 2014 12:32:36 -0700 (PDT) In-Reply-To: References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> <53FB83FA.8010101@alum.mit.edu> Date: Sat, 13 Sep 2014 15:32:36 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=089e013d1c46cddcdd0502f776f2 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/cqCqWCpbk_dywQqv345DTByZRZE Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 19:32:45 -0000 --089e013d1c46cddcdd0502f776f2 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 4, 2014 at 7:27 PM, Peterson, Jon wrote: > > I understand that OAuth can be altered from its basic flows to provide > tokens for OpenID, and IdP could be bound to OAuth, and while this is all > very interesting it doesn't change much about the requirements discussion I > think we need to have: the one about what kinds of use cases we want to > satisfy and who the relying parties are in those cases. Once we understand > that, we will understand what tools are applicable to these use cases - > preferably, not tools that need to be twisted into a different shape to be > applicable. > > Well, OpenID extends the OAuth 2.0 Framework to authenticate the user; why do you think it is "twisting" OAuth into a different shape? > It would helpful, in the enterprise SSO case, for us to understand what > kinds of application servers a user might need to access, and what exactly > those application servers need to know about the user in order to > accomplish their function. > > Below is a description for some enterprise issues, that hopefully will be addressed by a new authorization framework: * Multiple Identities One of the major issues in the enterprise is the need for a user to obtain multiple uncorrelated identities associated with different products to get access to the various services provided by the enterprise. For example, in the enterprise the user will be provided with different identities to: o Login his device (PC, laptop, mobile, ...) to the network. o Register to the SIP network and get basic SIP services. o Access his Voice Mail. o Host a conference. o etc Typically, these identities belong to different administrative domains and realms. Instead of these multiple identities, ideally the enterprise would like to create and maintain only one identity for the user and then allow the user access to all SIP and non-SIP services using that one identity. * Authorization of Access to Services Another issue in the enterprise is the need to control and authorize a user access to services. Because application servers have their own user directory, the control of access to services is spread over a multitude of servers in the network. Ideally, the enterprise would like to manage the access to services using one centralized entity and for the various entities that provide the service to become the enforcement points. * Assignment of Services In the enterprise, different users might be assigned to different servers providing a specific service; e.g. Voice Mail Box for different users might be hosted by different servers, and the user need to know his assigned server to be able to get access to this service. * Application Servers To be able to provide service, the application server needs a list of users allowed to get services. The application server needs the following pieces of information about each user: 1. User ID and Credentials 2. Profile to control the level of service provided to the user. If one application server provides different services using different protocols, the application server might need to maintain different identities associated with these protocols; e.g. an application server that provides presence service using SIP, and IM service using XMPP. Ideally, an authorization framework would: 1. Off load the application server from the need to manage the user credentials and authenticating the user. 2. Off load the application server from the need to maintain the users and their profiles to control the level of service provided to the user. 3. Allow the assignment of a user to a specific application server. * OAuth/OpenID Model With the OAuth/OpenID framework, the user ID and credentials will be handled by the authorization server, and the application server assignment and the level of service associated with the user will be provided in the scope of the token associated with the user. When the application server receives a request from a user it will have all the details that would allow the application server to validate the request to make sure it is coming from the right authorization server, and to act upon the request because it has the scope associated with the user, without the need to contact the authorization server. * Relying Party Regarding the Relying Party question: I think that when the user is being authenticated, that the Relying Party would be the SIP Client that would be given a user token (ID Token in OpenID lingo) to access services on behalf of the end user. So, the mapping would be something like this: +------------------------+-----------------------------+ | OAuth | SIP | +------------------------+-----------------------------+ | Resource Owner | End User | | Resource Server | SIP Proxy or SIP App Server | | Client | SIP UA (Relying Party) | | Authorization Server | Authorization Server | +------------------------+-----------------------------+ Regards, Rifaat > Jon Peterson > Neustar, Inc. > > From: Rifaat Shekh-Yusef > Date: Thursday, September 4, 2014 at 8:31 AM > To: Jon Peterson > Cc: Paul Kyzivat , "sipcore@ietf.org" < > sipcore@ietf.org> > Subject: Re: [sipcore] A SIP OAuth use case > > > > > On Wed, Sep 3, 2014 at 4:00 PM, Peterson, Jon > wrote: > >> >> While I would echo Paul's thoughts below about the plausibility of service >> providers using this model to authorize recording, I also agree that >> third-party recording is an excellent example of a service architecture >> that requires an authorization mechanism like OAuth. An end user needs to >> authorize a third party to participate in the session under certain >> constraints, and coordinate the association between the third party and >> the VoIP service. This example also (rightly, in my opinion) conducts the >> majority of the flow in HTTP where it belongs. >> >> > I agree with that. > > > >> Many of the use cases under discussion in this thread, though, are of the >> form where there are really only two involved parties: an end user and a >> service provider. If you are my service provider, then in traditional SIP >> I share a secret with you that I use to REGISTER my devices. I don't think >> you need OAuth for that. > > > If you assume that there is one server that provides all the services, > then you are right. > But that is not the case all the time. I think that Dale articulated that > clearly in the following response: > http://www.ietf.org/mail-archive/web/sipcore/current/msg06233.html > > > >> I do understand that OAuth 2.0 is used in the >> wild for SSO, though I sympathize with Matt that the base flow shown in >> RFC6749 Sec 1.2 just doesn't map onto the requirements for SSO. >> >> > I agree that the OAuth 2.0 "as is" does not address the SSO requirements. > The SIP OAuth proposal is not just using OAuth 2.0 "as is", but it is > extending the framework to authenticate and provide a *user* specific token. > > Since Matt mentioned OpenID few times, I looked at the OpenID > specification. > What they are doing there is that they defined a new token, called ID > Token, that is associated with the *user*; which is exactly what the SIP > OAuth proposal is doing. > http://openid.net/specs/openid-connect-core-1_0.html#IDToken > > My plan is to use the same terminology, ID Token, in the next version of > the SIP OAuth document to clarify that, and to differentiate it from the > access token. > > > >> I think, though, we might usefully break uses cases here down by who the >> intended relying party is: >> >> - The user's own SIP service provider (my enterprise, my carrier, my OTT >> provider) >> - A third party that a user wants to authorize for a service (recording >> service... But anything else?) >> >> I would also append some use cases where the relying party: >> >> - Someone with no association with the user (caller ID sorts of cases) >> >> This last is where I've argued things like IdP might be relevant. >> >> > EKR has a nice description for binding IdP to OAuth in his WebRTC > Security Architecture document here: > https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10#appendix-A.2 > > We could use the same idea for SIP. > > > Regards, > Rifaat > > > > >> Are there any other high-level buckets of use cases here? >> >> Jon Peterson >> Neustar, Inc. >> >> On 8/25/14, 11:44 AM, "Paul Kyzivat" wrote: >> >> >On 8/25/14 11:50 AM, Rifaat Shekh-Yusef wrote: >> >> Hi Matt, >> >> >> >> The use case and the solution provided assumes that the VoIP Provider >> >> makes the decision on when and what to record. >> >> While this is a valid use case, there are other use cases that allow >> the >> >> user to decide on when and what to record; take a look at RFC6341 for >> >> more info. >> >> http://datatracker.ietf.org/doc/rfc6341/ >> > >> >SIPREC supports numerous topologies. >> >It would support the one that Matt outlines as well as end-user >> >controlled ones. >> > >> >I found Matt's use case interesting. I think it would be nice if such >> >services were available in that form. But I have difficulty imagining >> >any of the VoIP providers I'm aware of supporting this model. My >> >impression is that this means that they are giving up a value added >> >revenue market, that they are loath to do. The most likely justification >> >I can imagine that they don't want to legal consequences of doing >> >recording. >> > >> > Thanks, >> > Paul >> > >> >> For these use cases, where the user is in control, you need to away to >> >> authenticate and control which users are allowed to record and the >> level >> >> of service provided for that specific user. >> >> This is where the solutions provided in section 3 or section 4 of the >> >> SIP OAuth proposal come into play. >> >> Obviously, in this case the authorization server is different from >> >> authorization server used to establish the trust relationship between >> >> the VoIP Provider and the CRS Provider. >> >> In this case, the authorization server must authenticate the user and >> >> provide his UA with an access token or a code that controls the user's >> >> access to the service. >> >> >> >> Regards, >> >> Rifaat >> >> >> >> >> >> >> >> On Sat, Aug 23, 2014 at 9:05 AM, Matt Ryan > >> > wrote: >> >> >> >> Included is the use case I spoke of before. My apologies for the >> >>delay. >> >> >> >> This is written as though it could be included in >> >> [draft-yusef-sipcore-sip-oauth] at section 6. >> >> >> >> >> >> 6. Examples >> >> >> >> 6.1. Example: Call Recording Service >> >> >> >> This example illustrates the use of SIP OAuth between three >> >> parties: A hosted VoIP service provider, a Call Recording Service >> >> provider, and a phone system end-user. In this example: >> >> - The phone system end-user is a customer of both the hosted VoIP >> >> provider and the Call Recording Service provider >> >> - The hosted VoIP service provider is a standard provider of hosted >> >> business-class VoIP telephone service using SIP >> >> - The Call Recording Service provider is a distinct entity from the >> >> hosted VoIP provider >> >> >> >> The Call Recording Service provides to customers both the call >> >> recording abilities and management of call recordings >> >> (configuration, sharing and distribution, retention, etc.). This >> >> service can accept and record RTP traffic, associate all RTP >> streams >> >> with a single call together, and store and catalog the recorded >> data >> >> for future searching and retrieval. The service also offers a web >> >> interface where customers may view and retrieve stored calls. >> >> Stored calls may range from simple person-to-person voice calls to >> >> multi-party conferences with a multitude of audio and video >> >> streams. In this example, customers are billed based on the amount >> >> of data they store, although other models are certainly possible. >> >> >> >> 6.1.1. OAuth 2.0 Roles >> >> >> >> In this example, each party assumes the following OAuth 2.0 roles >> as >> >> defined in [RFC6749] Section 1.1: >> >> - The end-user assumes the role of resource owner >> >> - The hosted VoIP service provider assumes the role of client >> >> - The Call Recording Service provider assumes the role of resource >> >> server as well as the role of authorization server >> >> >> >> 6.1.2. Description >> >> >> >> There are two parts to the example: Initial configuration and >> >> real-time recording authorization. >> >> >> >> Each section includes a simplified flow diagram for the purpose of >> >> describing the corresponding portion of the example. For the sake >> >> of brevity, certain parts of the OAuth dialog have been eliminated. >> >> Implements should refer to [RFC6749] for details on OAuth. >> >> >> >> 6.1.2.1 Initial Configuration >> >> >> >> +-------------+ +---------------+ +--------------+ >> >> | End-User | | VoIP Provider | | CRS Provider | >> >> | Web Browser | | Website | | | >> >> +-------------+ +---------------+ +--------------+ >> >> | | | >> >> | HTTP 1 | | >> >> | (Configure CRS) | | >> >> |------------------->| | >> >> | | | >> >> | HTTP 2 | | >> >> | (OAuth Redirect | | >> >> | to CRS Website) | | >> >> |<-------------------| | >> >> | | | >> >> | HTTP 3 | | >> >> | (Authorize SIP from VoIP provider | >> >> |----------------------------------------->| >> >> | | | >> >> | HTTP 4 | | >> >> | (OAuth Redirect back to VoIP portal) | >> >> |<-----------------------------------------| >> >> | | | >> >> | HTTP 5 | | >> >> |------------------->| | >> >> | | HTTP 6 | >> >> | | (Request Access and | >> >> | | refresh tokens) | >> >> | |-------------------->| >> >> | | | >> >> >> >> Some time after having signed up for both services, but prior to >> >> attempting to record any calls, the end-user logs into the web >> >> portal of the hosted VoIP provider with a web browser and >> configures >> >> their call recording service (HTTP 1). This configuration includes >> >> providing a URI where the call recording service may be reached, >> >> along with a set of API credentials, provided by the call recording >> >> service, which will allow the client to initiate an OAuth exchange. >> >> The end-user also configures the conditions under which call >> >> recordings should take place. For example, the end-user may >> request >> >> to record every multi-party (conference) call, or every call >> >> involving a specific set of users. The end-user may also specify >> >> other restrictions, such as restricting codec negotiation to G.711u >> >> for audio and H.264 for video in order to record the RTP streams. >> >> Once the end-user saves the configuration, the hosted VoIP provider >> >> web portal redirects the end-user's web browser to the call >> >> recording service website and a standard HTTP OAuth dialog begins >> >> (HTTP 2). The end-user authorizes the hosted VoIP provider to >> >> access (i.e. send SIP and RTP traffic to) the call recording >> >> service, for the purpose of recording calls, so long as the >> >> configured conditions are met (HTTP 3). The result of this >> >> interaction is that the hosted VoIP provider ends up receiving an >> >> OAuth access token and refresh token from the call recording >> service >> >> (HTTP 4, HTTP 5, HTTP 6). These tokens are saved in the end-user's >> >> hosted VoIP account database. >> >> >> >> 6.1.2.2 Real-time Recording Authorization >> >> >> >> +-------------+ +---------------+ +--------------+ >> >> | End-User | | VoIP Provider | | CRS Provider | >> >> | SIP Phone | | Website | | | >> >> +-------------+ +---------------+ +--------------+ >> >> | | | >> >> | SIP INVITE 1 | | >> >> |------------------->| | >> >> | | SIP INVITE 2 | >> >> | | (with access token) | >> >> | |--------------------->| >> >> | | | >> >> | | SIP 401 Unauthorized | >> >> | |<---------------------| >> >> | | | >> >> | | SIP INVITE 3 | >> >> | | (with refresh token) | >> >> | |--------------------->| >> >> | | | >> >> | | SIP 200 1 | >> >> | | (new access token) | >> >> | |<---------------------| >> >> | | | >> >> | | SIP INVITE 4 | >> >> | | (with access token) | >> >> | |--------------------->| >> >> | | | >> >> | | SIP 200 2 | >> >> | |<---------------------| >> >> | | | >> >> >> >> Independently of and after the initial configuration phase, the >> >> end-user makes a telephone call using the hosted VoIP provider (SIP >> >> INVITE 1). When this call takes place, the hosted VoIP provider >> >> looks to see whether it believes this call should be recorded. If >> >> so, at this point it would branch the call session to the call >> >> recording service, using SIP OAuth to pass the previously provided >> >> access token for authorization (SIP INVITE 2). Once the access >> >> token is validated by the call recording service (perhaps after >> >> first providing a new access token based on receipt of a valid >> >> refresh token), the call recording service will check the rights >> >> that were previously authorized and examine the SIP to determine >> >> whether it can accept the call. If so, it completes the >> >> establishment of the session and begins receiving and recording the >> >> RTP stream(s) (SIP 200 OK). The call recording service provider >> >> could also deny the request, either because the tokens are invalid >> >> or because the content of >> >> the SIP invite does not match the previously authorized >> >> conditions, in which case a SIP 403 would be returned by the call >> >> recording service provider and the call would not be recorded - >> >> however, the initial call branch would continue without >> >>interruption. >> >> >> >> Note: >> >> [RFC6749] specifies that when a client uses a refresh token to >> >> request a new access token, the response is HTTP 200 with the new >> >> access token and optionally a new refresh token included in the >> >> payload. In this example, a SIP 200 response (SIP 200 1) is sent >> >> which contains the new token(s). However, this could be confusing >> >> as SIP 200 is generally viewed as the acceptance of the INVITE, >> >> which is not what is happening in this case. Should SIP 200 be >> used >> >> for consistency, or should another mechanism be used? >> >> >> >> 6.1.3. Justification >> >> >> >> 6.1.3.1. Hosted VoIP Service Provider >> >> >> >> In this example, the hosted VoIP service provider can allow their >> >> customers to enable call recording in their VoIP service by >> >> selecting from any of a number of supported call recording service >> >> providers. This allows the hosted VoIP service provider to offer >> >> this feature to customers without requiring that the hosted VoIP >> >> service provider implement and support this feature themselves. >> >> >> >> 6.1.3.2. Call Recording Service Provider >> >> >> >> In this example, the Call Recording Service provider can focus on >> >> value and innovation in the area of recording calls and managing >> >> recorded calls without having to build a full-featured telephony >> >> offering. >> >> >> >> 6.1.3.3. Customer >> >> >> >> In this example, the customer has more flexibility in choosing a >> >> complete solution that meets all of the customer needs. The >> >> customer does not have to settle for a substandard call recording >> >> service offering in order to obtain other features they seek in a >> >> hosted VoIP provider, and vice versa. >> >> >> >> 6.1.4. Variants >> >> >> >> A simple variant of this example is one wherein one of the services >> >> (either the VoIP service or the call recording service) is managed >> >> directly by the end-user, but the other is not. For example, the >> >> end-user may wish to make use of an external hosted VoIP service >> >> provider, but may have business or legal reasons that forbid the >> >> end-user from allowing a third party to store and manage recorded >> >> calls. The end-user could choose to set up their own call >> recording >> >> service as described in this example, and use SIP OAuth to >> >> facilitate interaction between the hosted VoIP service and the >> >> end-user's own call recording service. >> >> >> >> 6.2. Other SIP OAuth examples >> >> >> >> Many other SIP-based services could leverage SIP OAuth to provide >> >> value-added service to an end-user of a hosted VoIP service >> >> provider. Some examples of these types of services are listed >> >>below. >> >> >> >> Voicemail service provider: The end-user configures their hosted >> >> VoIP service provider to manage voicemail through a separate >> >> voicemail service provider, which chooses whether to store >> voicemail >> >> based on existing quotas, Caller ID, etc. >> >> >> >> Conferencing service provider: A conferencing service may wish to >> >> bill customers in a more granular fashion, for example, based on >> the >> >> number of participants and attendees in a conference, the duration >> >> of conference, whether video was also included, which codecs were >> >> being used, etc. instead of a flat monthly rate. SIP OAuth would >> >> facilitate metered authorization for a client's use of the service, >> >> instead of all-or-nothing access. >> >> >> >> Call center service provider: A third party may provide ring >> groups >> >> or call queues for a hosted VoIP provider along with detailed >> >> reports and dashboards. The end-user uses OAuth over SIP to >> control >> >> who can log into which queues or ring groups, etc. >> >> >> >> >> >> >> >> -- >> >> Matt Ryan >> >> code slinger | zoomulus.com >> >> ietf at mvryan dot org >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> sipcore mailing list >> >> sipcore@ietf.org >> >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> sipcore mailing list >> >> sipcore@ietf.org >> >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> > >> >_______________________________________________ >> >sipcore mailing list >> >sipcore@ietf.org >> >https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > --089e013d1c46cddcdd0502f776f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 4, 2014 at 7:27 PM, Peterson, Jon <jon.peterson@neu= star.biz> wrote:

I understand that OAuth can be altered from its basic flows to provide= tokens for OpenID, and IdP could be bound to OAuth, and while this is all = very interesting it doesn't change much about the requirements discussi= on I think we need to have: the one about what kinds of use cases we want to satisfy and who the relying parti= es are in those cases. Once we understand that, we will understand what too= ls are applicable to these use cases - preferably, not tools that need to b= e twisted into a different shape to be applicable.


Well, OpenID extends = the OAuth 2.0 Framework to authenticate the user; why do you think it is &q= uot;twisting" OAuth into a different shape?

<= br>
=A0
It would helpful, in the enterprise SSO case, for us to understand wha= t kinds of application servers a user might need to access, and what exactl= y those application servers need to know about the user in order to accompl= ish their function.


Below is a descriptio= n for some enterprise issues, that hopefully will be addressed by a new aut= horization framework:


* Multiple Identities One of the major issues in the enterprise is the need for a user to obtain multiple uncorrelated identities associated with different products to get access to the various services provided by the enterprise. For example, in the enterprise the user will be provided with different ide= ntities to: o Login his device (PC, laptop, mobile, ...) to the network. o Register to the SIP network and get basic SIP services. o Access his Voice Mail. o Host a conference. o etc Typically, these identities belong to different administrative domains and = realms. Instead of these multiple identities, ideally the enterprise would like to create and maintain only one identity for the user and then allow the user access to all SIP and non-SIP services using that one identity. * Authorization of Access to Services Another issue in the enterprise is the need to control and authorize a user access to services. Because application servers have their own user directo= ry, the control of access to services is spread over a multitude of servers in = the network. Ideally, the enterprise would like to manage the access to services using one centralized entity and for the various entities that provide the service to become the enforcement points. * Assignment of Services In the enterprise, different users might be assigned to different servers providing a specific service; e.g. Voice Mail Box for different users might= be hosted by different servers, and the user need to know his assigned server to be able to get access to this service. * Application Servers To be able to provide service, the application server needs a list of users allowed to get services. The application server needs the following pieces = of information about each user: 1. User ID and Credentials 2. Profile to control the level of service provided to the user. If one application server provides different services using different proto= cols, the application server might need to maintain different identities associat= ed with these protocols; e.g. an application server that provides presence ser= vice using SIP, and IM service using XMPP. Ideally, an authorization framework would: 1. Off load the application server from the need to manage the user credent= ials and authenticating the user. 2. Off load the application server from the need to maintain the users and = their profiles to control the level of service provided to the user. 3. Allow the assignment of a user to a specific application server. * OAuth/OpenID Model With the OAuth/OpenID framework, the user ID and credentials will be handle= d by the authorization server, and the application server assignment and the level of service associated with the user will be provided in the scope of = the token associated with the user. When the application server receives a request from a user it will have all= the details that would allow the application server to validate the request to make sure it is coming from the right authorization server, and to act upon the request because it has the scope associated with the user, without the need to contact the authorization server. * Relying Party Regarding the Relying Party question: I think that when the user is being authenticated, that the Relying Party would be the SIP Client that would be given a user token (ID Token in OpenID lingo) to access services on behalf of the end user. So, the mapping would be something like this: +------------------------+-----------------------------+ | OAuth | SIP | +------------------------+-----------------------------+ | Resource Owner | End User | | Resource Server | SIP Proxy or SIP App Server | | Client | SIP UA (Relying Party) | | Authorization Server | Authorization Server | +------------------------+-----------------------------+


=
Regards,
=A0Rifaat


=



=A0
Jon Peterson
Neustar, Inc.





On Wed, Sep 3, 2014 at 4:00 PM, Peterson, Jon <jon.peter= son@neustar.biz> wrote:

While I would echo Paul's thoughts below about the plausibility of serv= ice
providers using this model to authorize recording, I also agree that
third-party recording is an excellent example of a service architecture
that requires an authorization mechanism like OAuth. An end user needs to authorize a third party to participate in the session under certain
constraints, and coordinate the association between the third party and
the VoIP service. This example also (rightly, in my opinion) conducts the majority of the flow in HTTP where it belongs.


I agree with that.

=A0
Many of the use cases under discussion in this thread, though, are of the form where there are really only two involved parties: an end user and a service provider. If you are my service provider, then in traditional SIP I share a secret with you that I use to REGISTER my devices. I don't th= ink
you need OAuth for that.

If you assume that there is one server that provides all the services,= then you are right.
But that is not the case all the time. I think that Dale articulated t= hat clearly in the following response:

=A0
I do understand that OAuth 2.0 is used in the
wild for SSO, though I sympathize with Matt that the base flow shown in
RFC6749 Sec 1.2 just doesn't map onto the requirements for SSO.


I agree that the OAuth 2.0 "as is" does not address the SSO = requirements.
The SIP OAuth proposal is not just using OAuth 2.0 "as is", = but it is extending the framework to authenticate and provide a *user* spec= ific token.

Since Matt mentioned OpenID few times, I looked at the OpenID specific= ation.
What they are doing there is that they defined a new token, called ID = Token, that is associated with the *user*; which is exactly what the SIP OA= uth proposal is doing.

My plan is to use the same terminology, ID Token, in the next version = of the SIP OAuth document to clarify that, and to differentiate it from the= access token.

=A0
I think, though, we might usefully break uses cases here down by who the intended relying party is:

- The user's own SIP service provider (my enterprise, my carrier, my OT= T
provider)
- A third party that a user wants to authorize for a service (recording
service... But anything else?)

I would also append some use cases where the relying party:

- Someone with no association with the user (caller ID sorts of cases)

This last is where I've argued things like IdP might be relevant.


EKR has a nice description for binding IdP to OAuth in his WebRTC Secu= rity Architecture document here:

We could use the same idea for SIP.


Regards,
=A0Rifaat


=A0
Are there any other high-level buckets of use cases here?

Jon Peterson
Neustar, Inc.

On 8/25/14, 11:44 AM, "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote:

>On 8/25/14 11:50 AM, Rifaat Shekh-Yusef wrote:
>> Hi Matt,
>>
>> The use case and the solution provided assumes that the VoIP Provi= der
>> makes the decision on when and what to record.
>> While this is a valid use case, there are other use cases that all= ow the
>> user to decide on when and what to record; take a look at RFC6341 = for
>> more info.
>> http://datatracker.ietf.org/doc/rfc6341/
>
>SIPREC supports numerous topologies.
>It would support the one that Matt outlines as well as end-user
>controlled ones.
>
>I found Matt's use case interesting. I think it would be nice if su= ch
>services were available in that form. But I have difficulty imagining >any of the VoIP providers I'm aware of supporting this model. My >impression is that this means that they are giving up a value added
>revenue market, that they are loath to do. The most likely justificatio= n
>I can imagine that they don't want to legal consequences of doing >recording.
>
>=A0 =A0 =A0 =A0Thanks,
>=A0 =A0 =A0 =A0Paul
>
>> For these use cases, where the user is in control, you need to awa= y to
>> authenticate and control which users are allowed to record and the= level
>> of service provided for that specific user.
>> This is where the solutions provided in section 3 or section 4 of = the
>> SIP OAuth proposal come into play.
>> Obviously, in this case the authorization server is different from=
>> authorization server used to establish the trust relationship betw= een
>> the VoIP Provider and the CRS Provider.
>> In this case, the authorization server must authenticate the user = and
>> provide his UA with an access token or a code that controls the us= er's
>> access to the service.
>>
>> Regards,
>>=A0 =A0Rifaat
>>
>>
>>
>> On Sat, Aug 23, 2014 at 9:05 AM, Matt Ryan <ietf@mvryan.org
>> <mailto:ie= tf@mvryan.org>> wrote:
>>
>>=A0 =A0 =A0Included is the use case I spoke of before.=A0 My apolog= ies for the
>>delay.
>>
>>=A0 =A0 =A0This is written as though it could be included in
>>=A0 =A0 =A0[draft-yusef-sipcore-sip-oauth] at section 6.
>>
>>
>>=A0 =A0 =A06. Examples
>>
>>=A0 =A0 =A06.1. Example: Call Recording Service
>>
>>=A0 =A0 =A0This example illustrates the use of SIP OAuth between th= ree
>>=A0 =A0 =A0parties:=A0 A hosted VoIP service provider, a Call Recor= ding Service
>>=A0 =A0 =A0provider, and a phone system end-user.=A0 In this exampl= e:
>>=A0 =A0 =A0- The phone system end-user is a customer of both the ho= sted VoIP
>>=A0 =A0 =A0provider and the Call Recording Service provider
>>=A0 =A0 =A0- The hosted VoIP service provider is a standard provide= r of hosted
>>=A0 =A0 =A0business-class VoIP telephone service using SIP
>>=A0 =A0 =A0- The Call Recording Service provider is a distinct enti= ty from the
>>=A0 =A0 =A0hosted VoIP provider
>>
>>=A0 =A0 =A0The Call Recording Service provides to customers both th= e call
>>=A0 =A0 =A0recording abilities and management of call recordings >>=A0 =A0 =A0(configuration, sharing and distribution, retention, etc= .).=A0 This
>>=A0 =A0 =A0service can accept and record RTP traffic, associate all= RTP streams
>>=A0 =A0 =A0with a single call together, and store and catalog the r= ecorded data
>>=A0 =A0 =A0for future searching and retrieval.=A0 The service also = offers a web
>>=A0 =A0 =A0interface where customers may view and retrieve stored c= alls.
>>=A0 =A0 =A0Stored calls may range from simple person-to-person voic= e calls to
>>=A0 =A0 =A0multi-party conferences with a multitude of audio and vi= deo
>>=A0 =A0 =A0streams.=A0 In this example, customers are billed based = on the amount
>>=A0 =A0 =A0of data they store, although other models are certainly = possible.
>>
>>=A0 =A0 =A06.1.1. OAuth 2.0 Roles
>>
>>=A0 =A0 =A0In this example, each party assumes the following OAuth = 2.0 roles as
>>=A0 =A0 =A0defined in [RFC6749] Section 1.1:
>>=A0 =A0 =A0- The end-user assumes the role of resource owner
>>=A0 =A0 =A0- The hosted VoIP service provider assumes the role of c= lient
>>=A0 =A0 =A0- The Call Recording Service provider assumes the role o= f resource
>>=A0 =A0 =A0server as well as the role of authorization server
>>
>>=A0 =A0 =A06.1.2. Description
>>
>>=A0 =A0 =A0There are two parts to the example:=A0 Initial configura= tion and
>>=A0 =A0 =A0real-time recording authorization.
>>
>>=A0 =A0 =A0Each section includes a simplified flow diagram for the = purpose of
>>=A0 =A0 =A0describing the corresponding portion of the example.=A0 = For the sake
>>=A0 =A0 =A0of brevity, certain parts of the OAuth dialog have been = eliminated.
>>=A0 =A0 =A0Implements should refer to [RFC6749] for details on OAut= h.
>>
>>=A0 =A0 =A06.1.2.1 Initial Configuration
>>
>>=A0 =A0 =A0 =A0 +-------------+=A0 =A0 =A0+---------------+=A0 =A0 = =A0+--------------+
>>=A0 =A0 =A0 =A0 |=A0 End-User=A0 =A0|=A0 =A0 =A0| VoIP Provider |= =A0 =A0 =A0| CRS Provider |
>>=A0 =A0 =A0 =A0 | Web Browser |=A0 =A0 =A0|=A0 =A0 Website=A0 =A0 |= =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 +-------------+=A0 =A0 =A0+---------------+=A0 =A0 = =A0+--------------+
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| HTTP 1=A0 =A0 =A0 =A0 =A0 =A0 =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| (Configure CRS)=A0 =A0 |=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|------------------->|=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| HTTP 2=A0 =A0 =A0 =A0 =A0 =A0 =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| (OAuth Redirect=A0 =A0 |=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 to CRS Website)=A0 =A0|=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<-------------------|=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| HTTP 3=A0 =A0 =A0 =A0 =A0 =A0 =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| (Authorize SIP from VoIP provider= =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|-----------------------------------= ------>|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| HTTP 4=A0 =A0 =A0 =A0 =A0 =A0 =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| (OAuth Redirect back to VoIP porta= l)=A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<-------------------------------= ----------|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| HTTP 5=A0 =A0 =A0 =A0 =A0 =A0 =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|------------------->|=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | HTTP 6=A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | (Request Access and |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 refresh tokens)=A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |-------------------->|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>
>>=A0 =A0 =A0Some time after having signed up for both services, but = prior to
>>=A0 =A0 =A0attempting to record any calls, the end-user logs into t= he web
>>=A0 =A0 =A0portal of the hosted VoIP provider with a web browser an= d configures
>>=A0 =A0 =A0their call recording service (HTTP 1).=A0 This configura= tion includes
>>=A0 =A0 =A0providing a URI where the call recording service may be = reached,
>>=A0 =A0 =A0along with a set of API credentials, provided by the cal= l recording
>>=A0 =A0 =A0service, which will allow the client to initiate an OAut= h exchange.
>>=A0 =A0 =A0The end-user also configures the conditions under which = call
>>=A0 =A0 =A0recordings should take place.=A0 For example, the end-us= er may request
>>=A0 =A0 =A0to record every multi-party (conference) call, or every = call
>>=A0 =A0 =A0involving a specific set of users.=A0 The end-user may a= lso specify
>>=A0 =A0 =A0other restrictions, such as restricting codec negotiatio= n to G.711u
>>=A0 =A0 =A0for audio and H.264 for video in order to record the RTP= streams.
>>=A0 =A0 =A0Once the end-user saves the configuration, the hosted Vo= IP provider
>>=A0 =A0 =A0web portal redirects the end-user's web browser to t= he call
>>=A0 =A0 =A0recording service website and a standard HTTP OAuth dial= og begins
>>=A0 =A0 =A0(HTTP 2).=A0 The end-user authorizes the hosted VoIP pro= vider to
>>=A0 =A0 =A0access (i.e. send SIP and RTP traffic to) the call recor= ding
>>=A0 =A0 =A0service, for the purpose of recording calls, so long as = the
>>=A0 =A0 =A0configured conditions are met (HTTP 3).=A0 The result of= this
>>=A0 =A0 =A0interaction is that the hosted VoIP provider ends up rec= eiving an
>>=A0 =A0 =A0OAuth access token and refresh token from the call recor= ding service
>>=A0 =A0 =A0(HTTP 4, HTTP 5, HTTP 6).=A0 These tokens are saved in t= he end-user's
>>=A0 =A0 =A0hosted VoIP account database.
>>
>>=A0 =A0 =A06.1.2.2 Real-time Recording Authorization
>>
>>=A0 =A0 =A0 =A0 +-------------+=A0 =A0 =A0+---------------+=A0 =A0 = =A0 +--------------+
>>=A0 =A0 =A0 =A0 |=A0 End-User=A0 =A0|=A0 =A0 =A0| VoIP Provider |= =A0 =A0 =A0 | CRS Provider |
>>=A0 =A0 =A0 =A0 |=A0 SIP Phone=A0 |=A0 =A0 =A0|=A0 =A0 Website=A0 = =A0 |=A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 +-------------+=A0 =A0 =A0+---------------+=A0 =A0 = =A0 +--------------+
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| SIP INVITE 1=A0 =A0 =A0 =A0|=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|------------------->|=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP INVITE 2=A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | (with access token)=A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |--------------------->|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP 401 Unauthorized |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |<---------------------|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP INVITE 3=A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | (with refresh token) |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |--------------------->|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP 200 1=A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | (new access token)=A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |<---------------------|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP INVITE 4=A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | (with access token)=A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |--------------------->|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP 200 2=A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |<---------------------|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>
>>=A0 =A0 =A0Independently of and after the initial configuration pha= se, the
>>=A0 =A0 =A0end-user makes a telephone call using the hosted VoIP pr= ovider (SIP
>>=A0 =A0 =A0INVITE 1).=A0 When this call takes place, the hosted VoI= P provider
>>=A0 =A0 =A0looks to see whether it believes this call should be rec= orded.=A0 If
>>=A0 =A0 =A0so, at this point it would branch the call session to th= e call
>>=A0 =A0 =A0recording service, using SIP OAuth to pass the previousl= y provided
>>=A0 =A0 =A0access token for authorization (SIP INVITE 2).=A0 Once t= he access
>>=A0 =A0 =A0token is validated by the call recording service (perhap= s after
>>=A0 =A0 =A0first providing a new access token based on receipt of a= valid
>>=A0 =A0 =A0refresh token), the call recording service will check th= e rights
>>=A0 =A0 =A0that were previously authorized and examine the SIP to d= etermine
>>=A0 =A0 =A0whether it can accept the call.=A0 If so, it completes t= he
>>=A0 =A0 =A0establishment of the session and begins receiving and re= cording the
>>=A0 =A0 =A0RTP stream(s) (SIP 200 OK).=A0 The call recording servic= e provider
>>=A0 =A0 =A0could also deny the request, either because the tokens a= re invalid
>>=A0 =A0 =A0or because the content of
>>=A0 =A0 =A0 =A0the SIP invite does not match the previously authori= zed
>>=A0 =A0 =A0conditions, in which case a SIP 403 would be returned by= the call
>>=A0 =A0 =A0recording service provider and the call would not be rec= orded -
>>=A0 =A0 =A0however, the initial call branch would continue without<= br> >>interruption.
>>
>>=A0 =A0 =A0Note:
>>=A0 =A0 =A0[RFC6749] specifies that when a client uses a refresh to= ken to
>>=A0 =A0 =A0request a new access token, the response is HTTP 200 wit= h the new
>>=A0 =A0 =A0access token and optionally a new refresh token included= in the
>>=A0 =A0 =A0payload.=A0 In this example, a SIP 200 response (SIP 200= 1) is sent
>>=A0 =A0 =A0which contains the new token(s).=A0 However, this could = be confusing
>>=A0 =A0 =A0as SIP 200 is generally viewed as the acceptance of the = INVITE,
>>=A0 =A0 =A0which is not what is happening in this case.=A0 Should S= IP 200 be used
>>=A0 =A0 =A0for consistency, or should another mechanism be used? >>
>>=A0 =A0 =A06.1.3. Justification
>>
>>=A0 =A0 =A06.1.3.1. Hosted VoIP Service Provider
>>
>>=A0 =A0 =A0In this example, the hosted VoIP service provider can al= low their
>>=A0 =A0 =A0customers to enable call recording in their VoIP service= by
>>=A0 =A0 =A0selecting from any of a number of supported call recordi= ng service
>>=A0 =A0 =A0providers.=A0 This allows the hosted VoIP service provid= er to offer
>>=A0 =A0 =A0this feature to customers without requiring that the hos= ted VoIP
>>=A0 =A0 =A0service provider implement and support this feature them= selves.
>>
>>=A0 =A0 =A06.1.3.2. Call Recording Service Provider
>>
>>=A0 =A0 =A0In this example, the Call Recording Service provider can= focus on
>>=A0 =A0 =A0value and innovation in the area of recording calls and = managing
>>=A0 =A0 =A0recorded calls without having to build a full-featured t= elephony
>>=A0 =A0 =A0offering.
>>
>>=A0 =A0 =A06.1.3.3. Customer
>>
>>=A0 =A0 =A0In this example, the customer has more flexibility in ch= oosing a
>>=A0 =A0 =A0complete solution that meets all of the customer needs.= =A0 The
>>=A0 =A0 =A0customer does not have to settle for a substandard call = recording
>>=A0 =A0 =A0service offering in order to obtain other features they = seek in a
>>=A0 =A0 =A0hosted VoIP provider, and vice versa.
>>
>>=A0 =A0 =A06.1.4. Variants
>>
>>=A0 =A0 =A0A simple variant of this example is one wherein one of t= he services
>>=A0 =A0 =A0(either the VoIP service or the call recording service) = is managed
>>=A0 =A0 =A0directly by the end-user, but the other is not.=A0 For e= xample, the
>>=A0 =A0 =A0end-user may wish to make use of an external hosted VoIP= service
>>=A0 =A0 =A0provider, but may have business or legal reasons that fo= rbid the
>>=A0 =A0 =A0end-user from allowing a third party to store and manage= recorded
>>=A0 =A0 =A0calls.=A0 The end-user could choose to set up their own = call recording
>>=A0 =A0 =A0service as described in this example, and use SIP OAuth = to
>>=A0 =A0 =A0facilitate interaction between the hosted VoIP service a= nd the
>>=A0 =A0 =A0end-user's own call recording service.
>>
>>=A0 =A0 =A06.2. Other SIP OAuth examples
>>
>>=A0 =A0 =A0Many other SIP-based services could leverage SIP OAuth t= o provide
>>=A0 =A0 =A0value-added service to an end-user of a hosted VoIP serv= ice
>>=A0 =A0 =A0provider.=A0 Some examples of these types of services ar= e listed
>>below.
>>
>>=A0 =A0 =A0Voicemail service provider:=A0 The end-user configures t= heir hosted
>>=A0 =A0 =A0VoIP service provider to manage voicemail through a sepa= rate
>>=A0 =A0 =A0voicemail service provider, which chooses whether to sto= re voicemail
>>=A0 =A0 =A0based on existing quotas, Caller ID, etc.
>>
>>=A0 =A0 =A0Conferencing service provider:=A0 A conferencing service= may wish to
>>=A0 =A0 =A0bill customers in a more granular fashion, for example, = based on the
>>=A0 =A0 =A0number of participants and attendees in a conference, th= e duration
>>=A0 =A0 =A0of conference, whether video was also included, which co= decs were
>>=A0 =A0 =A0being used, etc. instead of a flat monthly rate.=A0 SIP = OAuth would
>>=A0 =A0 =A0facilitate metered authorization for a client's use = of the service,
>>=A0 =A0 =A0instead of all-or-nothing access.
>>
>>=A0 =A0 =A0Call center service provider:=A0 A third party may provi= de ring groups
>>=A0 =A0 =A0or call queues for a hosted VoIP provider along with det= ailed
>>=A0 =A0 =A0reports and dashboards.=A0 The end-user uses OAuth over = SIP to control
>>=A0 =A0 =A0who can log into which queues or ring groups, etc.
>>
>>
>>
>>=A0 =A0 =A0--
>>=A0 =A0 =A0Matt Ryan
>>=A0 =A0 =A0code slinger | zoomulus.com <http://zoomulus.com>
>>=A0 =A0 =A0ietf at mvryan dot org
>>
>>
>>
>>
>>=A0 =A0 =A0_______________________________________________
>>=A0 =A0 =A0sipcore mailing list
>>=A0 =A0 =A0si= pcore@ietf.org <mailto:sipcore@ietf.org>
>>=A0 =A0 =A0https://www.ietf.org/mailman/listinfo/sipcore
>>
>>
>>
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf= .org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>
>_______________________________________________
>sipcore mailing list
>sipcore@ietf.org<= /a>
>https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--089e013d1c46cddcdd0502f776f2-- From nobody Mon Sep 15 12:29:59 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835A21A0391 for ; Mon, 15 Sep 2014 12:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.866 X-Spam-Level: X-Spam-Status: No, score=-98.866 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HLqo8qHiZJC for ; Mon, 15 Sep 2014 12:29:52 -0700 (PDT) Received: from mx0a-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B41B51A0026 for ; Mon, 15 Sep 2014 12:29:52 -0700 (PDT) Received: from pps.filterd (m0049402.ppops.net [127.0.0.1]) by m0049402.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s8FJErCI022850; Mon, 15 Sep 2014 15:29:48 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049402.ppops.net-0018ba01. with ESMTP id 1pdmk4tpxa-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Sep 2014 15:29:47 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.97]) by stntexhc10.cis.neustar.com ([169.254.4.83]) with mapi id 14.03.0158.001; Mon, 15 Sep 2014 15:29:45 -0400 From: "Peterson, Jon" To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] A SIP OAuth use case Thread-Index: AQHPvtLmZYbTlD+FuE+zMNKWASQKqZvhvfeAgAAwjgCADcUOgIABvEuAgAAP2QCADliiAIACroIA Date: Mon, 15 Sep 2014 19:29:45 +0000 Message-ID: References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> <53FB83FA.8010101@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [192.168.128.148] Content-Type: multipart/alternative; boundary="_000_D03C75E8133DCFjonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7562 signatures=670520 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409150162 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/VTrOEi-osifLYaudwCdUInVmdP0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 19:29:57 -0000 --_000_D03C75E8133DCFjonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Format snags aside, I have a bit of difficulty even differentiating the iss= ues listed below: surely the reason why enterprises assign multiple identit= ies per user is to authorize access to different services separately. This = is an issue that could be resolved with an access control list per service = and a trusted identity broker in the enterprise vouching for user identitie= s to these services. But to convince ourselves that one approach to this is= better than another, we need to look at a level of detail below these issu= e descriptions. Again, in order to access a voicemail service in an enterpr= ise, say, what does the voicemail service need to know about the user? Like, for regular access to the voicemail for "jon@enterprise," surely all = the voicemail service needs to know is that the entity authoritative for th= e @enterprise issued me the name "jon." Maybe the "admin" account gets to a= ccess all the voicemails, if need be. There are a variety of mechanisms tha= t suffice to prove simple identities like that to a service. If, however, I= as "jon" needed for a third-party transcription service to access a subset= of the messages in my voicemail box, and I wanted the permissions for that= access to expire as soon as the messages had been transcribed, then there = is a much narrower set of mechanisms that could provide that capability. Bu= t it sounds to me, from this issues list, like your requirements are more a= long the former lines than the latter. Jon Peterson Neustar, Inc. From: Rifaat Shekh-Yusef > Date: Saturday, September 13, 2014 at 12:32 PM To: Jon Peterson = > Cc: Paul Kyzivat >, "si= pcore@ietf.org" > Subject: Re: [sipcore] A SIP OAuth use case On Thu, Sep 4, 2014 at 7:27 PM, Peterson, Jon > wrote: I understand that OAuth can be altered from its basic flows to provide toke= ns for OpenID, and IdP could be bound to OAuth, and while this is all very = interesting it doesn't change much about the requirements discussion I thin= k we need to have: the one about what kinds of use cases we want to satisfy= and who the relying parties are in those cases. Once we understand that, w= e will understand what tools are applicable to these use cases - preferably= , not tools that need to be twisted into a different shape to be applicable= . Well, OpenID extends the OAuth 2.0 Framework to authenticate the user; why = do you think it is "twisting" OAuth into a different shape? It would helpful, in the enterprise SSO case, for us to understand what kin= ds of application servers a user might need to access, and what exactly tho= se application servers need to know about the user in order to accomplish t= heir function. Below is a description for some enterprise issues, that hopefully will be a= ddressed by a new authorization framework: * Multiple Identities One of the major issues in the enterprise is the need= for a user to obtain multiple uncorrelated identities associated with diff= erent products to get access to the various services provided by the enterp= rise. For example, in the enterprise the user will be provided with differe= nt identities to: o Login his device (PC, laptop, mobile, ...) to the netwo= rk. o Register to the SIP network and get basic SIP services. o Access his = Voice Mail. o Host a conference. o etc Typically, these identities belong t= o different administrative domains and realms. Instead of these multiple id= entities, ideally the enterprise would like to create and maintain only one= identity for the user and then allow the user access to all SIP and non-SI= P services using that one identity. * Authorization of Access to Services A= nother issue in the enterprise is the need to control and authorize a user = access to services. Because application servers have their own user directo= ry, the control of access to services is spread over a multitude of servers= in the network. Ideally, the enterprise would like to manage the access to= services using one centralized entity and for the various entities that pr= ovide the service to become the enforcement points. * Assignment of Service= s In the enterprise, different users might be assigned to different servers= providing a specific service; e.g. Voice Mail Box for different users migh= t be hosted by different servers, and the user need to know his assigned se= rver to be able to get access to this service. * Application Servers To be = able to provide service, the application server needs a list of users allow= ed to get services. The application server needs the following pieces of in= formation about each user: 1. User ID and Credentials 2. Profile to control= the level of service provided to the user. If one application server provi= des different services using different protocols, the application server mi= ght need to maintain different identities associated with these protocols; = e.g. an application server that provides presence service using SIP, and IM= service using XMPP. Ideally, an authorization framework would: 1. Off load= the application server from the need to manage the user credentials and au= thenticating the user. 2. Off load the application server from the need to = maintain the users and their profiles to control the level of service provi= ded to the user. 3. Allow the assignment of a user to a specific applicatio= n server. * OAuth/OpenID Model With the OAuth/OpenID framework, the user ID= and credentials will be handled by the authorization server, and the appli= cation server assignment and the level of service associated with the user = will be provided in the scope of the token associated with the user. When t= he application server receives a request from a user it will have all the d= etails that would allow the application server to validate the request to m= ake sure it is coming from the right authorization server, and to act upon = the request because it has the scope associated with the user, without the = need to contact the authorization server. * Relying Party Regarding the Rel= ying Party question: I think that when the user is being authenticated, tha= t the Relying Party would be the SIP Client that would be given a user toke= n (ID Token in OpenID lingo) to access services on behalf of the end user. = So, the mapping would be something like this: +------------------------+---= --------------------------+ | OAuth | SIP | +------------------------+-----= ------------------------+ | Resource Owner | End User | | Resource Server |= SIP Proxy or SIP App Server | | Client | SIP UA (Relying Party) | | Author= ization Server | Authorization Server | +------------------------+---------= --------------------+ Regards, Rifaat Jon Peterson Neustar, Inc. From: Rifaat Shekh-Yusef > Date: Thursday, September 4, 2014 at 8:31 AM To: Jon Peterson = > Cc: Paul Kyzivat >, "si= pcore@ietf.org" > Subject: Re: [sipcore] A SIP OAuth use case On Wed, Sep 3, 2014 at 4:00 PM, Peterson, Jon > wrote: While I would echo Paul's thoughts below about the plausibility of service providers using this model to authorize recording, I also agree that third-party recording is an excellent example of a service architecture that requires an authorization mechanism like OAuth. An end user needs to authorize a third party to participate in the session under certain constraints, and coordinate the association between the third party and the VoIP service. This example also (rightly, in my opinion) conducts the majority of the flow in HTTP where it belongs. I agree with that. Many of the use cases under discussion in this thread, though, are of the form where there are really only two involved parties: an end user and a service provider. If you are my service provider, then in traditional SIP I share a secret with you that I use to REGISTER my devices. I don't think you need OAuth for that. If you assume that there is one server that provides all the services, then= you are right. But that is not the case all the time. I think that Dale articulated that c= learly in the following response: http://www.ietf.org/mail-archive/web/sipcore/current/msg06233.html I do understand that OAuth 2.0 is used in the wild for SSO, though I sympathize with Matt that the base flow shown in RFC6749 Sec 1.2 just doesn't map onto the requirements for SSO. I agree that the OAuth 2.0 "as is" does not address the SSO requirements. The SIP OAuth proposal is not just using OAuth 2.0 "as is", but it is exten= ding the framework to authenticate and provide a *user* specific token. Since Matt mentioned OpenID few times, I looked at the OpenID specification= . What they are doing there is that they defined a new token, called ID Token= , that is associated with the *user*; which is exactly what the SIP OAuth p= roposal is doing. http://openid.net/specs/openid-connect-core-1_0.html#IDToken My plan is to use the same terminology, ID Token, in the next version of th= e SIP OAuth document to clarify that, and to differentiate it from the acce= ss token. I think, though, we might usefully break uses cases here down by who the intended relying party is: - The user's own SIP service provider (my enterprise, my carrier, my OTT provider) - A third party that a user wants to authorize for a service (recording service... But anything else?) I would also append some use cases where the relying party: - Someone with no association with the user (caller ID sorts of cases) This last is where I've argued things like IdP might be relevant. EKR has a nice description for binding IdP to OAuth in his WebRTC Security = Architecture document here: https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10#appendix-A.2 We could use the same idea for SIP. Regards, Rifaat Are there any other high-level buckets of use cases here? Jon Peterson Neustar, Inc. On 8/25/14, 11:44 AM, "Paul Kyzivat" > wrote: >On 8/25/14 11:50 AM, Rifaat Shekh-Yusef wrote: >> Hi Matt, >> >> The use case and the solution provided assumes that the VoIP Provider >> makes the decision on when and what to record. >> While this is a valid use case, there are other use cases that allow the >> user to decide on when and what to record; take a look at RFC6341 for >> more info. >> http://datatracker.ietf.org/doc/rfc6341/ > >SIPREC supports numerous topologies. >It would support the one that Matt outlines as well as end-user >controlled ones. > >I found Matt's use case interesting. I think it would be nice if such >services were available in that form. But I have difficulty imagining >any of the VoIP providers I'm aware of supporting this model. My >impression is that this means that they are giving up a value added >revenue market, that they are loath to do. The most likely justification >I can imagine that they don't want to legal consequences of doing >recording. > > Thanks, > Paul > >> For these use cases, where the user is in control, you need to away to >> authenticate and control which users are allowed to record and the level >> of service provided for that specific user. >> This is where the solutions provided in section 3 or section 4 of the >> SIP OAuth proposal come into play. >> Obviously, in this case the authorization server is different from >> authorization server used to establish the trust relationship between >> the VoIP Provider and the CRS Provider. >> In this case, the authorization server must authenticate the user and >> provide his UA with an access token or a code that controls the user's >> access to the service. >> >> Regards, >> Rifaat >> >> >> >> On Sat, Aug 23, 2014 at 9:05 AM, Matt Ryan >> >> wrote: >> >> Included is the use case I spoke of before. My apologies for the >>delay. >> >> This is written as though it could be included in >> [draft-yusef-sipcore-sip-oauth] at section 6. >> >> >> 6. Examples >> >> 6.1. Example: Call Recording Service >> >> This example illustrates the use of SIP OAuth between three >> parties: A hosted VoIP service provider, a Call Recording Service >> provider, and a phone system end-user. In this example: >> - The phone system end-user is a customer of both the hosted VoIP >> provider and the Call Recording Service provider >> - The hosted VoIP service provider is a standard provider of hosted >> business-class VoIP telephone service using SIP >> - The Call Recording Service provider is a distinct entity from the >> hosted VoIP provider >> >> The Call Recording Service provides to customers both the call >> recording abilities and management of call recordings >> (configuration, sharing and distribution, retention, etc.). This >> service can accept and record RTP traffic, associate all RTP streams >> with a single call together, and store and catalog the recorded data >> for future searching and retrieval. The service also offers a web >> interface where customers may view and retrieve stored calls. >> Stored calls may range from simple person-to-person voice calls to >> multi-party conferences with a multitude of audio and video >> streams. In this example, customers are billed based on the amount >> of data they store, although other models are certainly possible. >> >> 6.1.1. OAuth 2.0 Roles >> >> In this example, each party assumes the following OAuth 2.0 roles as >> defined in [RFC6749] Section 1.1: >> - The end-user assumes the role of resource owner >> - The hosted VoIP service provider assumes the role of client >> - The Call Recording Service provider assumes the role of resource >> server as well as the role of authorization server >> >> 6.1.2. Description >> >> There are two parts to the example: Initial configuration and >> real-time recording authorization. >> >> Each section includes a simplified flow diagram for the purpose of >> describing the corresponding portion of the example. For the sake >> of brevity, certain parts of the OAuth dialog have been eliminated. >> Implements should refer to [RFC6749] for details on OAuth. >> >> 6.1.2.1 Initial Configuration >> >> +-------------+ +---------------+ +--------------+ >> | End-User | | VoIP Provider | | CRS Provider | >> | Web Browser | | Website | | | >> +-------------+ +---------------+ +--------------+ >> | | | >> | HTTP 1 | | >> | (Configure CRS) | | >> |------------------->| | >> | | | >> | HTTP 2 | | >> | (OAuth Redirect | | >> | to CRS Website) | | >> |<-------------------| | >> | | | >> | HTTP 3 | | >> | (Authorize SIP from VoIP provider | >> |----------------------------------------->| >> | | | >> | HTTP 4 | | >> | (OAuth Redirect back to VoIP portal) | >> |<-----------------------------------------| >> | | | >> | HTTP 5 | | >> |------------------->| | >> | | HTTP 6 | >> | | (Request Access and | >> | | refresh tokens) | >> | |-------------------->| >> | | | >> >> Some time after having signed up for both services, but prior to >> attempting to record any calls, the end-user logs into the web >> portal of the hosted VoIP provider with a web browser and configures >> their call recording service (HTTP 1). This configuration includes >> providing a URI where the call recording service may be reached, >> along with a set of API credentials, provided by the call recording >> service, which will allow the client to initiate an OAuth exchange. >> The end-user also configures the conditions under which call >> recordings should take place. For example, the end-user may request >> to record every multi-party (conference) call, or every call >> involving a specific set of users. The end-user may also specify >> other restrictions, such as restricting codec negotiation to G.711u >> for audio and H.264 for video in order to record the RTP streams. >> Once the end-user saves the configuration, the hosted VoIP provider >> web portal redirects the end-user's web browser to the call >> recording service website and a standard HTTP OAuth dialog begins >> (HTTP 2). The end-user authorizes the hosted VoIP provider to >> access (i.e. send SIP and RTP traffic to) the call recording >> service, for the purpose of recording calls, so long as the >> configured conditions are met (HTTP 3). The result of this >> interaction is that the hosted VoIP provider ends up receiving an >> OAuth access token and refresh token from the call recording service >> (HTTP 4, HTTP 5, HTTP 6). These tokens are saved in the end-user's >> hosted VoIP account database. >> >> 6.1.2.2 Real-time Recording Authorization >> >> +-------------+ +---------------+ +--------------+ >> | End-User | | VoIP Provider | | CRS Provider | >> | SIP Phone | | Website | | | >> +-------------+ +---------------+ +--------------+ >> | | | >> | SIP INVITE 1 | | >> |------------------->| | >> | | SIP INVITE 2 | >> | | (with access token) | >> | |--------------------->| >> | | | >> | | SIP 401 Unauthorized | >> | |<---------------------| >> | | | >> | | SIP INVITE 3 | >> | | (with refresh token) | >> | |--------------------->| >> | | | >> | | SIP 200 1 | >> | | (new access token) | >> | |<---------------------| >> | | | >> | | SIP INVITE 4 | >> | | (with access token) | >> | |--------------------->| >> | | | >> | | SIP 200 2 | >> | |<---------------------| >> | | | >> >> Independently of and after the initial configuration phase, the >> end-user makes a telephone call using the hosted VoIP provider (SIP >> INVITE 1). When this call takes place, the hosted VoIP provider >> looks to see whether it believes this call should be recorded. If >> so, at this point it would branch the call session to the call >> recording service, using SIP OAuth to pass the previously provided >> access token for authorization (SIP INVITE 2). Once the access >> token is validated by the call recording service (perhaps after >> first providing a new access token based on receipt of a valid >> refresh token), the call recording service will check the rights >> that were previously authorized and examine the SIP to determine >> whether it can accept the call. If so, it completes the >> establishment of the session and begins receiving and recording the >> RTP stream(s) (SIP 200 OK). The call recording service provider >> could also deny the request, either because the tokens are invalid >> or because the content of >> the SIP invite does not match the previously authorized >> conditions, in which case a SIP 403 would be returned by the call >> recording service provider and the call would not be recorded - >> however, the initial call branch would continue without >>interruption. >> >> Note: >> [RFC6749] specifies that when a client uses a refresh token to >> request a new access token, the response is HTTP 200 with the new >> access token and optionally a new refresh token included in the >> payload. In this example, a SIP 200 response (SIP 200 1) is sent >> which contains the new token(s). However, this could be confusing >> as SIP 200 is generally viewed as the acceptance of the INVITE, >> which is not what is happening in this case. Should SIP 200 be used >> for consistency, or should another mechanism be used? >> >> 6.1.3. Justification >> >> 6.1.3.1. Hosted VoIP Service Provider >> >> In this example, the hosted VoIP service provider can allow their >> customers to enable call recording in their VoIP service by >> selecting from any of a number of supported call recording service >> providers. This allows the hosted VoIP service provider to offer >> this feature to customers without requiring that the hosted VoIP >> service provider implement and support this feature themselves. >> >> 6.1.3.2. Call Recording Service Provider >> >> In this example, the Call Recording Service provider can focus on >> value and innovation in the area of recording calls and managing >> recorded calls without having to build a full-featured telephony >> offering. >> >> 6.1.3.3. Customer >> >> In this example, the customer has more flexibility in choosing a >> complete solution that meets all of the customer needs. The >> customer does not have to settle for a substandard call recording >> service offering in order to obtain other features they seek in a >> hosted VoIP provider, and vice versa. >> >> 6.1.4. Variants >> >> A simple variant of this example is one wherein one of the services >> (either the VoIP service or the call recording service) is managed >> directly by the end-user, but the other is not. For example, the >> end-user may wish to make use of an external hosted VoIP service >> provider, but may have business or legal reasons that forbid the >> end-user from allowing a third party to store and manage recorded >> calls. The end-user could choose to set up their own call recording >> service as described in this example, and use SIP OAuth to >> facilitate interaction between the hosted VoIP service and the >> end-user's own call recording service. >> >> 6.2. Other SIP OAuth examples >> >> Many other SIP-based services could leverage SIP OAuth to provide >> value-added service to an end-user of a hosted VoIP service >> provider. Some examples of these types of services are listed >>below. >> >> Voicemail service provider: The end-user configures their hosted >> VoIP service provider to manage voicemail through a separate >> voicemail service provider, which chooses whether to store voicemail >> based on existing quotas, Caller ID, etc. >> >> Conferencing service provider: A conferencing service may wish to >> bill customers in a more granular fashion, for example, based on the >> number of participants and attendees in a conference, the duration >> of conference, whether video was also included, which codecs were >> being used, etc. instead of a flat monthly rate. SIP OAuth would >> facilitate metered authorization for a client's use of the service, >> instead of all-or-nothing access. >> >> Call center service provider: A third party may provide ring groups >> or call queues for a hosted VoIP provider along with detailed >> reports and dashboards. The end-user uses OAuth over SIP to control >> who can log into which queues or ring groups, etc. >> >> >> >> -- >> Matt Ryan >> code slinger | zoomulus.com >> ietf at mvryan dot org >> >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_D03C75E8133DCFjonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Format snags aside, I have a bit of difficulty even differentiating th= e issues listed below: surely the reason why enterprises assign multiple id= entities per user is to authorize access to different services separately. = This is an issue that could be resolved with an access control list per service and a trusted identity broker in t= he enterprise vouching for user identities to these services. But to convin= ce ourselves that one approach to this is better than another, we need to l= ook at a level of detail below these issue descriptions. Again, in order to access a voicemail service in an en= terprise, say, what does the voicemail service need to know about the user?=

Like, for regular access to the voicemail for "jon@enterprise,&qu= ot; surely all the voicemail service needs to know is that the entity autho= ritative for the @enterprise issued me the name "jon." Maybe the = "admin" account gets to access all the voicemails, if need be. There are a variety of mechanisms that suffice to prove simple id= entities like that to a service. If, however, I as "jon" needed f= or a third-party transcription service to access a subset of the messages i= n my voicemail box, and I wanted the permissions for that access to expire as soon as the messages had been transcribed, th= en there is a much narrower set of mechanisms that could provide that capab= ility. But it sounds to me, from this issues list, like your requirements a= re more along the former lines than the latter. 

Jon Peterson
Neustar, Inc.

From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Saturday, September 13, 2014 = at 12:32 PM
To: Jon Peterson <jon.peterson@neustar.biz>
Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>, "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] A SIP OAuth = use case



On Thu, Sep 4, 2014 at 7:27 PM, Peterson, Jon <jon.peter= son@neustar.biz> wrote:

I understand that OAuth can be altered from its basic flows to provide= tokens for OpenID, and IdP could be bound to OAuth, and while this is all = very interesting it doesn't change much about the requirements discussion I= think we need to have: the one about what kinds of use cases we want to satisfy and who the relying parti= es are in those cases. Once we understand that, we will understand what too= ls are applicable to these use cases - preferably, not tools that need to b= e twisted into a different shape to be applicable.


Well, OpenID extends the OAuth 2.0 Framework to authenticate the user;= why do you think it is "twisting" OAuth into a different shape?<= /div>


 
It would helpful, in the enterprise SSO case, for us to understand wha= t kinds of application servers a user might need to access, and what exactl= y those application servers need to know about the user in order to accompl= ish their function.


Below is a description for some enterprise issues, that hopefully will= be addressed by a new authorization framework:


* Multiple Identitie= s One of the major issues in the enterprise is the need for a user to obtai= n multiple uncorrelated identities associated with different products to get access to the various services p= rovided by the enterprise. For example, in the enterprise the user will be = provided with different identities to: o Login his device (PC, laptop, mobi= le, ...) to the network. o Register to the SIP network and get basic SIP services. o Access his Voice Mail. o = Host a conference. o etc Typically, these identities belong to different ad= ministrative domains and realms. Instead of these multiple identities, idea= lly the enterprise would like to create and maintain only one identity for the user and then allow the user= access to all SIP and non-SIP services using that one identity. * Authoriz= ation of Access to Services Another issue in the enterprise is the need to = control and authorize a user access to services. Because application servers have their own user directory, th= e control of access to services is spread over a multitude of servers in th= e network. Ideally, the enterprise would like to manage the access to servi= ces using one centralized entity and for the various entities that provide the service to become the enforc= ement points. * Assignment of Services In the enterprise, different users m= ight be assigned to different servers providing a specific service; e.g. Vo= ice Mail Box for different users might be hosted by different servers, and the user need to know his assign= ed server to be able to get access to this service. * Application Servers T= o be able to provide service, the application server needs a list of users = allowed to get services. The application server needs the following pieces of information about each user: 1. User = ID and Credentials 2. Profile to control the level of service provided to t= he user. If one application server provides different services using differ= ent protocols, the application server might need to maintain different identities associated with these protocol= s; e.g. an application server that provides presence service using SIP, and= IM service using XMPP. Ideally, an authorization framework would: 1. Off l= oad the application server from the need to manage the user credentials and authenticating the user. 2. Of= f load the application server from the need to maintain the users and their= profiles to control the level of service provided to the user. 3. Allow th= e assignment of a user to a specific application server. * OAuth/OpenID Model With the OAuth/OpenID framework, = the user ID and credentials will be handled by the authorization server, an= d the application server assignment and the level of service associated wit= h the user will be provided in the scope of the token associated with the user. When the application server r= eceives a request from a user it will have all the details that would allow= the application server to validate the request to make sure it is coming f= rom the right authorization server, and to act upon the request because it has the scope associated with the u= ser, without the need to contact the authorization server. * Relying Party = Regarding the Relying Party question: I think that when the user is being a= uthenticated, that the Relying Party would be the SIP Client that would be given a user token (ID Token in Open= ID lingo) to access services on behalf of the end user. So, the mapping wou= ld be something like this: +------------------------+--------------= ---------------+ | OAuth | SIP | +------------------------+----= -------------------------+ | Resource Owner | End User | | Resource Server | SIP Proxy or SIP App Ser= ver | | Client | SIP UA (Relying Party) | | Authorization Server | Authoriz= ation Server | +------------------------+--------------------------= ---+


Regards,
 Rifaat





 
Jon Peterson
Neustar, Inc.





On Wed, Sep 3, 2014 at 4:00 PM, Peterson, Jon <jon.peter= son@neustar.biz> wrote:

While I would echo Paul's thoughts below about the plausibility of service<= br> providers using this model to authorize recording, I also agree that
third-party recording is an excellent example of a service architecture
that requires an authorization mechanism like OAuth. An end user needs to authorize a third party to participate in the session under certain
constraints, and coordinate the association between the third party and
the VoIP service. This example also (rightly, in my opinion) conducts the majority of the flow in HTTP where it belongs.


I agree with that.

 
Many of the use cases under discussion in this thread, though, are of the form where there are really only two involved parties: an end user and a service provider. If you are my service provider, then in traditional SIP I share a secret with you that I use to REGISTER my devices. I don't think<= br> you need OAuth for that.

If you assume that there is one server that provides all the services,= then you are right.
But that is not the case all the time. I think that Dale articulated t= hat clearly in the following response:

 
I do understand that OAuth 2.0 is used in the
wild for SSO, though I sympathize with Matt that the base flow shown in
RFC6749 Sec 1.2 just doesn't map onto the requirements for SSO.


I agree that the OAuth 2.0 "as is" does not address the SSO = requirements.
The SIP OAuth proposal is not just using OAuth 2.0 "as is", = but it is extending the framework to authenticate and provide a *user* spec= ific token.

Since Matt mentioned OpenID few times, I looked at the OpenID specific= ation.
What they are doing there is that they defined a new token, called ID = Token, that is associated with the *user*; which is exactly what the SIP OA= uth proposal is doing.

My plan is to use the same terminology, ID Token, in the next version = of the SIP OAuth document to clarify that, and to differentiate it from the= access token.

 
I think, though, we might usefully break uses cases here down by who the intended relying party is:

- The user's own SIP service provider (my enterprise, my carrier, my OTT provider)
- A third party that a user wants to authorize for a service (recording
service... But anything else?)

I would also append some use cases where the relying party:

- Someone with no association with the user (caller ID sorts of cases)

This last is where I've argued things like IdP might be relevant.


EKR has a nice description for binding IdP to OAuth in his WebRTC Secu= rity Architecture document here:

We could use the same idea for SIP.


Regards,
 Rifaat


 
Are there any other high-level buckets of use cases here?

Jon Peterson
Neustar, Inc.

On 8/25/14, 11:44 AM, "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote:

>On 8/25/14 11:50 AM, Rifaat Shekh-Yusef wrote:
>> Hi Matt,
>>
>> The use case and the solution provided assumes that the VoIP Provi= der
>> makes the decision on when and what to record.
>> While this is a valid use case, there are other use cases that all= ow the
>> user to decide on when and what to record; take a look at RFC6341 = for
>> more info.
>> http://datatracker.ietf.org/doc/rfc6341/
>
>SIPREC supports numerous topologies.
>It would support the one that Matt outlines as well as end-user
>controlled ones.
>
>I found Matt's use case interesting. I think it would be nice if such >services were available in that form. But I have difficulty imagining >any of the VoIP providers I'm aware of supporting this model. My
>impression is that this means that they are giving up a value added
>revenue market, that they are loath to do. The most likely justificatio= n
>I can imagine that they don't want to legal consequences of doing
>recording.
>
>       Thanks,
>       Paul
>
>> For these use cases, where the user is in control, you need to awa= y to
>> authenticate and control which users are allowed to record and the= level
>> of service provided for that specific user.
>> This is where the solutions provided in section 3 or section 4 of = the
>> SIP OAuth proposal come into play.
>> Obviously, in this case the authorization server is different from=
>> authorization server used to establish the trust relationship betw= een
>> the VoIP Provider and the CRS Provider.
>> In this case, the authorization server must authenticate the user = and
>> provide his UA with an access token or a code that controls the us= er's
>> access to the service.
>>
>> Regards,
>>   Rifaat
>>
>>
>>
>> On Sat, Aug 23, 2014 at 9:05 AM, Matt Ryan <ietf@mvryan.org
>> <mailto:ie= tf@mvryan.org>> wrote:
>>
>>     Included is the use case I spoke of before.&nbs= p; My apologies for the
>>delay.
>>
>>     This is written as though it could be included = in
>>     [draft-yusef-sipcore-sip-oauth] at section 6. >>
>>
>>     6. Examples
>>
>>     6.1. Example: Call Recording Service
>>
>>     This example illustrates the use of SIP OAuth b= etween three
>>     parties:  A hosted VoIP service provider, = a Call Recording Service
>>     provider, and a phone system end-user.  In= this example:
>>     - The phone system end-user is a customer of bo= th the hosted VoIP
>>     provider and the Call Recording Service provide= r
>>     - The hosted VoIP service provider is a standar= d provider of hosted
>>     business-class VoIP telephone service using SIP=
>>     - The Call Recording Service provider is a dist= inct entity from the
>>     hosted VoIP provider
>>
>>     The Call Recording Service provides to customer= s both the call
>>     recording abilities and management of call reco= rdings
>>     (configuration, sharing and distribution, reten= tion, etc.).  This
>>     service can accept and record RTP traffic, asso= ciate all RTP streams
>>     with a single call together, and store and cata= log the recorded data
>>     for future searching and retrieval.  The s= ervice also offers a web
>>     interface where customers may view and retrieve= stored calls.
>>     Stored calls may range from simple person-to-pe= rson voice calls to
>>     multi-party conferences with a multitude of aud= io and video
>>     streams.  In this example, customers are b= illed based on the amount
>>     of data they store, although other models are c= ertainly possible.
>>
>>     6.1.1. OAuth 2.0 Roles
>>
>>     In this example, each party assumes the followi= ng OAuth 2.0 roles as
>>     defined in [RFC6749] Section 1.1:
>>     - The end-user assumes the role of resource own= er
>>     - The hosted VoIP service provider assumes the = role of client
>>     - The Call Recording Service provider assumes t= he role of resource
>>     server as well as the role of authorization ser= ver
>>
>>     6.1.2. Description
>>
>>     There are two parts to the example:  Initi= al configuration and
>>     real-time recording authorization.
>>
>>     Each section includes a simplified flow diagram= for the purpose of
>>     describing the corresponding portion of the exa= mple.  For the sake
>>     of brevity, certain parts of the OAuth dialog h= ave been eliminated.
>>     Implements should refer to [RFC6749] for detail= s on OAuth.
>>
>>     6.1.2.1 Initial Configuration
>>
>>        +-------------+    &n= bsp;+---------------+     +--------------+ >>        |  End-User   |  &n= bsp;  | VoIP Provider |     | CRS Provider |
>>        | Web Browser |     |&nb= sp;   Website    |     |      =         |
>>        +-------------+    &n= bsp;+---------------+     +--------------+ >>               |  &nbs= p;                 |    &= nbsp;                |
>>               | HTTP 1&nbs= p;            |        &n= bsp;            |
>>               | (Configure= CRS)    |               =      |
>>               |-----------= -------->|                 =    |
>>               |  &nbs= p;                 |    &= nbsp;                |
>>               | HTTP 2&nbs= p;            |        &n= bsp;            |
>>               | (OAuth Red= irect    |               =      |
>>               |  to C= RS Website)   |              &= nbsp;      |
>>               |<-------= ------------|                 =    |
>>               |  &nbs= p;                 |    &= nbsp;                |
>>               | HTTP 3&nbs= p;            |        &n= bsp;            |
>>               | (Authorize= SIP from VoIP provider        |
>>               |-----------= ------------------------------>|
>>               |  &nbs= p;                 |    &= nbsp;                |
>>               | HTTP 4&nbs= p;            |        &n= bsp;            |
>>               | (OAuth Red= irect back to VoIP portal)     |
>>               |<-------= ----------------------------------|
>>               |  &nbs= p;                 |    &= nbsp;                |
>>               | HTTP 5&nbs= p;            |        &n= bsp;            |
>>               |-----------= -------->|                 =    |
>>               |  &nbs= p;                 | HTTP 6  &= nbsp;           |
>>               |  &nbs= p;                 | (Request Acces= s and |
>>               |  &nbs= p;                 |  refresh = tokens)    |
>>               |  &nbs= p;                 |---------------= ----->|
>>               |  &nbs= p;                 |    &= nbsp;                |
>>
>>     Some time after having signed up for both servi= ces, but prior to
>>     attempting to record any calls, the end-user lo= gs into the web
>>     portal of the hosted VoIP provider with a web b= rowser and configures
>>     their call recording service (HTTP 1).  Th= is configuration includes
>>     providing a URI where the call recording servic= e may be reached,
>>     along with a set of API credentials, provided b= y the call recording
>>     service, which will allow the client to initiat= e an OAuth exchange.
>>     The end-user also configures the conditions und= er which call
>>     recordings should take place.  For example= , the end-user may request
>>     to record every multi-party (conference) call, = or every call
>>     involving a specific set of users.  The en= d-user may also specify
>>     other restrictions, such as restricting codec n= egotiation to G.711u
>>     for audio and H.264 for video in order to recor= d the RTP streams.
>>     Once the end-user saves the configuration, the = hosted VoIP provider
>>     web portal redirects the end-user's web browser= to the call
>>     recording service website and a standard HTTP O= Auth dialog begins
>>     (HTTP 2).  The end-user authorizes the hos= ted VoIP provider to
>>     access (i.e. send SIP and RTP traffic to) the c= all recording
>>     service, for the purpose of recording calls, so= long as the
>>     configured conditions are met (HTTP 3).  T= he result of this
>>     interaction is that the hosted VoIP provider en= ds up receiving an
>>     OAuth access token and refresh token from the c= all recording service
>>     (HTTP 4, HTTP 5, HTTP 6).  These tokens ar= e saved in the end-user's
>>     hosted VoIP account database.
>>
>>     6.1.2.2 Real-time Recording Authorization
>>
>>        +-------------+    &n= bsp;+---------------+      +--------------+<= br> >>        |  End-User   |  &n= bsp;  | VoIP Provider |      | CRS Provider |
>>        |  SIP Phone  |    =  |    Website    |      |  &nb= sp;           |
>>        +-------------+    &n= bsp;+---------------+      +--------------+<= br> >>               |  &nbs= p;                 |    &= nbsp;                 |
>>               | SIP INVITE= 1       |            &nb= sp;         |
>>               |-----------= -------->|                 =     |
>>               |  &nbs= p;                 | SIP INVITE 2&n= bsp;        |
>>               |  &nbs= p;                 | (with access t= oken)  |
>>               |  &nbs= p;                 |---------------= ------>|
>>               |  &nbs= p;                 |    &= nbsp;                 |
>>               |  &nbs= p;                 | SIP 401 Unauth= orized |
>>               |  &nbs= p;                 |<-----------= ----------|
>>               |  &nbs= p;                 |    &= nbsp;                 |
>>               |  &nbs= p;                 | SIP INVITE 3&n= bsp;        |
>>               |  &nbs= p;                 | (with refresh = token) |
>>               |  &nbs= p;                 |---------------= ------>|
>>               |  &nbs= p;                 |    &= nbsp;                 |
>>               |  &nbs= p;                 | SIP 200 1 = ;           |
>>               |  &nbs= p;                 | (new access to= ken)   |
>>               |  &nbs= p;                 |<-----------= ----------|
>>               |  &nbs= p;                 |    &= nbsp;                 |
>>               |  &nbs= p;                 | SIP INVITE 4&n= bsp;        |
>>               |  &nbs= p;                 | (with access t= oken)  |
>>               |  &nbs= p;                 |---------------= ------>|
>>               |  &nbs= p;                 |    &= nbsp;                 |
>>               |  &nbs= p;                 | SIP 200 2 = ;           |
>>               |  &nbs= p;                 |<-----------= ----------|
>>               |  &nbs= p;                 |    &= nbsp;                 |
>>
>>     Independently of and after the initial configur= ation phase, the
>>     end-user makes a telephone call using the hoste= d VoIP provider (SIP
>>     INVITE 1).  When this call takes place, th= e hosted VoIP provider
>>     looks to see whether it believes this call shou= ld be recorded.  If
>>     so, at this point it would branch the call sess= ion to the call
>>     recording service, using SIP OAuth to pass the = previously provided
>>     access token for authorization (SIP INVITE 2).&= nbsp; Once the access
>>     token is validated by the call recording servic= e (perhaps after
>>     first providing a new access token based on rec= eipt of a valid
>>     refresh token), the call recording service will= check the rights
>>     that were previously authorized and examine the= SIP to determine
>>     whether it can accept the call.  If so, it= completes the
>>     establishment of the session and begins receivi= ng and recording the
>>     RTP stream(s) (SIP 200 OK).  The call reco= rding service provider
>>     could also deny the request, either because the= tokens are invalid
>>     or because the content of
>>       the SIP invite does not match the previo= usly authorized
>>     conditions, in which case a SIP 403 would be re= turned by the call
>>     recording service provider and the call would n= ot be recorded -
>>     however, the initial call branch would continue= without
>>interruption.
>>
>>     Note:
>>     [RFC6749] specifies that when a client uses a r= efresh token to
>>     request a new access token, the response is HTT= P 200 with the new
>>     access token and optionally a new refresh token= included in the
>>     payload.  In this example, a SIP 200 respo= nse (SIP 200 1) is sent
>>     which contains the new token(s).  However,= this could be confusing
>>     as SIP 200 is generally viewed as the acceptanc= e of the INVITE,
>>     which is not what is happening in this case.&nb= sp; Should SIP 200 be used
>>     for consistency, or should another mechanism be= used?
>>
>>     6.1.3. Justification
>>
>>     6.1.3.1. Hosted VoIP Service Provider
>>
>>     In this example, the hosted VoIP service provid= er can allow their
>>     customers to enable call recording in their VoI= P service by
>>     selecting from any of a number of supported cal= l recording service
>>     providers.  This allows the hosted VoIP se= rvice provider to offer
>>     this feature to customers without requiring tha= t the hosted VoIP
>>     service provider implement and support this fea= ture themselves.
>>
>>     6.1.3.2. Call Recording Service Provider
>>
>>     In this example, the Call Recording Service pro= vider can focus on
>>     value and innovation in the area of recording c= alls and managing
>>     recorded calls without having to build a full-f= eatured telephony
>>     offering.
>>
>>     6.1.3.3. Customer
>>
>>     In this example, the customer has more flexibil= ity in choosing a
>>     complete solution that meets all of the custome= r needs.  The
>>     customer does not have to settle for a substand= ard call recording
>>     service offering in order to obtain other featu= res they seek in a
>>     hosted VoIP provider, and vice versa.
>>
>>     6.1.4. Variants
>>
>>     A simple variant of this example is one wherein= one of the services
>>     (either the VoIP service or the call recording = service) is managed
>>     directly by the end-user, but the other is not.=   For example, the
>>     end-user may wish to make use of an external ho= sted VoIP service
>>     provider, but may have business or legal reason= s that forbid the
>>     end-user from allowing a third party to store a= nd manage recorded
>>     calls.  The end-user could choose to set u= p their own call recording
>>     service as described in this example, and use S= IP OAuth to
>>     facilitate interaction between the hosted VoIP = service and the
>>     end-user's own call recording service.
>>
>>     6.2. Other SIP OAuth examples
>>
>>     Many other SIP-based services could leverage SI= P OAuth to provide
>>     value-added service to an end-user of a hosted = VoIP service
>>     provider.  Some examples of these types of= services are listed
>>below.
>>
>>     Voicemail service provider:  The end-user = configures their hosted
>>     VoIP service provider to manage voicemail throu= gh a separate
>>     voicemail service provider, which chooses wheth= er to store voicemail
>>     based on existing quotas, Caller ID, etc.
>>
>>     Conferencing service provider:  A conferen= cing service may wish to
>>     bill customers in a more granular fashion, for = example, based on the
>>     number of participants and attendees in a confe= rence, the duration
>>     of conference, whether video was also included,= which codecs were
>>     being used, etc. instead of a flat monthly rate= .  SIP OAuth would
>>     facilitate metered authorization for a client's= use of the service,
>>     instead of all-or-nothing access.
>>
>>     Call center service provider:  A third par= ty may provide ring groups
>>     or call queues for a hosted VoIP provider along= with detailed
>>     reports and dashboards.  The end-user uses= OAuth over SIP to control
>>     who can log into which queues or ring groups, e= tc.
>>
>>
>>
>>     --
>>     Matt Ryan
>>     code slinger | zoomulus.com <http://zoomulus.com>
>>     ietf at mvryan dot org
>>
>>
>>
>>
>>     _______________________________________________=
>>     sipcore mailing list
>>     sipcore@ietf.org <mailto:sipcore@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/sipcore<= /a>
>>
>>
>>
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf= .org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>
>_______________________________________________
>sipcore mailing list
>sipcore@ietf.org<= /a>
>https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore


--_000_D03C75E8133DCFjonpetersonneustarbiz_-- From nobody Wed Sep 17 06:22:41 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5031A03DE for ; Wed, 17 Sep 2014 06:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5__xtpOt6t52 for ; Wed, 17 Sep 2014 06:22:29 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D4E11A037D for ; Wed, 17 Sep 2014 06:22:28 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id gq15so1790223lab.39 for ; Wed, 17 Sep 2014 06:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iI3JjWHg/QT2hzPBs8dRWNgAyRO4MsoMoTcQfhZIOh8=; b=fXjWglihQulLWaVPpLdwP/f2NE5ub0ZfiZ2Vd15vMmnPigUv82BMEyRazl5oS95ZSS AqUbH3qc+8l0PSx3sE88CzXoLlLfQ486sTSwMcYcOMeILTkIWrJRG+oSfVq4+ib9lFkg zPIwMXdmgU4yC8wPJnKn3t48lvgW1wVnEXMWhB7aHV8saDTx/HHcjSY0mODO5wPH4w2e gWGnPSypfBDVaxyDGnQ4LZyZFYsE9LHlEXLmAS6y+ydjltXhXWkI3Mg28ckjTl4uCRWs aJJ8aqXooy6Oasn7evp8SrMDc+qxevBG5KqFUVp89i4GEPMylYSkOqu2vl8hEIWs7fsu DL4A== MIME-Version: 1.0 X-Received: by 10.152.21.42 with SMTP id s10mr44779504lae.61.1410960146178; Wed, 17 Sep 2014 06:22:26 -0700 (PDT) Received: by 10.114.2.34 with HTTP; Wed, 17 Sep 2014 06:22:26 -0700 (PDT) In-Reply-To: References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> <53FB83FA.8010101@alum.mit.edu> Date: Wed, 17 Sep 2014 09:22:26 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=089e013d175e4e2887050342c210 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/A6pmEfzlV1dcaQInIgCjY2BUWN4 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 13:22:37 -0000 --089e013d175e4e2887050342c210 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 15, 2014 at 3:29 PM, Peterson, Jon wrote: > > Format snags aside, > I copied that text from a different editor. The format seems ok here: http://www.ietf.org/mail-archive/web/sipcore/current/msg06258.html So, it might be something on your side? > I have a bit of difficulty even differentiating the issues listed below: > surely the reason why enterprises assign multiple identities per user is to > authorize access to different services separately. > Sorry, I do not get that. Why would the enterprise be required to create multiple identities to allow access to different services separately? in other words, why cannot the enterprise create one identity and still be able to control the user's access to different services provided by different servers? > This is an issue that could be resolved with an access control list per > service and a trusted identity broker in the enterprise vouching for user > identities to these services. > But that means that each server that provides a service must maintain a separate user directory, which is exactly what I am trying to avoid. > But to convince ourselves that one approach to this is better than > another, we need to look at a level of detail below these issue > descriptions. Again, in order to access a voicemail service in an > enterprise, say, what does the voicemail service need to know about the > user? > > Like, for regular access to the voicemail for "jon@enterprise," surely > all the voicemail service needs to know is that the entity authoritative > for the @enterprise issued me the name "jon." Maybe the "admin" account > gets to access all the voicemails, if need be. > The application server needs the following pieces of information about each user: 1. ID and credentials 2. User profile to control the level of service provided to the user. You cannot assume that all users will get the same level of service. > There are a variety of mechanisms that suffice to prove simple identities > like that to a service. > Can you elaborate? Are you assuming that the service still have a separate user directory? > If, however, I as "jon" needed for a third-party transcription service to > access a subset of the messages in my voicemail box, and I wanted the > permissions for that access to expire as soon as the messages had been > transcribed, then there is a much narrower set of mechanisms that could > provide that capability. > You keep going back to the OAuth 2.0 model and try to impose it on SIP, which would work in some use cases. What I am proposing is something along the lines of OpenID, which extends the OAuth to authenticate the *user*. In this case, the mapping between OAuth and SIP would be something like the following: OAuth SIP --------------------------------------------------------------------------- Resource Owner End User Resource Server SIP Proxy or SIP Application Server Client SIP UA Authorization Server Authorization Server Do you see a problem with this model? > But it sounds to me, from this issues list, like your requirements are > more along the former lines than the latter. > > Actually, it is both. Here is an example of a use case that fits with the OAuth 2.0 model: An Application Server that provides Mobile Clients with access to SIP services. The Mobile Client uses a proprietary protocol to communicate with the Application Server that registers and gets service from the SIP network on behalf of the user that is using the Mobile Client. The communication channels between the players in this case are as follows (hopefully the format is ok this time): [Mobile Client] <-----------> [Application Server] <-----------> [SIP Proxy] /\ /\ | | | \/ ------------------------> [Authorization Server] In this case, the mapping between OAuth and SIP would be something like the following: OAuth SIP --------------------------------------------------------------------------- Resource Owner End User Resource Server SIP Proxy Client Application Server (providing service to the mobile client) Authorization Server Authorization Server Regards, Rifaat > Jon Peterson > Neustar, Inc. > > From: Rifaat Shekh-Yusef > Date: Saturday, September 13, 2014 at 12:32 PM > > To: Jon Peterson > Cc: Paul Kyzivat , "sipcore@ietf.org" < > sipcore@ietf.org> > Subject: Re: [sipcore] A SIP OAuth use case > > > > On Thu, Sep 4, 2014 at 7:27 PM, Peterson, Jon > wrote: > >> >> I understand that OAuth can be altered from its basic flows to provide >> tokens for OpenID, and IdP could be bound to OAuth, and while this is all >> very interesting it doesn't change much about the requirements discussion I >> think we need to have: the one about what kinds of use cases we want to >> satisfy and who the relying parties are in those cases. Once we understand >> that, we will understand what tools are applicable to these use cases - >> preferably, not tools that need to be twisted into a different shape to be >> applicable. >> >> > Well, OpenID extends the OAuth 2.0 Framework to authenticate the user; > why do you think it is "twisting" OAuth into a different shape? > > > > >> It would helpful, in the enterprise SSO case, for us to understand what >> kinds of application servers a user might need to access, and what exactly >> those application servers need to know about the user in order to >> accomplish their function. >> >> > Below is a description for some enterprise issues, that hopefully will > be addressed by a new authorization framework: > > > * Multiple Identities One of the major issues in the enterprise is the > need for a user to obtain multiple uncorrelated identities associated with > different products to get access to the various services provided by the > enterprise. For example, in the enterprise the user will be provided with > different identities to: o Login his device (PC, laptop, mobile, ...) to > the network. o Register to the SIP network and get basic SIP services. o > Access his Voice Mail. o Host a conference. o etc Typically, these > identities belong to different administrative domains and realms. Instead > of these multiple identities, ideally the enterprise would like to create > and maintain only one identity for the user and then allow the user access > to all SIP and non-SIP services using that one identity. * Authorization of > Access to Services Another issue in the enterprise is the need to control > and authorize a user access to services. Because application servers have > their own user directory, the control of access to services is spread over > a multitude of servers in the network. Ideally, the enterprise would like > to manage the access to services using one centralized entity and for the > various entities that provide the service to become the enforcement points. > * Assignment of Services In the enterprise, different users might be > assigned to different servers providing a specific service; e.g. Voice Mail > Box for different users might be hosted by different servers, and the user > need to know his assigned server to be able to get access to this service. > * Application Servers To be able to provide service, the application server > needs a list of users allowed to get services. The application server needs > the following pieces of information about each user: 1. User ID and > Credentials 2. Profile to control the level of service provided to the > user. If one application server provides different services using different > protocols, the application server might need to maintain different > identities associated with these protocols; e.g. an application server that > provides presence service using SIP, and IM service using XMPP. Ideally, an > authorization framework would: 1. Off load the application server from the > need to manage the user credentials and authenticating the user. 2. Off > load the application server from the need to maintain the users and their > profiles to control the level of service provided to the user. 3. Allow the > assignment of a user to a specific application server. * OAuth/OpenID Model > With the OAuth/OpenID framework, the user ID and credentials will be > handled by the authorization server, and the application server assignment > and the level of service associated with the user will be provided in the > scope of the token associated with the user. When the application server > receives a request from a user it will have all the details that would > allow the application server to validate the request to make sure it is > coming from the right authorization server, and to act upon the request > because it has the scope associated with the user, without the need to > contact the authorization server. * Relying Party Regarding the Relying > Party question: I think that when the user is being authenticated, that the > Relying Party would be the SIP Client that would be given a user token (ID > Token in OpenID lingo) to access services on behalf of the end user. So, > the mapping would be something like this: > +------------------------+-----------------------------+ | OAuth | SIP | > +------------------------+-----------------------------+ | Resource Owner | > End User | | Resource Server | SIP Proxy or SIP App Server | | Client | SIP > UA (Relying Party) | | Authorization Server | Authorization Server | > +------------------------+-----------------------------+ > > > Regards, > Rifaat > > > > > > > >> Jon Peterson >> Neustar, Inc. >> >> From: Rifaat Shekh-Yusef >> Date: Thursday, September 4, 2014 at 8:31 AM >> To: Jon Peterson >> Cc: Paul Kyzivat , "sipcore@ietf.org" < >> sipcore@ietf.org> >> Subject: Re: [sipcore] A SIP OAuth use case >> >> >> >> >> On Wed, Sep 3, 2014 at 4:00 PM, Peterson, Jon >> wrote: >> >>> >>> While I would echo Paul's thoughts below about the plausibility of >>> service >>> providers using this model to authorize recording, I also agree that >>> third-party recording is an excellent example of a service architecture >>> that requires an authorization mechanism like OAuth. An end user needs to >>> authorize a third party to participate in the session under certain >>> constraints, and coordinate the association between the third party and >>> the VoIP service. This example also (rightly, in my opinion) conducts the >>> majority of the flow in HTTP where it belongs. >>> >>> >> I agree with that. >> >> >> >>> Many of the use cases under discussion in this thread, though, are of the >>> form where there are really only two involved parties: an end user and a >>> service provider. If you are my service provider, then in traditional SIP >>> I share a secret with you that I use to REGISTER my devices. I don't >>> think >>> you need OAuth for that. >> >> >> If you assume that there is one server that provides all the services, >> then you are right. >> But that is not the case all the time. I think that Dale articulated that >> clearly in the following response: >> http://www.ietf.org/mail-archive/web/sipcore/current/msg06233.html >> >> >> >>> I do understand that OAuth 2.0 is used in the >>> wild for SSO, though I sympathize with Matt that the base flow shown in >>> RFC6749 Sec 1.2 just doesn't map onto the requirements for SSO. >>> >>> >> I agree that the OAuth 2.0 "as is" does not address the SSO >> requirements. >> The SIP OAuth proposal is not just using OAuth 2.0 "as is", but it is >> extending the framework to authenticate and provide a *user* specific token. >> >> Since Matt mentioned OpenID few times, I looked at the OpenID >> specification. >> What they are doing there is that they defined a new token, called ID >> Token, that is associated with the *user*; which is exactly what the SIP >> OAuth proposal is doing. >> http://openid.net/specs/openid-connect-core-1_0.html#IDToken >> >> My plan is to use the same terminology, ID Token, in the next version >> of the SIP OAuth document to clarify that, and to differentiate it from the >> access token. >> >> >> >>> I think, though, we might usefully break uses cases here down by who the >>> intended relying party is: >>> >>> - The user's own SIP service provider (my enterprise, my carrier, my OTT >>> provider) >>> - A third party that a user wants to authorize for a service (recording >>> service... But anything else?) >>> >>> I would also append some use cases where the relying party: >>> >>> - Someone with no association with the user (caller ID sorts of cases) >>> >>> This last is where I've argued things like IdP might be relevant. >>> >>> >> EKR has a nice description for binding IdP to OAuth in his WebRTC >> Security Architecture document here: >> >> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10#appendix-A.2 >> >> We could use the same idea for SIP. >> >> >> Regards, >> Rifaat >> >> >> >> >>> Are there any other high-level buckets of use cases here? >>> >>> Jon Peterson >>> Neustar, Inc. >>> >>> On 8/25/14, 11:44 AM, "Paul Kyzivat" wrote: >>> >>> >On 8/25/14 11:50 AM, Rifaat Shekh-Yusef wrote: >>> >> Hi Matt, >>> >> >>> >> The use case and the solution provided assumes that the VoIP Provider >>> >> makes the decision on when and what to record. >>> >> While this is a valid use case, there are other use cases that allow >>> the >>> >> user to decide on when and what to record; take a look at RFC6341 for >>> >> more info. >>> >> http://datatracker.ietf.org/doc/rfc6341/ >>> > >>> >SIPREC supports numerous topologies. >>> >It would support the one that Matt outlines as well as end-user >>> >controlled ones. >>> > >>> >I found Matt's use case interesting. I think it would be nice if such >>> >services were available in that form. But I have difficulty imagining >>> >any of the VoIP providers I'm aware of supporting this model. My >>> >impression is that this means that they are giving up a value added >>> >revenue market, that they are loath to do. The most likely justification >>> >I can imagine that they don't want to legal consequences of doing >>> >recording. >>> > >>> > Thanks, >>> > Paul >>> > >>> >> For these use cases, where the user is in control, you need to away to >>> >> authenticate and control which users are allowed to record and the >>> level >>> >> of service provided for that specific user. >>> >> This is where the solutions provided in section 3 or section 4 of the >>> >> SIP OAuth proposal come into play. >>> >> Obviously, in this case the authorization server is different from >>> >> authorization server used to establish the trust relationship between >>> >> the VoIP Provider and the CRS Provider. >>> >> In this case, the authorization server must authenticate the user and >>> >> provide his UA with an access token or a code that controls the user's >>> >> access to the service. >>> >> >>> >> Regards, >>> >> Rifaat >>> >> >>> >> >>> >> >>> >> On Sat, Aug 23, 2014 at 9:05 AM, Matt Ryan >> >> > wrote: >>> >> >>> >> Included is the use case I spoke of before. My apologies for the >>> >>delay. >>> >> >>> >> This is written as though it could be included in >>> >> [draft-yusef-sipcore-sip-oauth] at section 6. >>> >> >>> >> >>> >> 6. Examples >>> >> >>> >> 6.1. Example: Call Recording Service >>> >> >>> >> This example illustrates the use of SIP OAuth between three >>> >> parties: A hosted VoIP service provider, a Call Recording Service >>> >> provider, and a phone system end-user. In this example: >>> >> - The phone system end-user is a customer of both the hosted VoIP >>> >> provider and the Call Recording Service provider >>> >> - The hosted VoIP service provider is a standard provider of >>> hosted >>> >> business-class VoIP telephone service using SIP >>> >> - The Call Recording Service provider is a distinct entity from >>> the >>> >> hosted VoIP provider >>> >> >>> >> The Call Recording Service provides to customers both the call >>> >> recording abilities and management of call recordings >>> >> (configuration, sharing and distribution, retention, etc.). This >>> >> service can accept and record RTP traffic, associate all RTP >>> streams >>> >> with a single call together, and store and catalog the recorded >>> data >>> >> for future searching and retrieval. The service also offers a web >>> >> interface where customers may view and retrieve stored calls. >>> >> Stored calls may range from simple person-to-person voice calls to >>> >> multi-party conferences with a multitude of audio and video >>> >> streams. In this example, customers are billed based on the >>> amount >>> >> of data they store, although other models are certainly possible. >>> >> >>> >> 6.1.1. OAuth 2.0 Roles >>> >> >>> >> In this example, each party assumes the following OAuth 2.0 roles >>> as >>> >> defined in [RFC6749] Section 1.1: >>> >> - The end-user assumes the role of resource owner >>> >> - The hosted VoIP service provider assumes the role of client >>> >> - The Call Recording Service provider assumes the role of resource >>> >> server as well as the role of authorization server >>> >> >>> >> 6.1.2. Description >>> >> >>> >> There are two parts to the example: Initial configuration and >>> >> real-time recording authorization. >>> >> >>> >> Each section includes a simplified flow diagram for the purpose of >>> >> describing the corresponding portion of the example. For the sake >>> >> of brevity, certain parts of the OAuth dialog have been >>> eliminated. >>> >> Implements should refer to [RFC6749] for details on OAuth. >>> >> >>> >> 6.1.2.1 Initial Configuration >>> >> >>> >> +-------------+ +---------------+ +--------------+ >>> >> | End-User | | VoIP Provider | | CRS Provider | >>> >> | Web Browser | | Website | | | >>> >> +-------------+ +---------------+ +--------------+ >>> >> | | | >>> >> | HTTP 1 | | >>> >> | (Configure CRS) | | >>> >> |------------------->| | >>> >> | | | >>> >> | HTTP 2 | | >>> >> | (OAuth Redirect | | >>> >> | to CRS Website) | | >>> >> |<-------------------| | >>> >> | | | >>> >> | HTTP 3 | | >>> >> | (Authorize SIP from VoIP provider | >>> >> |----------------------------------------->| >>> >> | | | >>> >> | HTTP 4 | | >>> >> | (OAuth Redirect back to VoIP portal) | >>> >> |<-----------------------------------------| >>> >> | | | >>> >> | HTTP 5 | | >>> >> |------------------->| | >>> >> | | HTTP 6 | >>> >> | | (Request Access and | >>> >> | | refresh tokens) | >>> >> | |-------------------->| >>> >> | | | >>> >> >>> >> Some time after having signed up for both services, but prior to >>> >> attempting to record any calls, the end-user logs into the web >>> >> portal of the hosted VoIP provider with a web browser and >>> configures >>> >> their call recording service (HTTP 1). This configuration >>> includes >>> >> providing a URI where the call recording service may be reached, >>> >> along with a set of API credentials, provided by the call >>> recording >>> >> service, which will allow the client to initiate an OAuth >>> exchange. >>> >> The end-user also configures the conditions under which call >>> >> recordings should take place. For example, the end-user may >>> request >>> >> to record every multi-party (conference) call, or every call >>> >> involving a specific set of users. The end-user may also specify >>> >> other restrictions, such as restricting codec negotiation to >>> G.711u >>> >> for audio and H.264 for video in order to record the RTP streams. >>> >> Once the end-user saves the configuration, the hosted VoIP >>> provider >>> >> web portal redirects the end-user's web browser to the call >>> >> recording service website and a standard HTTP OAuth dialog begins >>> >> (HTTP 2). The end-user authorizes the hosted VoIP provider to >>> >> access (i.e. send SIP and RTP traffic to) the call recording >>> >> service, for the purpose of recording calls, so long as the >>> >> configured conditions are met (HTTP 3). The result of this >>> >> interaction is that the hosted VoIP provider ends up receiving an >>> >> OAuth access token and refresh token from the call recording >>> service >>> >> (HTTP 4, HTTP 5, HTTP 6). These tokens are saved in the >>> end-user's >>> >> hosted VoIP account database. >>> >> >>> >> 6.1.2.2 Real-time Recording Authorization >>> >> >>> >> +-------------+ +---------------+ +--------------+ >>> >> | End-User | | VoIP Provider | | CRS Provider | >>> >> | SIP Phone | | Website | | | >>> >> +-------------+ +---------------+ +--------------+ >>> >> | | | >>> >> | SIP INVITE 1 | | >>> >> |------------------->| | >>> >> | | SIP INVITE 2 | >>> >> | | (with access token) | >>> >> | |--------------------->| >>> >> | | | >>> >> | | SIP 401 Unauthorized | >>> >> | |<---------------------| >>> >> | | | >>> >> | | SIP INVITE 3 | >>> >> | | (with refresh token) | >>> >> | |--------------------->| >>> >> | | | >>> >> | | SIP 200 1 | >>> >> | | (new access token) | >>> >> | |<---------------------| >>> >> | | | >>> >> | | SIP INVITE 4 | >>> >> | | (with access token) | >>> >> | |--------------------->| >>> >> | | | >>> >> | | SIP 200 2 | >>> >> | |<---------------------| >>> >> | | | >>> >> >>> >> Independently of and after the initial configuration phase, the >>> >> end-user makes a telephone call using the hosted VoIP provider >>> (SIP >>> >> INVITE 1). When this call takes place, the hosted VoIP provider >>> >> looks to see whether it believes this call should be recorded. If >>> >> so, at this point it would branch the call session to the call >>> >> recording service, using SIP OAuth to pass the previously provided >>> >> access token for authorization (SIP INVITE 2). Once the access >>> >> token is validated by the call recording service (perhaps after >>> >> first providing a new access token based on receipt of a valid >>> >> refresh token), the call recording service will check the rights >>> >> that were previously authorized and examine the SIP to determine >>> >> whether it can accept the call. If so, it completes the >>> >> establishment of the session and begins receiving and recording >>> the >>> >> RTP stream(s) (SIP 200 OK). The call recording service provider >>> >> could also deny the request, either because the tokens are invalid >>> >> or because the content of >>> >> the SIP invite does not match the previously authorized >>> >> conditions, in which case a SIP 403 would be returned by the call >>> >> recording service provider and the call would not be recorded - >>> >> however, the initial call branch would continue without >>> >>interruption. >>> >> >>> >> Note: >>> >> [RFC6749] specifies that when a client uses a refresh token to >>> >> request a new access token, the response is HTTP 200 with the new >>> >> access token and optionally a new refresh token included in the >>> >> payload. In this example, a SIP 200 response (SIP 200 1) is sent >>> >> which contains the new token(s). However, this could be confusing >>> >> as SIP 200 is generally viewed as the acceptance of the INVITE, >>> >> which is not what is happening in this case. Should SIP 200 be >>> used >>> >> for consistency, or should another mechanism be used? >>> >> >>> >> 6.1.3. Justification >>> >> >>> >> 6.1.3.1. Hosted VoIP Service Provider >>> >> >>> >> In this example, the hosted VoIP service provider can allow their >>> >> customers to enable call recording in their VoIP service by >>> >> selecting from any of a number of supported call recording service >>> >> providers. This allows the hosted VoIP service provider to offer >>> >> this feature to customers without requiring that the hosted VoIP >>> >> service provider implement and support this feature themselves. >>> >> >>> >> 6.1.3.2. Call Recording Service Provider >>> >> >>> >> In this example, the Call Recording Service provider can focus on >>> >> value and innovation in the area of recording calls and managing >>> >> recorded calls without having to build a full-featured telephony >>> >> offering. >>> >> >>> >> 6.1.3.3. Customer >>> >> >>> >> In this example, the customer has more flexibility in choosing a >>> >> complete solution that meets all of the customer needs. The >>> >> customer does not have to settle for a substandard call recording >>> >> service offering in order to obtain other features they seek in a >>> >> hosted VoIP provider, and vice versa. >>> >> >>> >> 6.1.4. Variants >>> >> >>> >> A simple variant of this example is one wherein one of the >>> services >>> >> (either the VoIP service or the call recording service) is managed >>> >> directly by the end-user, but the other is not. For example, the >>> >> end-user may wish to make use of an external hosted VoIP service >>> >> provider, but may have business or legal reasons that forbid the >>> >> end-user from allowing a third party to store and manage recorded >>> >> calls. The end-user could choose to set up their own call >>> recording >>> >> service as described in this example, and use SIP OAuth to >>> >> facilitate interaction between the hosted VoIP service and the >>> >> end-user's own call recording service. >>> >> >>> >> 6.2. Other SIP OAuth examples >>> >> >>> >> Many other SIP-based services could leverage SIP OAuth to provide >>> >> value-added service to an end-user of a hosted VoIP service >>> >> provider. Some examples of these types of services are listed >>> >>below. >>> >> >>> >> Voicemail service provider: The end-user configures their hosted >>> >> VoIP service provider to manage voicemail through a separate >>> >> voicemail service provider, which chooses whether to store >>> voicemail >>> >> based on existing quotas, Caller ID, etc. >>> >> >>> >> Conferencing service provider: A conferencing service may wish to >>> >> bill customers in a more granular fashion, for example, based on >>> the >>> >> number of participants and attendees in a conference, the duration >>> >> of conference, whether video was also included, which codecs were >>> >> being used, etc. instead of a flat monthly rate. SIP OAuth would >>> >> facilitate metered authorization for a client's use of the >>> service, >>> >> instead of all-or-nothing access. >>> >> >>> >> Call center service provider: A third party may provide ring >>> groups >>> >> or call queues for a hosted VoIP provider along with detailed >>> >> reports and dashboards. The end-user uses OAuth over SIP to >>> control >>> >> who can log into which queues or ring groups, etc. >>> >> >>> >> >>> >> >>> >> -- >>> >> Matt Ryan >>> >> code slinger | zoomulus.com >>> >> ietf at mvryan dot org >>> >> >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> sipcore mailing list >>> >> sipcore@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/sipcore >>> >> >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> sipcore mailing list >>> >> sipcore@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/sipcore >>> >> >>> > >>> >_______________________________________________ >>> >sipcore mailing list >>> >sipcore@ietf.org >>> >https://www.ietf.org/mailman/listinfo/sipcore >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> >> > --089e013d175e4e2887050342c210 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Sep 15, 2014 at 3:29 PM, Peterson, Jon <jon.peterson@ne= ustar.biz> wrote:

Format snags aside,

I cop= ied that text from a different editor.
The format seems ok here:<= /div>

So, it might be so= mething on your side?

=A0
I have a bit of difficulty even differentiat= ing the issues listed below: surely the reason why enterprises assign multi= ple identities per user is to authorize access to different services separa= tely.

Sorry, I do not get that= .=A0
Why would the enterprise be required to create multiple iden= tities to allow access to different services separately? in other words, wh= y cannot the enterprise create one identity and still be able to control th= e user's access to different services provided by different servers?

=A0
=
But to convince ourselves that one approach to= this is better than another, we need to look at a level of detail below th= ese issue descriptions. Again, in order to access a voicemail service in an en= terprise, say, what does the voicemail service need to know about the user?=

Like, for regular access to the voicemail for "jon@enterprise,&qu= ot; surely all the voicemail service needs to know is that the entity autho= ritative for the @enterprise issued me the name "jon." Maybe the = "admin" account gets to access all the voicemails, if need be.

The application= server needs the following pieces of information about each user:
1. ID and credentials
2. User profile to control the level of s= ervice provided to the user.

You cannot assu= me that all users will get the same level of service.

<= div>=A0
There are a vari= ety of mechanisms that suffice to prove simple identities like that to a se= rvice.

Can you elaborate?
Are you assuming that the service still have a separate user director= y?

=A0
If, however, I as "jon" needed for a third-party transcri= ption service to access a subset of the messages in my voicemail box, and I= wanted the permissions for that access to expire as soon as the messages had been transcribed, th= en there is a much narrower set of mechanisms that could provide that capab= ility.

You keep going back to = the OAuth 2.0 model and try to impose it on SIP, which would work in some u= se cases.

What I am proposing is something along t= he lines of OpenID, which extends the OAuth to authenticate the *user*.
In this case, the mapping between OAuth and SIP would be something l= ike the following:

OAuth =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0SIP
--------------= -------------------------------------------------------------
Res= ource Owner =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 End User
Reso= urce Server =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SIP Proxy or SIP Applic= ation Server
Client =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 SIP UA
Authorization Server =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0Authorization Server

Do you= see a problem with this model?

=A0
But it sounds to me, from this issues = list, like your requirements are more along the former lines than the latter.=A0


Actually, it is both.=

Here is an example of a use case that fits with t= he OAuth 2.0 model:

An Application Server that pro= vides Mobile Clients with access to SIP services.
The Mobile Clie= nt uses a proprietary protocol to communicate with the Application Server t= hat registers and gets service from the SIP network on behalf of the user t= hat is using the Mobile Client.

The communication = channels between the players in this case are as follows (hopefully the for= mat is ok this time):

[Mobile Client] =A0<-----= ------> =A0[Application Server] <-----------> [SIP Proxy]
=A0 =A0 =A0 =A0 =A0 /\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /\
=A0 =A0 =A0 =A0 =A0 =A0| =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0|
=A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \/
=A0 =A0 = =A0 =A0 =A0 =A0------------------------> [Authorization Server]


In this case, the mapping between OAuth and= SIP would be something like the following:

OAuth =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0SIP
------------------------------------------------------= ---------------------
Resource Owner =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 End User
Resource Server =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 SIP Proxy
Client =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Application Server (providing service t= o the mobile client)
Authorization Server =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0Authorization Server


= Regards,
=A0Rifaat



=A0
Jon Peterson
Neustar, Inc.




On Thu, Sep 4, 2014 at 7:27 PM, Peterson, Jon <jon.peter= son@neustar.biz> wrote:

I understand that OAuth can be altered from its basic flows to provide= tokens for OpenID, and IdP could be bound to OAuth, and while this is all = very interesting it doesn't change much about the requirements discussi= on I think we need to have: the one about what kinds of use cases we want to satisfy and who the relying parti= es are in those cases. Once we understand that, we will understand what too= ls are applicable to these use cases - preferably, not tools that need to b= e twisted into a different shape to be applicable.


Well, OpenID extends the OAuth 2.0 Framework to authenticate the user;= why do you think it is "twisting" OAuth into a different shape?<= /div>


=A0
It would helpful, in the enterprise SSO case, for us to understand wha= t kinds of application servers a user might need to access, and what exactl= y those application servers need to know about the user in order to accompl= ish their function.


Below is a description for some enterprise issues, that hopefully will= be addressed by a new authorization framework:


* Multiple Identities On= e of the major issues in the enterprise is the need for a user to obtain mu= ltiple uncorrelated identities associated with different products to get access to the various services p= rovided by the enterprise. For example, in the enterprise the user will be = provided with different identities to: o Login his device (PC, laptop, mobi= le, ...) to the network. o Register to the SIP network and get basic SIP services. o Access his Voice Mail. o = Host a conference. o etc Typically, these identities belong to different ad= ministrative domains and realms. Instead of these multiple identities, idea= lly the enterprise would like to create and maintain only one identity for the user and then allow the user= access to all SIP and non-SIP services using that one identity. * Authoriz= ation of Access to Services Another issue in the enterprise is the need to = control and authorize a user access to services. Because application servers have their own user directory, th= e control of access to services is spread over a multitude of servers in th= e network. Ideally, the enterprise would like to manage the access to servi= ces using one centralized entity and for the various entities that provide the service to become the enforc= ement points. * Assignment of Services In the enterprise, different users m= ight be assigned to different servers providing a specific service; e.g. Vo= ice Mail Box for different users might be hosted by different servers, and the user need to know his assign= ed server to be able to get access to this service. * Application Servers T= o be able to provide service, the application server needs a list of users = allowed to get services. The application server needs the following pieces of information about each user: 1. User = ID and Credentials 2. Profile to control the level of service provided to t= he user. If one application server provides different services using differ= ent protocols, the application server might need to maintain different identities associated with these protocol= s; e.g. an application server that provides presence service using SIP, and= IM service using XMPP. Ideally, an authorization framework would: 1. Off l= oad the application server from the need to manage the user credentials and authenticating the user. 2. Of= f load the application server from the need to maintain the users and their= profiles to control the level of service provided to the user. 3. Allow th= e assignment of a user to a specific application server. * OAuth/OpenID Model With the OAuth/OpenID framework, = the user ID and credentials will be handled by the authorization server, an= d the application server assignment and the level of service associated wit= h the user will be provided in the scope of the token associated with the user. When the application server r= eceives a request from a user it will have all the details that would allow= the application server to validate the request to make sure it is coming f= rom the right authorization server, and to act upon the request because it has the scope associated with the u= ser, without the need to contact the authorization server. * Relying Party = Regarding the Relying Party question: I think that when the user is being a= uthenticated, that the Relying Party would be the SIP Client that would be given a user token (ID Token in Open= ID lingo) to access services on behalf of the end user. So, the mapping wou= ld be something like this: +------------------------+----------------------= -------+ | OAuth | SIP | +------------------------+------------------------= -----+ | Resource Owner | End User | | Resource Server | SIP Proxy or SIP App Ser= ver | | Client | SIP UA (Relying Party) | | Authorization Server | Authoriz= ation Server | +------------------------+-----------------------------+


Regards,
=A0Rifaat





=A0
Jon Peterson
Neustar, Inc.





On Wed, Sep 3, 2014 at 4:00 PM, Peterson, Jon <jon.peter= son@neustar.biz> wrote:

While I would echo Paul's thoughts below about the plausibility of serv= ice
providers using this model to authorize recording, I also agree that
third-party recording is an excellent example of a service architecture
that requires an authorization mechanism like OAuth. An end user needs to authorize a third party to participate in the session under certain
constraints, and coordinate the association between the third party and
the VoIP service. This example also (rightly, in my opinion) conducts the majority of the flow in HTTP where it belongs.


I agree with that.

=A0
Many of the use cases under discussion in this thread, though, are of the form where there are really only two involved parties: an end user and a service provider. If you are my service provider, then in traditional SIP I share a secret with you that I use to REGISTER my devices. I don't th= ink
you need OAuth for that.

If you assume that there is one server that provides all the services,= then you are right.
But that is not the case all the time. I think that Dale articulated t= hat clearly in the following response:

=A0
I do understand that OAuth 2.0 is used in the
wild for SSO, though I sympathize with Matt that the base flow shown in
RFC6749 Sec 1.2 just doesn't map onto the requirements for SSO.


I agree that the OAuth 2.0 "as is" does not address the SSO = requirements.
The SIP OAuth proposal is not just using OAuth 2.0 "as is", = but it is extending the framework to authenticate and provide a *user* spec= ific token.

Since Matt mentioned OpenID few times, I looked at the OpenID specific= ation.
What they are doing there is that they defined a new token, called ID = Token, that is associated with the *user*; which is exactly what the SIP OA= uth proposal is doing.

My plan is to use the same terminology, ID Token, in the next version = of the SIP OAuth document to clarify that, and to differentiate it from the= access token.

=A0
I think, though, we might usefully break uses cases here down by who the intended relying party is:

- The user's own SIP service provider (my enterprise, my carrier, my OT= T
provider)
- A third party that a user wants to authorize for a service (recording
service... But anything else?)

I would also append some use cases where the relying party:

- Someone with no association with the user (caller ID sorts of cases)

This last is where I've argued things like IdP might be relevant.


EKR has a nice description for binding IdP to OAuth in his WebRTC Secu= rity Architecture document here:

We could use the same idea for SIP.


Regards,
=A0Rifaat


=A0
Are there any other high-level buckets of use cases here?

Jon Peterson
Neustar, Inc.

On 8/25/14, 11:44 AM, "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote:

>On 8/25/14 11:50 AM, Rifaat Shekh-Yusef wrote:
>> Hi Matt,
>>
>> The use case and the solution provided assumes that the VoIP Provi= der
>> makes the decision on when and what to record.
>> While this is a valid use case, there are other use cases that all= ow the
>> user to decide on when and what to record; take a look at RFC6341 = for
>> more info.
>> http://datatracker.ietf.org/doc/rfc6341/
>
>SIPREC supports numerous topologies.
>It would support the one that Matt outlines as well as end-user
>controlled ones.
>
>I found Matt's use case interesting. I think it would be nice if su= ch
>services were available in that form. But I have difficulty imagining >any of the VoIP providers I'm aware of supporting this model. My >impression is that this means that they are giving up a value added
>revenue market, that they are loath to do. The most likely justificatio= n
>I can imagine that they don't want to legal consequences of doing >recording.
>
>=A0 =A0 =A0 =A0Thanks,
>=A0 =A0 =A0 =A0Paul
>
>> For these use cases, where the user is in control, you need to awa= y to
>> authenticate and control which users are allowed to record and the= level
>> of service provided for that specific user.
>> This is where the solutions provided in section 3 or section 4 of = the
>> SIP OAuth proposal come into play.
>> Obviously, in this case the authorization server is different from=
>> authorization server used to establish the trust relationship betw= een
>> the VoIP Provider and the CRS Provider.
>> In this case, the authorization server must authenticate the user = and
>> provide his UA with an access token or a code that controls the us= er's
>> access to the service.
>>
>> Regards,
>>=A0 =A0Rifaat
>>
>>
>>
>> On Sat, Aug 23, 2014 at 9:05 AM, Matt Ryan <ietf@mvryan.org
>> <mailto:ie= tf@mvryan.org>> wrote:
>>
>>=A0 =A0 =A0Included is the use case I spoke of before.=A0 My apolog= ies for the
>>delay.
>>
>>=A0 =A0 =A0This is written as though it could be included in
>>=A0 =A0 =A0[draft-yusef-sipcore-sip-oauth] at section 6.
>>
>>
>>=A0 =A0 =A06. Examples
>>
>>=A0 =A0 =A06.1. Example: Call Recording Service
>>
>>=A0 =A0 =A0This example illustrates the use of SIP OAuth between th= ree
>>=A0 =A0 =A0parties:=A0 A hosted VoIP service provider, a Call Recor= ding Service
>>=A0 =A0 =A0provider, and a phone system end-user.=A0 In this exampl= e:
>>=A0 =A0 =A0- The phone system end-user is a customer of both the ho= sted VoIP
>>=A0 =A0 =A0provider and the Call Recording Service provider
>>=A0 =A0 =A0- The hosted VoIP service provider is a standard provide= r of hosted
>>=A0 =A0 =A0business-class VoIP telephone service using SIP
>>=A0 =A0 =A0- The Call Recording Service provider is a distinct enti= ty from the
>>=A0 =A0 =A0hosted VoIP provider
>>
>>=A0 =A0 =A0The Call Recording Service provides to customers both th= e call
>>=A0 =A0 =A0recording abilities and management of call recordings >>=A0 =A0 =A0(configuration, sharing and distribution, retention, etc= .).=A0 This
>>=A0 =A0 =A0service can accept and record RTP traffic, associate all= RTP streams
>>=A0 =A0 =A0with a single call together, and store and catalog the r= ecorded data
>>=A0 =A0 =A0for future searching and retrieval.=A0 The service also = offers a web
>>=A0 =A0 =A0interface where customers may view and retrieve stored c= alls.
>>=A0 =A0 =A0Stored calls may range from simple person-to-person voic= e calls to
>>=A0 =A0 =A0multi-party conferences with a multitude of audio and vi= deo
>>=A0 =A0 =A0streams.=A0 In this example, customers are billed based = on the amount
>>=A0 =A0 =A0of data they store, although other models are certainly = possible.
>>
>>=A0 =A0 =A06.1.1. OAuth 2.0 Roles
>>
>>=A0 =A0 =A0In this example, each party assumes the following OAuth = 2.0 roles as
>>=A0 =A0 =A0defined in [RFC6749] Section 1.1:
>>=A0 =A0 =A0- The end-user assumes the role of resource owner
>>=A0 =A0 =A0- The hosted VoIP service provider assumes the role of c= lient
>>=A0 =A0 =A0- The Call Recording Service provider assumes the role o= f resource
>>=A0 =A0 =A0server as well as the role of authorization server
>>
>>=A0 =A0 =A06.1.2. Description
>>
>>=A0 =A0 =A0There are two parts to the example:=A0 Initial configura= tion and
>>=A0 =A0 =A0real-time recording authorization.
>>
>>=A0 =A0 =A0Each section includes a simplified flow diagram for the = purpose of
>>=A0 =A0 =A0describing the corresponding portion of the example.=A0 = For the sake
>>=A0 =A0 =A0of brevity, certain parts of the OAuth dialog have been = eliminated.
>>=A0 =A0 =A0Implements should refer to [RFC6749] for details on OAut= h.
>>
>>=A0 =A0 =A06.1.2.1 Initial Configuration
>>
>>=A0 =A0 =A0 =A0 +-------------+=A0 =A0 =A0+---------------+=A0 =A0 = =A0+--------------+
>>=A0 =A0 =A0 =A0 |=A0 End-User=A0 =A0|=A0 =A0 =A0| VoIP Provider |= =A0 =A0 =A0| CRS Provider |
>>=A0 =A0 =A0 =A0 | Web Browser |=A0 =A0 =A0|=A0 =A0 Website=A0 =A0 |= =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 +-------------+=A0 =A0 =A0+---------------+=A0 =A0 = =A0+--------------+
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| HTTP 1=A0 =A0 =A0 =A0 =A0 =A0 =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| (Configure CRS)=A0 =A0 |=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|------------------->|=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| HTTP 2=A0 =A0 =A0 =A0 =A0 =A0 =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| (OAuth Redirect=A0 =A0 |=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 to CRS Website)=A0 =A0|=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<-------------------|=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| HTTP 3=A0 =A0 =A0 =A0 =A0 =A0 =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| (Authorize SIP from VoIP provider= =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|-----------------------------------= ------>|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| HTTP 4=A0 =A0 =A0 =A0 =A0 =A0 =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| (OAuth Redirect back to VoIP porta= l)=A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|<-------------------------------= ----------|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| HTTP 5=A0 =A0 =A0 =A0 =A0 =A0 =A0|= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|------------------->|=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | HTTP 6=A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | (Request Access and |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 refresh tokens)=A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |-------------------->|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>
>>=A0 =A0 =A0Some time after having signed up for both services, but = prior to
>>=A0 =A0 =A0attempting to record any calls, the end-user logs into t= he web
>>=A0 =A0 =A0portal of the hosted VoIP provider with a web browser an= d configures
>>=A0 =A0 =A0their call recording service (HTTP 1).=A0 This configura= tion includes
>>=A0 =A0 =A0providing a URI where the call recording service may be = reached,
>>=A0 =A0 =A0along with a set of API credentials, provided by the cal= l recording
>>=A0 =A0 =A0service, which will allow the client to initiate an OAut= h exchange.
>>=A0 =A0 =A0The end-user also configures the conditions under which = call
>>=A0 =A0 =A0recordings should take place.=A0 For example, the end-us= er may request
>>=A0 =A0 =A0to record every multi-party (conference) call, or every = call
>>=A0 =A0 =A0involving a specific set of users.=A0 The end-user may a= lso specify
>>=A0 =A0 =A0other restrictions, such as restricting codec negotiatio= n to G.711u
>>=A0 =A0 =A0for audio and H.264 for video in order to record the RTP= streams.
>>=A0 =A0 =A0Once the end-user saves the configuration, the hosted Vo= IP provider
>>=A0 =A0 =A0web portal redirects the end-user's web browser to t= he call
>>=A0 =A0 =A0recording service website and a standard HTTP OAuth dial= og begins
>>=A0 =A0 =A0(HTTP 2).=A0 The end-user authorizes the hosted VoIP pro= vider to
>>=A0 =A0 =A0access (i.e. send SIP and RTP traffic to) the call recor= ding
>>=A0 =A0 =A0service, for the purpose of recording calls, so long as = the
>>=A0 =A0 =A0configured conditions are met (HTTP 3).=A0 The result of= this
>>=A0 =A0 =A0interaction is that the hosted VoIP provider ends up rec= eiving an
>>=A0 =A0 =A0OAuth access token and refresh token from the call recor= ding service
>>=A0 =A0 =A0(HTTP 4, HTTP 5, HTTP 6).=A0 These tokens are saved in t= he end-user's
>>=A0 =A0 =A0hosted VoIP account database.
>>
>>=A0 =A0 =A06.1.2.2 Real-time Recording Authorization
>>
>>=A0 =A0 =A0 =A0 +-------------+=A0 =A0 =A0+---------------+=A0 =A0 = =A0 +--------------+
>>=A0 =A0 =A0 =A0 |=A0 End-User=A0 =A0|=A0 =A0 =A0| VoIP Provider |= =A0 =A0 =A0 | CRS Provider |
>>=A0 =A0 =A0 =A0 |=A0 SIP Phone=A0 |=A0 =A0 =A0|=A0 =A0 Website=A0 = =A0 |=A0 =A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 +-------------+=A0 =A0 =A0+---------------+=A0 =A0 = =A0 +--------------+
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| SIP INVITE 1=A0 =A0 =A0 =A0|=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|------------------->|=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP INVITE 2=A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | (with access token)=A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |--------------------->|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP 401 Unauthorized |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |<---------------------|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP INVITE 3=A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | (with refresh token) |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |--------------------->|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP 200 1=A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | (new access token)=A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |<---------------------|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP INVITE 4=A0 =A0 =A0 =A0 =A0|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | (with access token)=A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |--------------------->|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 | SIP 200 2=A0 =A0 =A0 =A0 =A0 =A0 |
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |<---------------------|
>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>
>>=A0 =A0 =A0Independently of and after the initial configuration pha= se, the
>>=A0 =A0 =A0end-user makes a telephone call using the hosted VoIP pr= ovider (SIP
>>=A0 =A0 =A0INVITE 1).=A0 When this call takes place, the hosted VoI= P provider
>>=A0 =A0 =A0looks to see whether it believes this call should be rec= orded.=A0 If
>>=A0 =A0 =A0so, at this point it would branch the call session to th= e call
>>=A0 =A0 =A0recording service, using SIP OAuth to pass the previousl= y provided
>>=A0 =A0 =A0access token for authorization (SIP INVITE 2).=A0 Once t= he access
>>=A0 =A0 =A0token is validated by the call recording service (perhap= s after
>>=A0 =A0 =A0first providing a new access token based on receipt of a= valid
>>=A0 =A0 =A0refresh token), the call recording service will check th= e rights
>>=A0 =A0 =A0that were previously authorized and examine the SIP to d= etermine
>>=A0 =A0 =A0whether it can accept the call.=A0 If so, it completes t= he
>>=A0 =A0 =A0establishment of the session and begins receiving and re= cording the
>>=A0 =A0 =A0RTP stream(s) (SIP 200 OK).=A0 The call recording servic= e provider
>>=A0 =A0 =A0could also deny the request, either because the tokens a= re invalid
>>=A0 =A0 =A0or because the content of
>>=A0 =A0 =A0 =A0the SIP invite does not match the previously authori= zed
>>=A0 =A0 =A0conditions, in which case a SIP 403 would be returned by= the call
>>=A0 =A0 =A0recording service provider and the call would not be rec= orded -
>>=A0 =A0 =A0however, the initial call branch would continue without<= br> >>interruption.
>>
>>=A0 =A0 =A0Note:
>>=A0 =A0 =A0[RFC6749] specifies that when a client uses a refresh to= ken to
>>=A0 =A0 =A0request a new access token, the response is HTTP 200 wit= h the new
>>=A0 =A0 =A0access token and optionally a new refresh token included= in the
>>=A0 =A0 =A0payload.=A0 In this example, a SIP 200 response (SIP 200= 1) is sent
>>=A0 =A0 =A0which contains the new token(s).=A0 However, this could = be confusing
>>=A0 =A0 =A0as SIP 200 is generally viewed as the acceptance of the = INVITE,
>>=A0 =A0 =A0which is not what is happening in this case.=A0 Should S= IP 200 be used
>>=A0 =A0 =A0for consistency, or should another mechanism be used? >>
>>=A0 =A0 =A06.1.3. Justification
>>
>>=A0 =A0 =A06.1.3.1. Hosted VoIP Service Provider
>>
>>=A0 =A0 =A0In this example, the hosted VoIP service provider can al= low their
>>=A0 =A0 =A0customers to enable call recording in their VoIP service= by
>>=A0 =A0 =A0selecting from any of a number of supported call recordi= ng service
>>=A0 =A0 =A0providers.=A0 This allows the hosted VoIP service provid= er to offer
>>=A0 =A0 =A0this feature to customers without requiring that the hos= ted VoIP
>>=A0 =A0 =A0service provider implement and support this feature them= selves.
>>
>>=A0 =A0 =A06.1.3.2. Call Recording Service Provider
>>
>>=A0 =A0 =A0In this example, the Call Recording Service provider can= focus on
>>=A0 =A0 =A0value and innovation in the area of recording calls and = managing
>>=A0 =A0 =A0recorded calls without having to build a full-featured t= elephony
>>=A0 =A0 =A0offering.
>>
>>=A0 =A0 =A06.1.3.3. Customer
>>
>>=A0 =A0 =A0In this example, the customer has more flexibility in ch= oosing a
>>=A0 =A0 =A0complete solution that meets all of the customer needs.= =A0 The
>>=A0 =A0 =A0customer does not have to settle for a substandard call = recording
>>=A0 =A0 =A0service offering in order to obtain other features they = seek in a
>>=A0 =A0 =A0hosted VoIP provider, and vice versa.
>>
>>=A0 =A0 =A06.1.4. Variants
>>
>>=A0 =A0 =A0A simple variant of this example is one wherein one of t= he services
>>=A0 =A0 =A0(either the VoIP service or the call recording service) = is managed
>>=A0 =A0 =A0directly by the end-user, but the other is not.=A0 For e= xample, the
>>=A0 =A0 =A0end-user may wish to make use of an external hosted VoIP= service
>>=A0 =A0 =A0provider, but may have business or legal reasons that fo= rbid the
>>=A0 =A0 =A0end-user from allowing a third party to store and manage= recorded
>>=A0 =A0 =A0calls.=A0 The end-user could choose to set up their own = call recording
>>=A0 =A0 =A0service as described in this example, and use SIP OAuth = to
>>=A0 =A0 =A0facilitate interaction between the hosted VoIP service a= nd the
>>=A0 =A0 =A0end-user's own call recording service.
>>
>>=A0 =A0 =A06.2. Other SIP OAuth examples
>>
>>=A0 =A0 =A0Many other SIP-based services could leverage SIP OAuth t= o provide
>>=A0 =A0 =A0value-added service to an end-user of a hosted VoIP serv= ice
>>=A0 =A0 =A0provider.=A0 Some examples of these types of services ar= e listed
>>below.
>>
>>=A0 =A0 =A0Voicemail service provider:=A0 The end-user configures t= heir hosted
>>=A0 =A0 =A0VoIP service provider to manage voicemail through a sepa= rate
>>=A0 =A0 =A0voicemail service provider, which chooses whether to sto= re voicemail
>>=A0 =A0 =A0based on existing quotas, Caller ID, etc.
>>
>>=A0 =A0 =A0Conferencing service provider:=A0 A conferencing service= may wish to
>>=A0 =A0 =A0bill customers in a more granular fashion, for example, = based on the
>>=A0 =A0 =A0number of participants and attendees in a conference, th= e duration
>>=A0 =A0 =A0of conference, whether video was also included, which co= decs were
>>=A0 =A0 =A0being used, etc. instead of a flat monthly rate.=A0 SIP = OAuth would
>>=A0 =A0 =A0facilitate metered authorization for a client's use = of the service,
>>=A0 =A0 =A0instead of all-or-nothing access.
>>
>>=A0 =A0 =A0Call center service provider:=A0 A third party may provi= de ring groups
>>=A0 =A0 =A0or call queues for a hosted VoIP provider along with det= ailed
>>=A0 =A0 =A0reports and dashboards.=A0 The end-user uses OAuth over = SIP to control
>>=A0 =A0 =A0who can log into which queues or ring groups, etc.
>>
>>
>>
>>=A0 =A0 =A0--
>>=A0 =A0 =A0Matt Ryan
>>=A0 =A0 =A0code slinger | zoomulus.com <http://zoomulus.com>
>>=A0 =A0 =A0ietf at mvryan dot org
>>
>>
>>
>>
>>=A0 =A0 =A0_______________________________________________
>>=A0 =A0 =A0sipcore mailing list
>>=A0 =A0 =A0si= pcore@ietf.org <mailto:sipcore@ietf.org>
>>=A0 =A0 =A0https://www.ietf.org/mailman/listinfo/sipcore
>>
>>
>>
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf= .org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>
>_______________________________________________
>sipcore mailing list
>sipcore@ietf.org<= /a>
>https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore



--089e013d175e4e2887050342c210-- From nobody Thu Sep 25 08:34:18 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D511A0174 for ; Thu, 25 Sep 2014 08:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nflDfN-1HsHM for ; Thu, 25 Sep 2014 08:34:14 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B84951A7006 for ; Thu, 25 Sep 2014 08:34:13 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-7b-542435f32c19 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 32.38.21432.3F534245; Thu, 25 Sep 2014 17:34:11 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Thu, 25 Sep 2014 17:34:11 +0200 From: Christer Holmberg To: Rifaat Shekh-Yusef , "Peterson, Jon" Thread-Topic: [sipcore] A SIP OAuth use case Thread-Index: AQHPvtLkDukB9S5lmka5p3A9Sdf1J5vhWWKAgAAwjgCADjpnAIABRvKAgACFNgCADeNFAIADI96AgAK+CQCADNdi4A== Date: Thu, 25 Sep 2014 15:34:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D45BB30@ESESSMB209.ericsson.se> References: <10D4F263-37CF-4A74-8F23-EBA9E5010E02@mvryan.org> <53FB83FA.8010101@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D45BB30ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3RvezqUqIwbp3hhZnGiwtdr5oZbP4 +mMTmwOzx85Zd9k9liz5yeSxo+E5cwBzFJdNSmpOZllqkb5dAldG6zSxgtO1FVe6+5gbGL/m djFyckgImEicXHqcBcIWk7hwbz0biC0kcJRRorUhpIuRC8hewigx++MO1i5GDg42AQuJ7n/a IDUiAjESHyZ2gfUyC2hKPNq5lwnEFhbQlvh57hojRI2OxJ/Gn2wQdpbExeZZYHEWAVWJQ4sO sYPYvAK+EqtPnWOE2NXAInH0/i0WkF2cAoESx+ZpgtQwAt32/dQaJohd4hK3nsxngrhZQGLJ nvPMELaoxMvH/1ghbCWJtYe3Q92WL7F0z1RmiF2CEidnPmGZwCg6C8moWUjKZiEpg4jrSCzY /YkNwtaWWLbwNTOMfebAYyZk8QWM7KsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAqPv4Jbf BjsYXz53PMQowMGoxMOrUK4cIsSaWFZcmXuIUZqDRUmcd+G5ecFCAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGNOMtq1afP/m7xz/Z8+Mn/5RfdSXvvjCBu/zDHqx3TL3C+UiBZ92t/J/nts3 PWGby6M703//0NVaxZVXa9H34b7u3PYfpesvLn97o+b953752yK8M0xXbX/s/ky/Q3jZiWTj C9f1P3TdfCJSX6SwfmZ/8iHLtae7b3+1t+a9czFDx3WmsFlstIsSS3FGoqEWc1FxIgDmFKQ4 nwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Q-YCxEVUjP8e3sdtgyurouzn_nU Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A SIP OAuth use case X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 15:34:16 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D45BB30ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >What I am proposing is something along the lines of OpenID, which extends = the OAuth to >authenticate the *user*. >In this case, the mapping between OAuth and SIP would be something like th= e following: > >OAuth SIP >--------------------------------------------------------------------------= - >Resource Owner End User >Resource Server SIP Proxy or SIP Application Server >Client SIP UA >Authorization Server Authorization Server > >Do you see a problem with this model? As I indicated earlier, this is a little different mapping than the one don= e by 3GPP. OAuth role IMS role Resource Owner IMS subscriber Client WWSF Authorization Server WAF Resource Server IMS network (copied text) WWSF (WebRTC Web Server Function) - Acts as web server, from where the user downloads the IMS access= application. WAF (WebRTC Authorisation Function) - Acts as the authorization server (the "facebook"), and issues th= e authorization tokens. (The WWSF and WAF can, but does not have to, be located in the same domain = as the IMS provider.) I guess the important thing to note here is that the IMS core network (incl= uding the registrar/S-CSCF and HSS) does not act as Authorization Server, b= ut rather as the Resource Server. In fact, the IMS core network itself does not even need to support OAuth2.0= . Instead the WAF performs mapping and verification between "legacy IMS cre= dentials" and "web credentials" (e.g. OAuth2.0). The detailed procedures fo= r that mapping/verification is not specified in the current 3GPP release. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D45BB30ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

>What I am p= roposing is something along the lines of OpenID, which extends the OAuth to >authenticate the *user*.

>In this cas= e, the mapping between OAuth and SIP would be something like the following:=

> =

>OAuth  = ;                     &nb= sp;            SIP

>-----------= ----------------------------------------------------------------=

>Resource Ow= ner                    En= d User

>Resource Se= rver                    S= IP Proxy or SIP Application Server

>Client &nbs= p;                     &n= bsp;             SIP UA

>Authorizati= on Server             Authorization Server

> =

>Do you see = a problem with this model?

 

As I indicated earlier, t= his is a little different mapping than the one done by 3GPP.

 <= /p>

OAuth role  =             &nb= sp;            =           IMS role<= /span>

 <= /p>

Resource Owner  = ;            &n= bsp;            IMS = subscriber

Client   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      WWSF

Authorization Server = ;            &n= bsp;      WAF

Resource Server &nbs= p;            &= nbsp;           &nbs= p; IMS network

 <= /p>

(copied text)<= /span>

 

WWSF (WebRTC Web Server Function)

-     &= nbsp;    Acts as web server, from where the user downloads t= he IMS access application.

WAF (WebRTC Authorisation Function)

-     &= nbsp;    Acts as the authorization server (the “facebo= ok”), and issues the authorization tokens.

 

(The WWSF and WAF can, but does not have to, be loca= ted in the same domain as the IMS provider.)

 

I guess the important thing to note here is that the= IMS core network (including the registrar/S-CSCF and HSS) does not act as = Authorization Server, but rather as the Resource Server.

 

In fact, the IMS core network itself does not even n= eed to support OAuth2.0. Instead the WAF performs mapping and verification = between “legacy IMS credentials” and “web credentialsR= 21; (e.g. OAuth2.0). The detailed procedures for that mapping/verification is not specified in the current 3GPP release.

 

Regards,

 

Christer

 <= /p>

 <= /p>

 <= /p>

--_000_7594FB04B1934943A5C02806D1A2204B1D45BB30ESESSMB209erics_--