Re: [rtcweb] Regarding the use-case document

[Harald Alvestrand <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Stefan Hakansson LK
> Sent: Thursday, May 31, 2012 3:28 AM
> To: Ravindran, Parthasarathi
> Cc: [e-mail]
> 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: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of Stefan Hakansson LK
>>> Sent: Wednesday, May 30, 2012 2:24 PM To: [e-mail] 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
>>> [e-mail] https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>