Re: [Rum] Configuration file

[Paul Kyzivat <[e-mail]>]

On 10/22/20 9:17 AM, Brian Rosen wrote:
> How would we use DNS to hold the list of providers? 

We could simply create a zone as the root for a regulatory entity, and 
then populate it with A and AAAA entries for each provider in the 
regulatory domain. (There would need to be some way to provision the RUE 
with the zone to consult.)

Or perhaps SRV records could be used for this.

My point is simply that a single domain name or URL per provider could 
be sufficient to bootstrap connecting to the corresponding provider. It 
would require establishing some conventions for how to do the bootstrapping.

> Seems to me that 
> the official list, at least in some places like the US, is controlled by 
> the regulator.  That isn’t the case in other countries.  Where it is, 
> there is an authoritative source.  Could we make the list a registry, 
> make it country specific, and have an expert decide if a provider should 
> be added to the list?

This *might* work given that the set of providers doesn't change 
rapidly. But if/when it does change it isn't evident how deployed RUEs 
would be updated. I guess it might just be treated as part of normal 
maintenance updates, however they are done.

> I think your description of signup and config is good.

It is just a rough start. It needs more discussion and fleshing out. I 
don't know if this needs to be normative. (It might just be something 
such as a non-normative annex.) The main value is to ensure that the 
mechanisms needed to support it *are* defined and normative.

	Thanks,
	Paul

> Yes, I remember multi-line phones.  I have a SIP multi-line phone on my 
> desk that has “lines” from multiple providers.
> 
> Brian
> 
> 
>> On Oct 21, 2020, at 12:39 PM, Paul Kyzivat <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> 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]><mailto:[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]><mailto:[e-mail] 
>>>> <mailto:[e-mail]>>
>>>> https://www.ietf.org/mailman/listinfo/rum 
>>>> <https://www.ietf.org/mailman/listinfo/rum><https://www.ietf.org/mailman/listinfo/rum 
>>>> <https://www.ietf.org/mailman/listinfo/rum>>
>>
>> --
>> Rum mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rum 
>> <https://www.ietf.org/mailman/listinfo/rum>
>