Hi Henri,
On Wed, Mar 02, 2011 at 09:37:34AM +0200, Henri Bragge wrote:
> Hi Marcel,
>
> On Tue, 2011-03-01 at 11:39 -0800, Marcel Holtmann wrote:
> > > Arguments string Type
> > >
> > > - Contains the type of a field. For example "psk",
> > > - "wep", "ssid", "wpspin" or plain "string".
> > > + Contains the type of a field. For example "psk", "wep"
> > > + "eap-password", "eap-response", "ssid", "wpspin" or
> > > + plain "string".
> >
> > I like to see consistency here. So using eap-passphrase would be a bit
> > more consistent. However this also questions now if we not better just
> > call this simple passphrase. Or does an EAP passphrase is special in
> > some sort of sense?
>
> It's not special, but "eap" is mentioned because this type of
> passphrases are only asked in the context of EAP login. It adds no real
> information but saves the client from inferring this implicitly.
I think my conclusion on this one was that I really don't expect the user to
be helped by the UI displaying "EAP passphrase" instead of "Passphrase".
Again, it's nice and all for us geeks, but brings no real information to a
typical user.
> "passphrase/response" could be used as well, but I think it leaves their
> practical use more vague (or generic, if you wish).
>
> >
> > And with that in mind, using wps-pin instead of wpspin would be good as
> > well.
>
> I can fix this in a separate patch. The question is: "wps-pin" or "pin"?
>
> >
> > > string Requirement
> > >
> > > @@ -132,3 +138,16 @@ Examples Requesting a passphrase for WPA2 network
> > > }
> > >
> > > ==> { "WPS" : "123456" }
> > > +
> > > + Requesting challenge response for a WPA-Enterprise network:
> > > +
> > > + RequestInput("/service4",
> > > + { "Identity" : { "Type" : "string",
> > > + "Requirement" : "mandatory"
> > > + },
> > > + "Passphrase" : { "Type" : "eap-response",
> > > + "Requirement" : "mandatory"
> > > + }
> > > + }
> > > +
> > > + ==> { "Identity" : "bob", "Passphrase": "secret456" }
> >
> > Coming to thing about this now, it might make sense to have some more
> > generic types for username and password. Or just use string and secret
> > to allow the UI to tell that one is always visible and the other one
> > should be hidden.
> >
> > Same here goes for the WPS PIN type. We might need some generic pin
> > type. And in addition we also need to document that the returning type
> > in the result dictionary is type string etc.
> >
> > In summary, I prefer to only use specific types if they have specific
> > constraints. Like psk for example has an explicit length constraints.
>
> We discussed this before and came to a compromise that it would be nice
> for the UI to know what kind of EAP passphrase connman wants, so that it
> could help the user by showing a different view for MSCHAPV2 and GTC
> login for example (like Maemo 5 does).
I am actually fine with somehow differentiating between passphrases and
challenge responses, but I have to agree with Marcel that the type for both of
them are actually the same (a plain or secret string).
I think a good compromise could be having a new field for challenge responses.
They do look like passphrases, but they're not static. Would that make sense
to you ?
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
_______________________________________________
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
