Subject: Re: [rtcweb] Regarding the use-case document

From: Harald Alvestrand <[email-masked]>
Date: Fri, 01 Jun 2012 09:37:26 +0200

I'm starting to think that we need to encapsulate the identity work somehow.

It's clear that there needs to be a basic set of tools exposed from the 
lower layer RTCWEB work (chiefly DTLS, and possibly EKT) to support 
identity assertions about communications partners.

But it's clear that our current use cases document doesn't adequately 
cover requirements on what kind of identity can exist, and what 
information they need to be able to verify about each other - and that's 
a rather big undertaking to get right.

draft-ietf-rtcweb-identity-use-cases, anyone?

                   Harald

On 05/31/2012 03:04 PM, Jim Barnett wrote:
> Yes, let's set aside some time to discuss this at the interim.  When I brought up call center use cases a while ago, we reached the conclusion that the webRTC endpoint was the corporate gateway/ACD and that anything behind it (including the agent) was out of scope (which is another way of saying that it could work any way the corporation wanted.)  The result was that call centers fell under legacy inter-op and no changes were needed to the use cases.
>
> In general corporate/call center uses of webRTC will be important, so it's worth going over this once more to make sure we agree on how they fit into the framework.
>
> - Jim
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Hakansson LK
> Sent: Thursday, May 31, 2012 3:28 AM
> To: Ravindran, Parthasarathi
> Cc: [email-masked]
> Subject: Re: [rtcweb] Regarding the use-case document
>
> On 05/30/2012 11:31 AM, Ravindran, Parthasarathi wrote:
>> Stefan,
>>
>>
>> 1) I have mentioned in Call Center [2] usecase calls for "Anonymous"
>> identity for agents
>> (http://www.ietf.org/mail-archive/web/rtcweb/current/msg04295.html)
>> and also Andrew Hutton mentioned the same in the another mail
>> (http://www.ietf.org/mail-archive/web/rtcweb/current/msg04221.html)
>>
>> 2) Also in another mail thread, "Anonymous" identity for customer is
>> discussed  as part of
>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04254.html
>>
>> In case any more information required for clarity, please let me know.
>> Also, I'm fine with discussion about these usecase in interim meeting.
> Hi Partha,
>
> I would prefer if we discussed this at the interim before adding. The main reason is that the use-case document, and requirements, currently focus on media and data streams. When doing the first draft we deliberately left things like identity handling, find-and-connect and so on out of scope.
>
> This was partly inspired by the charter (that talks about enabling innovation on top of a set of basic components - those being peer-to-peer audio, video and data) and partly from that there are already a lot of web services used every day which has solved this - they have implemented presence, text chat, messaging, ... already and in theory it would be simple to add video etc. if we just got those "basic components" in place.
>
> If the use-case document is to be updated to cover things like identity, user management and so on that would be a big change, and I would prefer that to be discussed before starting actual work.
>
> Br,
> Stefan
>
>> Thanks Partha
>>
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Stefan Hakansson LK
>>> Sent: Wednesday, May 30, 2012 2:24 PM To: [email-masked] Subject:
>>> [rtcweb] Regarding the use-case document
>>>
>>> The rtcweb chairs asked for input on the use-case document on April
>>> 27th [1].
>>>
>>> Browsing the emails that followed, I note:
>>>
>>> 1. Proposal for a call center use case (made by Jim Barnett) [2]
>>>
>>> 2. Proposal to add peer-to-peer file sharing to the simple video comm
>>> service (made by Tim Terriberri) [3]
>>>
>>> 3. Comments related to security, SRTP and key exchange, F20 (by Dan
>>> Wing) [4]
>>>
>>> 4. Request for clarifying "eavesdropping", Andrew Hutton [5]
>>>
>>> 5. Enterprise policies use-cases proposed, Roman Shpount [6]
>>>
>>> 6. Multiparty with low complex central node, Stefan Håkansson [7]
>>>
>>> 7. Multiparty with central node that can not decipher media Oscar
>>> Ohlsson [8]
>>>
>>> 8. Four new reqs proposed (to be mapped to either new or existing
>>> use- cases), one additional use-case proposed, by Cullen Jennings
>>> [9]. Reqs: 8a. Req: When A calls B, B does not reveal their IP
>>> address to A 8b. Req: B can tell that the encrypted media is from A
>>> and not from a MITM 8c. Req: Be able to switch off Voice activity
>>> detection (if present) 8d. Req: Be able to prioritize between streams
>>> New use-case: "Collaboration between companies with node [in media
>>> path] that does/can not decipher media"
>>>
>>> 9. Proposal from Magnus Westerlund to clarify the language a bit [10]
>>> regarding 4. in this list
>>>
>>> Is anything important missing from the list above?
>>>
>>> Going through this list (and the discussion that followed on each
>>> item) it seems quite clear that:
>>>
>>> A. The language should be clarified (as Magnus proposed [10]), e.g.
>>> to clarify that also the data channel should be encrypted (this
>>> relates to 3. and 9. in the previous list)
>>>
>>> B. One more derivative of the "Simple Video Communication Service"
>>> use-case should be added to add peer-to-peer file sharing (this
>>> proposal got some support, no objection, and was also mentioned many
>>> times during the MV interim)
>>>
>>> C. There is no need to clarify "eavesdropping" (item 4. in the
>>> previous list); EKR proposed to do that as part of the security
>>> document instead
>>>
>>> D. For the new requirements proposed by Cullen (8a - d in the
>>> previous list), 8a and 8b can be incorporated in existing use cases,
>>> 8c is already covered in the "Distributed Music Band"
>>> use-case, 8d can be added to the "Hockey Game Viewer" use case.
>>> Regarding 8d it can be noted that there is already a requirement on
>>> "being able to use priority functions in network nodes" (F24); 8d
>>> would be different and relate more to how the browser reduces send
>>> rate for different flows as a response to e.g. network congestion.
>>> The reqs seem  uncontroversial to me.
>>>
>>> Unless there are objections to this, the editors plan to update the
>>> document according to A - D above.
>>>
>>>
>>>
>>> It is less clear on what to do regarding the call-center use case
>>> [2], the enterprise policies use-cases [6] and the two use-cases
>>> where a central node (in the media path) must not be able to access
>>> deciphered media [8] and [9]; I think this should be discussed at the
>>> interim meeting.
>>>
>>> Comments?
>>>
>>> Stefan
>>>
>>> [1]
>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04202.html
>>> [2]
>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04203.html
>>> [3]
>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04204.html
>>> [4]
>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04205.html
>>> [5]
>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04241.html
>>> [6]
>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04271.html
>>> [7]
>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04430.html
>>> [8]
>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04457.html
>>> [9]
>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04461.html
>>> [10]
>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04214.html
>>> _______________________________________________ rtcweb mailing list
>>> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Göran Eriksson AP <[email-masked]>
Date: Fri, 1 Jun 2012 09:42:15 +0200

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Harald Alvestrand
> Sent: den 1 juni 2012 09:37
> To: Jim Barnett
> Cc: [email-masked]
> It's clear that there needs to be a basic set of tools 
> exposed from the lower layer RTCWEB work (chiefly DTLS, and 
> possibly EKT) to support identity assertions about 
> communications partners.
> 
> But it's clear that our current use cases document doesn't 
> adequately cover requirements on what kind of identity can 
> exist, and what information they need to be able to verify 
> about each other - and that's a rather big undertaking to get right.
> 

