The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Tomasz Wolniewicz <twoln AT umk.pl>]

Hi Tom,
  Let me repeat again no offense was taken. The little argument I have put up 
was about features and workflow, and this is where we possibly still differ.

  And now for something completely different...
I think that the central CAT service should introduce some additions to the 
terms of use. I would want to see that whenever you make use of the service, 
you are obliged to clearly state that. If you are providing installers 
downloaded from CAT you say so, if you link to the CAT API then you say that 
you are using the CAT service in the background. And of course you also 
mention GEANT as the software developer and service owner and operator. I see 
two reasons for doing that. One is that this is simply fair that the CAT work 
is appreciated by end users and second that by stating that you can also say 
why the installers are signed by GEANT and not your local NRO.  Also if 
people were doing that then possibly we could live with the fact that RESTENA 
installer is offered from the Uninet site. We will get signatures in the 
eap-config files and will definitely display that info in the app.

And by the way, signature checking in the Android app could in principle use 
its own accredited certificate store, would this not be nice, but would not 
scale to large number of backend deployment.

Finally some remarks about the API. The users of 
https://eaplab.supplicants.net (a great service we have created in the SENSE 
project) can see a very different interface to the local CAT instance in that 
service. This was my original idea behind the API. I anticipated that the CAT 
package would be used in deployments outside of eduroam and there a new 
version of the UI  would be necessary, so I wanted to provide a clean way for 
doing that. Then starting with the Android eduroamCAT we started seeing new 
uses for that, and while explaining undocumented features to Gareth who was 
doing the app, I realized that the calls could be more self explanatory, so 
for version 1.2 I have a new version of the calls which get enabled by 
specifying the API version in the call. If we go for a new development of the 
UI I would want it to us the new version and while getting this prepared, 
perhaps tune the new API version as well. 

Tomasz Wolniewicz
UCI UMK

> On 06 Nov 2015, at 13:56, Tom Ivar Myren 
> <tom.myren AT uninett.no>
>  wrote:
> 
> Hi,
> Nice to see that our local CAT front-end has sparked off an interesting 
> discussion.
> 
> Our original idea for the national eduroam page was to simply link users to 
> the cat.eduroam.org site. 
> Then Jørn suggested using the API to make this look and feel more like the 
> rest of our webpages - his testing convinced us that a separate end-user UI 
> was cleaner and simpler for most users, and we ended up with the solution 
> you are now aware of. 
> We still link administrators to cat.eduroam.org, and all profiles are 
> fetched from CAT (the code acts as a client). 
> Tomasz - looks like you are doing the same (as I read the below), with the 
> difference that we at the moment offer all profiles not just one 
> institution.
> 
> Our intention was certainly not to offend anyone, CAT developers have done 
> a great job!
> We see this as utilising the possibilities of the API, and giving our 
> national users a UI where it is clear that this is UNINETT supported. 
> (Local users are more familiar with UNINETT than Geant). 
> Through this discussion we learned that the API actually changed somewhat 
> from CAT 1.0 to 1.1, and will adapt. (By using both generateInstaller and 
> downloadInstaller)
> We did choose to not display all information during download and 
> installation as we did not see that it was needed. (This is such as 
> Helpdesk info and whatever is added under Installer Fine-Tuning)
> 
> In our opinion a model with CAT as the central repository for all profiles 
> is best.
> The web design and user interaction does not have to be centralised, just 
> like every institution has its own helpdesk for eduroam problems. 
> 
> We have registered a couple of requests to make our implementation 
> available and our intention is a version of our «connect» page which uses 
> CAT as a single source of truth. 
> First we want to adjust it so that one can limit which institutions are 
> shown, NROs and institutions can then host their own, with their own (EV?) 
> TLS-certificate and their own design. 
> This may improve the current situation in two ways:
> 
> - Convince IdPs that do not use CAT today to start using CAT (we have a few 
> using locally stored profiles both CAT and others) 
> - Users get profiles from a familiar design, familiar hostname and 
> (depending on IdP) familiar EV-certificate
> 
> All profile downloads will go through CAT, and CAT will collect statistics.
> 
> 
> We are happy make such a “connect" code available on request through 
> github, provided this is OK with the CAT developers.
> 
> Br,
> Jørn de Jong and Tom Myren 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Tomasz Wolniewicz 
> <twoln AT umk.pl>
> Date: Friday 6 November 2015 at 10:35
> To: Zenon Mousmoulas 
> <zmousm AT noc.grnet.gr>
> Cc: 
> "cat-users AT geant.net"
>  
> <cat-users AT geant.net>
> Subject: Re: [cat-users] CAT website design
> 
>> Hi
>> 
>> Tomasz Wolniewicz
>> UCI UMK
>> 
>>> On 06 Nov 2015, at 10:07, Zenon Mousmoulas 
>>> <zmousm AT noc.grnet.gr>
>>>  wrote:
>>> 
>>> I think it's not unrealistic that an NRO or an institution may want to 
>>> use/present CAT data without sending the user to the CAT web site, so 
>>> this should be facilitated. On the other hand, considerable effort has 
>>> gone into translating the CAT UI in many languages, and that should not 
>>> go down the drain.
>> This is what we do at my university. We have our own instructions but for 
>> downloads we link directly to CAT installers via the API. We also tell the 
>> users that the installers are made by GEANT so no surprises about 
>> signature. 
>> Tomasz