Re: [Rum] Configuration file

[Paul Kyzivat <[e-mail]>]

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