This could easily become a Pandoras box, right? We need the hooks, but at the same time
not solve the whole identity area.

Do You have any idea as to how to limit the scope of this? A proposal that we can discuss in the
interim meeting could perhaps be useful.

> > Yes, let's set aside some time to discuss this at the 
> interim.  When I brought up call center use cases a while 
> ago, we reached the conclusion that the webRTC endpoint was 
> the corporate gateway/ACD and that anything behind it 
> (including the agent) was out of scope (which is another way 
> of saying that it could work any way the corporation wanted.) 
>  The result was that call centers fell under legacy inter-op 
> and no changes were needed to the use cases.
> >
> > In general corporate/call center uses of webRTC will be 
> important, so it's worth going over this once more to make 
> sure we agree on how they fit into the framework.
> >
> > - Jim
> >
> > I would prefer if we discussed this at the interim before 
> adding. The main reason is that the use-case document, and 
> requirements, currently focus on media and data streams. When 
> doing the first draft we deliberately left things like 
> identity handling, find-and-connect and so on out of scope.
> >
> > This was partly inspired by the charter (that talks about 
> enabling innovation on top of a set of basic components - 
> those being peer-to-peer audio, video and data) and partly 
> from that there are already a lot of web services used every 
> day which has solved this - they have implemented presence, 
> text chat, messaging, ... already and in theory it would be 
> simple to add video etc. if we just got those "basic 
> components" in place.
> >
> > If the use-case document is to be updated to cover things 
> like identity, user management and so on that would be a big 
> change, and I would prefer that to be discussed before 
> starting actual work.
> >
> > Br,
> > Stefan
> >
> >> Thanks Partha
> >>
> >>> 2. Proposal to add peer-to-peer file sharing to the simple video 
> >>> comm service (made by Tim Terriberri) [3]
> >>>
> >>> detection (if present) 8d. Req: Be able to prioritize between 
> >>> streams New use-case: "Collaboration between companies 
> with node [in 
> >>> media path] that does/can not decipher media"
> >>>
> >>> 9. Proposal from Magnus Westerlund to clarify the language a bit 
> >>> [10] regarding 4. in this list
> >>>
> >>> deciphered media [8] and [9]; I think this should be discussed at 
> >>> the interim meeting.
> >>>
> >>> Comments?
> >>>
> >>> Stefan
> >>>
> >>> [1]

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Fri, 1 Jun 2012 08:51:59 +0000

