Re: [sipcore] A SIP OAuth use case

[Rifaat Shekh-Yusef <[e-mail]>]

Thanks for the detailed response Jon.
Please, see my reply inline...

Regards,
 Rifaat


On Tue, Oct 7, 2014 at 7:01 PM, Peterson, Jon <[e-mail]>
wrote:

>
>  I know I've owed you a response to this one for a while... Still just
> trying to understand the requirements.
>
>  I suspect that application services in the enterprise, the ones that you
> worry about maintaining ACLs, don't get to avoid having "a separate user
> directory" so easily. A classic voicemail service, for example, needs to
> keep voicemails for Alice separate from Bob - that's why typically it
> authenticates who Alice and Bob are.
>

I obviously agree that the service must keep separate boxes for their users
and it must authenticate the user to allow access to a specific box, but I
am not sure that the authentication must be done by the voicemail server
itself.
The authentication could be done by an Authorization Server and as a result
the SIP endpoint would be given an ID Token, as per OpenID, which proves
the identity of the end user. The SIP endpoint will be able to use the ID
Token to get access to the user's box. The voicemail server will be able to
identify the user and verify the validity of the ID Token because the token
has the signature of an Authorization Server that the voicemail server
trusts.



> Such a service must have effectively a "directory" of separate users that
> effectively implies ACLs.
>
>
The ID Token could also have a scope that controls the services and level
of service provided to the user.




>  Now if, as you say:
>
>  > 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.
>
>  What is your app server using that ID and credentials for, if not to
> compare to something that is effectively an ACL - like, to prevent Alice
> from getting Bob's voicemail? My point earlier was that if all you care
> about is showing that someone is Alice or Bob (or just that they're an
> authenticated user and it doesn't matter who), then a solution to the
> requirements could look very similar to RFC4474 or STIR: you just need
> authentication, not authorization, and calling it authorization is just
> confusing the issue.
>
>
I care about both, authentication and authorization, and my argument is
that an ID Token could be used to provide the needed user authentication,
and the scope associated with the ID Token could be used to provide the
authorization to control access to services for that specific user.



>  But, there's a different approach here, one where a service doesn't need
> to know IDs or credentials or anything about users.
>

In this specific case, the service obviously needs to know the user ID, but
it does not have to know the user's credentials to authorize access to the
voicemail box.



> This is an approach where I just get a token from an authorization
> service, and hand that token to the app service, and the app service uses
> that token *instead of* my ID or credentials or any personal profile about
> me.
>

As I mentioned above, the ID Token proves your identity and has a scope
that controls your access to services.



> I can imagine a very odd voicemail service that, rather than putting
> messages into buckets for Alice and Bob, put them all into one generic
> bucket - and then an outside authorization service kept track of the fact
> that messages 2, 17, and 109 are for Alice. When Alice requests access to
> her voicemail from the authorization service, it gives her a token that
> proves to the voicemail service that she is allowed to access only messages
> 2, 17, and 109, and she can only do it in the next five minutes, say, to
> prevent capture and replay. The voicemail service then has no idea who she
> is or who those messages are for, it just ponies them up. If *that* is what
> you said above, at least I would understand why you want to use OAuth - it
> would be a terrible architecture (the authZ service keeps track of those
> messages how exactly?), but at least this is what OAuth is for. The
> architectures make more sense with third parties.
>
>
That obviously does not make sense for a voicemail service,

But, let's take a look at a different example; an adhoc conference server:
I can imagine an adhoc conference server that accepts requests to allocate
a focus to a user based on the ID Token provided in the incoming request.
The ID Token proves the identity of the user and provides a scope to
control the level of service provided to the user. The conference server
will be able to verify the validity of the ID Token because the token has
the signature of an Authorization Server that the conference server trusts.
In this specific case, do you see a need for the conference server to
maintain a user directory?

In any case, I am not trying to completely get rid of user directory from
all services, but mainly to get rid of the need to maintain separate user
identities and credentials per service.
Ideally, I would like the user to have one identity and be able to use that
identity to authenticate and get access to all services in the enterprise.


 A third approach would be problems we looked at as "trait-based"
> authorization problems. The classic example is where for some service,
> perhaps it matters whether Alice is in the Engineering department or the
> Finance department, rather than who Alice is exactly. Maybe those're the
> sort of elements you mean by "user profile." We did a whole requirements
> process years ago on "trait-based" authorization mechanisms intended to
> satisfy cases like this: see RFC4484. You'll note it shows architectures
> where a SIP endpoints point by-reference to HTTP objects that contain
> authorization policy elements like such "traits." There are a bunch of
> solutions for that space, too, but if that's what you want, then my
> question for you would be, do you have any requirements beyond what's
> defined in RFC4484 Sec. 5?
>
>
I have never read RFC4484 before; I will take a look.

Regards,
 Rifaat





>  Jon Peterson
> Neustar, Inc.
>
>   From: Rifaat Shekh-Yusef <[e-mail]>
> Date: Wednesday, September 17, 2014 at 6:22 AM
>
> To: Jon Peterson <[e-mail]>
> Cc: Paul Kyzivat <[e-mail]>, "[e-mail]" <
> [e-mail]>
> Subject: Re: [sipcore] A SIP OAuth use case
>
>
>
> On Mon, Sep 15, 2014 at 3:29 PM, Peterson, Jon <[e-mail]>
> 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 <[e-mail]>
>> Date: Saturday, September 13, 2014 at 12:32 PM
>>
>> To: Jon Peterson <[e-mail]>
>> Cc: Paul Kyzivat <[e-mail]>, "[e-mail]" <
>> [e-mail]>
>> Subject: Re: [sipcore] A SIP OAuth use case
>>
>>
>>
>> On Thu, Sep 4, 2014 at 7:27 PM, Peterson, Jon <[e-mail]>
>> 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 <[e-mail]>
>>> Date: Thursday, September 4, 2014 at 8:31 AM
>>> To: Jon Peterson <[e-mail]>
>>> Cc: Paul Kyzivat <[e-mail]>, "[e-mail]" <
>>> [e-mail]>
>>> Subject: Re: [sipcore] A SIP OAuth use case
>>>
>>>
>>>
>>>
>>> On Wed, Sep 3, 2014 at 4:00 PM, Peterson, Jon <[e-mail]>
>>> 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" <[e-mail]> 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 <[e-mail]
>>>> >> <mailto:[e-mail]>> 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 <http://zoomulus.com>
>>>> >>     ietf at mvryan dot org
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>     _______________________________________________
>>>> >>     sipcore mailing list
>>>> >>     [e-mail] <mailto:[e-mail]>
>>>> >>     https://www.ietf.org/mailman/listinfo/sipcore
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> _______________________________________________
>>>> >> sipcore mailing list
>>>> >> [e-mail]
>>>> >> https://www.ietf.org/mailman/listinfo/sipcore
>>>> >>
>>>> >
>>>> >_______________________________________________
>>>> >sipcore mailing list
>>>> >[e-mail]
>>>> >https://www.ietf.org/mailman/listinfo/sipcore
>>>>
>>>> _______________________________________________
>>>> sipcore mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>
>>>
>>>
>>
>