NameIDPolicy AllowCreate hardcoded to true in AuthnRequest

[mauromol]

Currently, if on login I request to set the NameIDPolicy element on the AuthnRequest, its AllowCreate attribute is hardcoded to true. Is there a particular reason for this?
If I had to think of a possible default value for this attribute in the average case, I would say that omitting the attribute (equivalent to set it to false) would be safer, while requesting it to be true could be an opt-in feature. Indeed, allowing the Identity Provider to create a new user on the fly if the principal was not previously identified might not be the most common scenario, might it?
What do you think?

As a concrete example, the Italian SPID system, for instance, requires a special out-of-band registration process for people to get proper credentials, so when a Service Provider starts a login process with SPID, the end user must already have such credentials; hence the SPID specification denies the use of AllowCreate="true".

Do you think the login process could be enhanced to support the specification of the AllowCreate flag? Please note that, if changes in #307 were accepted, from an API point of view this would just need an enrichment to the AuthRequestParams parameter class. The default value may be kept to true for backward compatibility.

[pitbulk]

I'm still considering adding #307 or not, but meanwhile I belive we can add a new parameter "allowCreate" to the login method, by default true.

[mauromol]

I'm still considering adding #307 or not, but meanwhile I belive we can add a new parameter "allowCreate" to the login method, by default true.

@pitbulk please have a look at #350: I think it brings actual value to implement features like this in an elegant and sustainable way.