+0 (whatever experienced implementers think), ...
... but consider that verbosity (less-of) is not the only
criteria in a case such as this, where user interfaces
are concerned.
Here the schema is also conveying a sense of the "default"
user interaction principles ... and those follow interaction
design practices that no unbeckoned presentations suddenly
appear [1].
I'd say that in the security context this user interface
aspect extends to all services cooperating in a consistent,
integral, presentation. Which imposes a default of: don't
interpose yourself (IdP/ECP) unless I specifically say you
may (and by which I am indicating that I have already given
the user the proper indications and am committing to follow
up 'your' interactions appropriately).
In other words, a default of "true" for IsPassive seems
just about right to me.
That's my two cents.
--Nick
[1] Given yet-another interpretation in, e.g., the "captive
phase" of Cooper & Reimann, 2003, where an interface must
positively indicate the *potential* actors in the action,
but of course going way back.
> > Conor wrote:
> > > * Line 1873: Strongly recommend that IsPassive default to
> > > "false" not True. The passive request is the exception to
> > > the rule and the default should be set accordingly.
> Scott wrote:
> > +1, I copied this from ID-FF, but I was a little confused
> > by it myself. I didn't think true was the more common case,
> > but I thought maybe this had been concluded otherwise in
> > Liberty discussions.
Conor wrote:
> If it was that way in ID-FF that was a mistake that I missed in my
> review of the ID-FF specs. I can say that there was no significant
> discussion in Liberty where this was consciously decided as my goal
> there was always to make sure that the normal case had the least
> amount of verbosity.