Harald,

Thanks for providing support for adding identity related usecases. As Stefan mentioned in the below mail, the authors deliberately excluded identity usecases initially. The single RTCWeb usecase document will give better picture over multiple usecase document as the solution of RTCWeb identity, security, media has the linkage. I'll wait for usecase document Editors opinion and interim discussion here.

Having said that in case it is decided not to add RTCWeb identity usecases within the current RTCWeb usecases document as it is big change, it will be better to work for draft-ietf-rtcweb-identity-use-cases and I volunteer to be one of the document reviewer & provide inputs.

Thanks
Partha

>From: Harald Alvestrand [mailto:[email-masked]]
>Sent: Friday, June 01, 2012 1:07 PM
>To: Jim Barnett
>Cc: Stefan Hakansson LK; Ravindran, Parthasarathi; [email-masked]
>> Yes, let's set aside some time to discuss this at the interim.  When I
>brought up call center use cases a while ago, we reached the conclusion
>that the webRTC endpoint was the corporate gateway/ACD and that anything
>behind it (including the agent) was out of scope (which is another way
>of saying that it could work any way the corporation wanted.)  The
>result was that call centers fell under legacy inter-op and no changes
>were needed to the use cases.
>>
>> In general corporate/call center uses of webRTC will be important, so
>it's worth going over this once more to make sure we agree on how they
>fit into the framework.
>>
>> - Jim
>>
>> I would prefer if we discussed this at the interim before adding. The
>main reason is that the use-case document, and requirements, currently
>focus on media and data streams. When doing the first draft we
>deliberately left things like identity handling, find-and-connect and so
>on out of scope.
>>
>> This was partly inspired by the charter (that talks about enabling
>innovation on top of a set of basic components - those being peer-to-
>peer audio, video and data) and partly from that there are already a lot
>of web services used every day which has solved this - they have
>implemented presence, text chat, messaging, ... already and in theory it
>would be simple to add video etc. if we just got those "basic
>components" in place.
>>
>> If the use-case document is to be updated to cover things like
>identity, user management and so on that would be a big change, and I
>would prefer that to be discussed before starting actual work.
>>
>> Br,
>> Stefan
>>
>>> Thanks Partha
>>>
>>>> streams New use-case: "Collaboration between companies with node [in