Re: [Rum] Configuration file

[Paul Kyzivat <[e-mail]>]

On 10/21/20 12:04 PM, Brian Rosen wrote:
> Yeah, my model was different.  It assumed that whatever was done by the 
> provider, the result was a single local file.
> 
> I’m not wedded to that.  We do need at least a piece of that to know 
> which providers to look for, but a file per provider, downloaded when 
> it’s needed is okay.

Yes, the list of providers needs to be from a single source. That will 
present some administration challenges. But I don't think it makes sense 
for the providers to populate that with all the details needed for a RUE 
to connect to them.

It occurs to me that we might be able to get away with using DNS to hold 
the list of providers - avoiding the need to stand up a special server 
for that purpose.

I'm thinking that the RUE have a way to present the user with a list of 
available providers. The user would be able to select one and then ask 
to enroll with it. Then the user would get a browser connection to an 
enrollment page where he would sign up for service, be assigned a user 
name, password, and phone number. Then the device would connect to the 
config download service of the provider and download the configuration 
file. The RUE would save this. The RUE would then use the configuration 
info to do a SIP registration and be ready to both receive and initiate 
calls.

The RUE could do this for multiple providers. The result would 
presumably be a UI for something akin to a multi-line phone. (Remember 
those from the old days?)

	Thanks,
	Paul

> Brian
> 
> 
>> On Oct 21, 2020, at 11:55 AM, Paul Kyzivat <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> On 10/20/20 3:15 PM, Brian Rosen wrote:
>>> This is still an open item and distinct from the “signed code” issue 
>>> we’ve been discussing.
>>> The current text describes a single file that can have multiple sets 
>>> of provider configuration data.  This caters to the common case of a 
>>> user having more than provider account.  The problem with the text is 
>>> it has plaintext username/passwords, which is clearly wrong.
>>> I see two solutions: require the local implementation to maintain a 
>>> password (or other multi factor authentication, and encrypt the file 
>>> so that the user needs to authenticate to access the file.  Paul is 
>>> worried that the login data may be needed more frequently than is 
>>> reasonable to enter the authentication data locally.
>>> The other is to maintain separate files in provider systems, with a 
>>> common authentication mechanism in each provider to access the file.
>>> I think Paul’s argument doesn’t really hold much water: no SIP device 
>>> I know of requires re-authentication that requires user interaction 
>>> very often, so whatever they do now is okay.  I think they just keep 
>>> the data locally, secure enough to re-use when they need to.  So 
>>> unlock once, good for a very long time.
>>> I’m reluctant to require all providers use the new OAUTH2 solution, 
>>> but if they were okay with it, that would be excellent.  We would 
>>> need some notion of common username, but otherwise it would just 
>>> work.  Seems way too different from how things work now.  Very 
>>> attractive, secure, and user-friendly.
>>
>> My concern was with one configuration file vs. a separate one for each 
>> provider. This is rooted in how the file would be provisioned in the 
>> device.
>>
>> My assumption is that this configuration is generated by the provider 
>> based on the user doing a web-based enrollment on the provider's web 
>> site, followed by the device downloading that configuration. If the 
>> user has accounts with different providers then this would happen 
>> separately for each, resulting is separate configuration files.
>>
>> Do you have a different model in mind for how this would happen?
>>
>> Thanks,
>> Paul
>>
>> --
>> Rum mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rum 
>> <https://www.ietf.org/mailman/listinfo/rum>
> 
>